2

I'm trying to boot mfsBSD ISO via PXE on a host with UEFI boot enabled.

It was a pretty simple task with BIOS boot, the ipxe config for this task looked like this:

kernel --name freebsd http://pxe.host/memdisk
initrd http://pxe.host/mfsbsd.img
imgargs freebsd harddisk raw
boot

Since memdisk way is not supported with UEFI boot method and it seems like there is no other way to boot mfsBSD directly, I switched to booting GRUB2 first:

kernel --name grub2 http://pxe.host/grub2.efi
boot

So now I'm trying to boot an mfsBSD ISO from there, here's how my grub.cfg looks like:

insmod efinet
insmod tftp
insmod loopback
insmod iso9660
insmod ufs2
insmod part_msdos
insmod gfxterm
insmod vbe

menuentry "mfs12.1.iso" {
  set isofile=(tftp)/mfs12.1.iso
  loopback loop $isofile
  echo "ISO mounted"
  set root=(loop)
  kfreebsd /boot/kernel/kernel.gz
  echo "kernel loaded"
  kfreebsd_loadenv /boot/device.hints
  kfreebsd_module /boot/kernel/ahci.ko
  echo "ahci.ko loaded"
  kfreebsd_module /mfsroot.gz type=mfs_root
  set kFreeBSD.vfs.root.mountfrom="ufs:/dev/md0"
  echo "set kFreeBSD.vfs.root.mountfrom"
  set kFreeBSD.mfs_type="mfs_root"
  echo "set kFreeBSD.mfs_type"
  set kFreeBSD.mfs_name="/mfsroot"
  echo "set kFreeBSD.mfs_name"
  set kFreeBSD.mfsbsd.autodhcp="YES"
  echo "set kFreeBSD.mfsbsd.autodhcp"
}

Unfortunately, the boot hangs every time with no information on screen: mfsBSD boot

I've tried changing kFreeBSD.vfs.root.mountfrom to "cd9660:/dev/md0" with no result, tried different mfsBSD versions and also built an EFI-enabled ISO using this solution: https://github.com/mmatuska/mfsbsd/pull/100

Is there anything I am missing in this setup? I would greatly appreciate any help.

1
  • When booting in BIOS style, the local display is initially in text mode, controlled by system's VideoBIOS. This means displaying text is as simple as writing ASCII values into specific memory locations. But when booting in native UEFI style, the local display is initially handled (typically) by the EFI_GOP framebuffer interface, which needs to be accessed in a different way, and may be in a graphics mode when the OS's driver takes over. So your mfsBSD kernel may need to be configured to accept an entirely different kind of console display. – telcoM Jul 3 '20 at 6:17
0

Are you sure that things are not working? Have you tried accessing it via the network?

If you look at the Grub manual and search for amd64 EFI you will see that it only supports headless boot. With your screenshot you might then have successfully booted the system. You should however not expect to see any console output on your screen.

If you build your own version of mfsBSD (or patch the ISO image) you might try setting either nullconsole or comconsole in /boot/loader.conf

console=nullconsole

...for no console - or use serial console using

console=comconsole

Or have a look at 2.12 Advanced Installation Guide

I understand the convenience using mfsBSD as everything is built for you. But it is really not hard to skip Grub alltogether and boot directly into FreeBSD. The only annoyance is that you need NFS running somewhere to boot from.

If you look at the documentation for 31.8. Diskless Operation with PXE - you can see an example config for a dhcp server. Modifying this for UEFI boot is trivial:

# path of boot loader obtained via tftp
filename "loader.efi";

# pxeboot boot loader will try to NFS mount this directory for root FS
option root-path "192.168.0.1:/tftproot/FreeBSD/" ;

So if you copy the FreeBSD /boot/loader.efi to your TFTP server then we will boot to the proper loader right away. AFAIK loader.efi still only supports getting the kernel via NFS on the network (unlike pxeboot(8) which can get further using TFTP). But if you have NFS handy then it is a breeze to setup. You can read more on that in diskless(8)

The default will give you the typical root over NFS. But when you have that going for you then working forward with a memory disk is not hard at all - see 17.9. Memory Disks and mdmfs(8). As mdmfs supports geom_uzip you can have a nice contained image which is easy to modify if need be.

As for the road forward there has been work on UEFI HTTP boot support which will simplify things if you prefer to serve via HTTP rather than NFS. This is however still rather new and shiny.

There are other reports of problems getting the same setup as yours running using UEFI, Grub and mfsBSD.

Again: I do understand the convenience of using the mfsBSD image. I just wanted to show that there is an alternate route. If we're lucky maybe someone with more Grub experience can chime in with a better answer.

1
  • OK there's a few things you (may) have to do here. To get your desired results. 1) your BIOS, switch it's settings to LEGACY CSM or whatever the setting is for (u)efi boot. 2) (and this may be difficult if on an ISO image) cd /<mfsbsd>/path/to/boot (/boot) while there; rm ./loader && ln loader_4th loader 3) edit loader.conf(5), removing or commenting any lines involving vt or efi, and add kern.vty=sc. This will give you a usable (boot) console (pty). That should provide for your needs. IOW don't use grub. BSD boot will work for you. – somebody Mar 4 '20 at 22:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.