Re: CTF: UEFI HTTP boot support

On Wed, Jun 17, 2020 at 12:56 PM Simon J. Gerraty <sjg_at_juniper.net> wrote:

> Warner Losh <imp_at_bsdimp.com> wrote:
> > > loader.conf says
> > >
> > > rootfs_load="yes"
> > > rootfs_name="contents.izo"
> > > rootfs_type="md_image"
> > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > >
> > > contents.izo is uzip'd contents.iso which file(1)
> > > describes as ISO 9660 CD-ROM filesystem data ''
> > >
> > > That's for normal boot, for the loader 'install' command
> > > it expects an uncompressed iso for rootfs.
> >
> > Ok, now the puzzle is how much work to get from a stock FreeBSD .iso
> > image to something that works with this.  Obviously we need a non-stock
> > /boot/loader.conf file, or to type some commands manually at a loader
> > prompt.  I believe the stock GENERIC kernel has the md_root support
> > for this already, so it may not be that hard to do.
>
> So obviously we don't use the GENERIC kernel, but
> I don't think we have any magic except in 4th files and loader.conf
> and for the loader install command its all in the loader itself,
> and I've been keeping head up todate on recent fixes/improvements there
> since for UEFI I'm using loader.efi built from head.
>

Yea the loader will load the image, but the md driver looks for images of
type md_image or md_root and will create md devices for those devices it
finds.


> Oh and all the scripts run by init during boot are custom.
>
> > Looking at the code, I think MD_ROOT alone is insufficient here...
> >
> > If there's no MD root provided, we look for the symbols mfs_root and
> > mfs_root_end, which I think means that rootfs_ in the above example
> > needs to be md_root_ instead so that we find it.
>
> FWIW our kernel options include
>
> options         CD9660
> options         MD_ROOT
> options         MD_ROOT_FSTYPE=\"cd9660\"
>

Yea, this lets you mout cd9660 images as root...

It also drives setting rootdevnames[0] which is used to create the default
mountroot script on loading the first md image.


> > You may need to have a custom kernel with 'options MD_ROOT_READONLY'
> because isofs is read-only.
> >
> > And there's a small chance you may need to define ROOTDEVNAME in the
> build as well to be "cd9660:/dev/md0.uzip"
>
> > Every time I do stuff like this I have to re-puzzle it out, alas, but
> > these should give you some guide posts. It should be better documented
> > in md(4), but isn't at the moment.
> >
> > I'd honestly try to get this setup working first loading all the files
> > off a local disk before layering in the networking on top of that.
>
> Agreed! Booting from say tftp://host/install.tar
> is far more fragile - the tar file needs to present all the files in
> correct order since we cannot seek backwards (much), and tftp sucks ;-)
>
> userboot is very handy for testing all this stuff, though building it to
> run on host (the way we do) seems broken in head.
>

Yea, of course. that makes sense. I'd forgotten userboot helps a lot. The
default build of it should be working, though...

Warner


> --sjg
>