Re: CTF: UEFI HTTP boot support

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.

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\"

> 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.

--sjg