CTF: UEFI HTTP boot support

[Warner Losh]

On Wed, Jun 17, 2020 at 12:19 PM Rodney W. Grimes <
freebsd-rwg at gndrsh.dnsmgr.net> wrote:

> > On Wed, Jun 17, 2020 at 11:53 AM Rodney W. Grimes <
> > freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> >
> > > > Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> > > > > > The "fake cd drive" is in the kernel, loader just copies the iso
> into
> > > > > > memory like any other module, and by the time that's done you
> just
> > > > > > reboot into the newly installed system, which again uses
> > > > > >
> > > > > > vfs.root.mountfrom="cd9660:/dev/md0.uzip"
> > > > >                                   ^^^
> > > > >
> > > > > Argh, the cd9660 confused me, I think your doing a
> > > > > "root on mfs/md"?
> > > >
> > > > 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.
> > >
> >
> > Looking at the code, I think MD_ROOT alone is insufficient here...
>
> I was a bit worried about that, but hopefull.  We do work out of the
> box with a NFS root as long as the NIC is found during boot.  And
> given that I load the loader over NFS the loader can also find my
> /boot/ directory and the files in it, so that part is already solved.
>

Yes. If you NFS mount root, it works. But if you are loading a full image,
the boot loader has to do all that and pass the right meta-data to the
kernel for the kernel to know what to use for root.


> > 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.
>
> Isnt this all handled by the loader?  I think we have 2 slightly
> different cases here.  THe one sjg shows up, where you actually
> load the md_image from a  seperate file, and the case your talking
> about where you actually embed the kernel and image into a single
> file.
>

No. I'm talking about dynamically loading as well. The loader sets up the
symbols that point to the image, though I didn't thread my way all the way
through that. The loader sets it all up, and the kernel just uses the hints
the loader gives and the md driver does at least part of the heavy lifting
to make it happen.

>
> > 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"
>
> I do not think that is necessesary but I'll keep it in mind, at present
> I do over ride the vfs.root.mountfrom to point to my version specific
> root file system using some ipxe variables.
>

Usually that's enough, though when you want to use a MD device as root,
it's configured in weird ways that appear from the code to be driven by
ifdefs. And the default defines are for an uncompressed UFS filesystem
inside that MD image. Others are possible, but I believe require compile
time options.

> 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.
>
> Thanks for exposing what may be some pointy sticks to stumble on.
>

Yea, There be a dragon or two here.

The ZRouter folks appear to have do a reroot to the
cdrom:9660:/dev/md0.uzip after dd'ing the installer image onto it....  but
otherwise they don't reply on md stuff running direclty out of flash that's
been uncompressed. I'd thought sure they'd worked this out for network
booting, but if so it's not in the copy of the scripts I have.

> 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.
>
> Probalby a good idea, as the usually failure mode in the diskless
> word is black screens leaving little detail about what went wrong.
>

Yea. Having both serial and video consoles connected wouldn't hurt :)

Good Luck!

Warner


> > Warner
> --
> Rod Grimes
> rgrimes at freebsd.org
>