Re: Building a macppc bootable USB image

[David Brownlee <abs%absd.org@localhost>]

On Tue, 27 Feb 2024 at 02:37, Valery Ushakov <uwe%stderr.spb.ru@localhost> wrote:
>
> I spent a bit of time experimenting with booting my mini off of a
> plain FAT USB and the results are a bit mixed.
>
> One can dd the (proper) install CD onto the USB and boot off of that.
> The downside is that the proper install CD requires a tool not in base
> to create the proper HFS-whatever info for the CD (cf. non-bootable
> iso images from daily builds).

I'll try to get the install notes for -10 updated this week to note
the 'dd iso to usb' option for installation.
Should at least make it easier for people to install a normal release :)

> So I thought I'll look at plain FAT.
>
> OFW in mini groks FAT, so you can put ofwboot on a FAT partition
> (that's how I normally boot).  But putting a kernel to the same FAT
> partition seems to pose a problem.  As far as I understand we will use
> OFW to read that file in that case and it looks like OFW's FAT
> implementation has issues with "seek".  I can boot the generic kernel
> from that same partition.  I can't boot either that same generic
> kernel gzipped, or the gzipped install kernel.  I can't boot gunzipped
> install kernel either.  I'm not sure why generic is lucky.
>
> Gzipped kernels fail to boot b/c we read the gzipped file to the end
> and then to seek backwards to read the symbols we need to reread the
> whole file, but when we seek to the beginning, the read just returns
> zero, as if we are stuck at EOF.
>
> As an experiment, reading the whole file inside open and seeking back
> to zero has the same effect - the next reads return 0.  If I do just a
> few test reads inside open and then rewind, eventually some read later
> on will fail.  So it's as if OFW deblocker keeps track of the position
> correctly, but loses track of how much it can still read from that
> position (that same generic kernel that happens to boot, will not boot
> in this case, with a couple of extra reads/seeks thrown into the mix
> inside open).

(Warning - random suggestions of more work for someone who has already
done all this work and testing so far follow :)

Foo... I imagine it would be a real pain to replace any (backwards)
seek with a close & re-open... It would probably be less work to read
the entire file into memory and then decompress from there :/

Could there be anything related to the number of calls we make, such
that ofw/we are leaking something with each call? When loading a large
uncompressed kernel does reading data in larger or smaller blocks
affect the maximum size we can read...

As a final desperation move we could use kloader - have ofwboot load a
stripped down kernel, that *then* autoconfigures and loads the real
kernel just talking to the bare devices (definitely a last option :)

> I haven't yet figured out how to convince ofwboot to use libsa version
> of the filesystem code.  ofwboot can load kernel from whatever you
> want, but it uses a bit different syntax, doesn't use devalias
> abbreviations and so it's quite a pain to experiment b/c you need to type
>
>   boot usb0/disk:,\ofwboot.elf /pci@f2000000/usb@1b,1/disk/install
>
> in tiny letters, on a real keyboard instead of just pasting it into a
> serial console.  (The above of course can be spelled as
>
>   boot usb0/disl:,\ofwboot.elf install
>
> and if the kernel is named "netbsd" instead of "install" you don't
> have to type its name, but here the point was to, for now, avoid the
> default on purpose.)

That might presumably also bypass the loading issue?

> Instead of a kernel with a ramdisk we can probably just use a separate
> partition on the same USB, but copying a few files onto a FAT
> formatted USB is more convenient than creating an image you have to
> dd, etc, etc.

Definitely, but it sounds like you already have the makings for a
reliable way to make a bootable writable live USB image? :)

Thanks

David