Re: 10-CURRENT i386 memstick snapshots broken?

From: Nathan Whitehorn <nwhitehorn_at_freebsd.org>
Date: Sat, 08 Jun 2013 14:18:48 -0500
On 06/08/13 14:17, Glen Barber wrote:
> On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote:
>> On Jun 8, 2013, at 10:34 AM, Glen Barber wrote:
>>
>>> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
>>>>> Has anyone else tried the i386 memstick and having the same problem?
>>>>>
>>>> Hmm.  Thanks for the report.  I'll take a look at the logs for i386, but
>>>> they are generated the same way as the amd64, so in theory should not
>>>> have any noticable difference.
>>>>
>>> For amd64 and i386, native binaries are built, and installed into
>>> scratch directories; for powerpc and powerpc64, I just use the amd64
>>> binaries, because I cannot directly use the chroot binaries for
>>> non-native architecture.
>>>
>>> The scripts chroot into the scratch directories, and run the "real"
>>> release builds.
>> Have you tried using Crochet for this sort of thing?
>>
>> Since it was designed from the ground up for cross-building
>> bootable images, it should avoid these issues.
>>
> I have not, primarily because I was not aware of crochet when
> I originally started this.  Although, by using the release stuff from
> the base system, we do get a weekly run-test of the 'make release' bits
> in head/ and stable/9/, so in theory, there would be no surprises when
> it is -RELEASE time.
>
>> The only fundamental limit right now is that Crochet uses
>> the host system to build the UFS filesystems, so it can't
>> build big-endian MIPS images on i386, for example.
>>
>>
> Yes, I have this same issue with sparc64.
>

Why not use makefs? It can build cross-endian UFS images.
-Nathan
Received on Sat Jun 08 2013 - 18:18:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC