Date: Wed, 17 Jun 2020 13:06:52 -0600 From: Warner Losh <imp@bsdimp.com> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Miguel C <miguelmclara@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: CTF: UEFI HTTP boot support Message-ID: <CANCZdfrE%2ByKhwPi5Lc%2BhqX2E228hPQ2dmj%2BT2AVD5AdOQy1xeA@mail.gmail.com> In-Reply-To: <48054.1592420182@kaos.jnpr.net> References: <46934.1592351291@kaos.jnpr.net> <202006171752.05HHqo0E086454@gndrsh.dnsmgr.net> <CANCZdfpiY3R4GLJTzDTEMFVjFhZvAtarMHMSzNg2bjMwP8QbCQ@mail.gmail.com> <48054.1592420182@kaos.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 17, 2020 at 12:56 PM Simon J. Gerraty <sjg@juniper.net> wrote: > Warner Losh <imp@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrE%2ByKhwPi5Lc%2BhqX2E228hPQ2dmj%2BT2AVD5AdOQy1xeA>