Date: Wed, 17 Jun 2020 20:28:21 +0000 From: "Dave Cottlehuber" <dch@skunkwerks.at> To: freebsd-current@freebsd.org, "Miguel C" <miguelmclara@gmail.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "Rebecca Cran" <rebecca@bsdio.com>, "Warner Losh" <imp@bsdimp.com> Subject: Re: CTF: UEFI HTTP boot support Message-ID: <c38f2d4b-fbeb-4c6f-865a-f9dd2dd17501@www.fastmail.com> In-Reply-To: <202006171752.05HHqo0E086454@gndrsh.dnsmgr.net> References: <202006171752.05HHqo0E086454@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jun 2020, at 17:52, Rodney W. Grimes wrote: > > Rodney W. Grimes <freebsd-rwg@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. Hi Miguel, all, I spent a bit of time on UEFI HTTP Boot earlier in the year in qemu, bhyve, and intel NUCs -- until everything in the world went to custard. I made some rough notes[1] and I'll go through them again tonight with a fresh build. Hopefully its useful. What I got stuck on was the final pivot, I have never debugged this setup before and I'm still not clear at what point things fail. Olivier's PXE booting and BSDRP were a fantastic reference, and I assume they work in BSDRP already for him. Worth noting that LE TLS certs didn't play well with the PXE UEFI implementation on my intel NUC, this comes up as a very unhelpful error. At least use plain HTTP to get started. While my notes are amd64 oriented I'm very interested in using this for aarch64 locally & in the clowd. My loader.conf follows: boot_multicons="YES" console="efi,comconsole" comconsole_speed="115200" boot_verbose="YES" # make booting somewhat less painful #entropy_cache_load="NO" #kern.random.initial_seeding.bypass_before_seeding="0" # entropy_cache_load="YES" # boot_single="YES" tmpfs_load="YES" autoboot_delay="-1" # dump net vars # exec="show boot.netif.hwaddr" # exec="show boot.netif.ip" # exec="show boot.netif.netmask" # exec="show boot.netif.gateway" # ensure we have enough ram for our image vm.kmem_size=2G vfs.root.mountfrom="ufs:/dev/md0" # vfs.root.mountfrom.options=ro mfs_load="YES" mfs_type="md_image" mfs_name="/boot/mfs-miniroot" interesting these are different from what's above in the thread. references: [1]: https://hackmd.io/@dch/H1X9RYEZr [mfsBSD]: https://mfsbsd.vx.sk/ still 150% awesome [olivier]: https://blog.cochard.me/2019/02/pxe-booting-of-freebsd-disk-image.html [BSDRP]: https://github.com/ocochard/BSDRP A+ Dave
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c38f2d4b-fbeb-4c6f-865a-f9dd2dd17501>