Can Linux boot FreeBSD?

PMc

PMc

I happen to have a machine that can only install linux, due to available boot images. (Machine is mfd ~2011.)

So I put FreeBSD on the second disk, and replaced the MBR on the first disk with boot0cfg. The problem now is: I cannot boot from the second disk, I just get the hash mark:

Code: 
F1  Linux
F2  ?
F3  Linux
F4  FreeBSD
F5  Drive 1

F6: PXE
Boot:  F5 ###########################

Both disks are accessible and useable after an OS has loaded, and obviousely I did write the boot blocks a couple of times - it seems there is some problem with the BIOS not properly knowing the second disk.
So, before complaining, I thought I try to boot via the Linux installation, i.e. use 'grub'.
But then I found, grub cannot boot FreeBSD at all, no matter if on the first or second disk. There are many examples on the web, what should be put into the grub configs to show FreeBSD; I tried lots of them, and none of them does boot FreeBSD.

Then I looked closer: none of these examples actually states that grub would ever boot FreeBSD! They only talk about putting "FreeBSD" into the grub menu! And that does work flawlessly: all of these examples do put "FreeBSD" into the grub menu - with chooseable colors&styles, even multiple times, or highlighted as the default. Only, none of them would ever actually boot anything else than Linux. (Obviousely, as soon as I write a boot0cfg onto the MBR, FreeBSD boots rightaway - at least when living on the first disk,)
 
Is the FreeBSD bit ZFS? If so that may require more magic from Grub.
But to answer your question:
Yes Grub used to be able to boot a FreeBSD UFS install from another disk or partition. Can it now? I have no idea, as I have not tried it about 20 yrs.
 
mer said:
Is the FreeBSD bit ZFS?
Click to expand...
No. Pure old-fashioned MBR-partition (aka slice) with BSDlabel entries..

mer said:
Yes Grub used to be able to boot a FreeBSD UFS install from another disk or partition. Can it now? I have no idea, as I have not tried it about 20 yrs.
Click to expand...
Yes, I know, at that time it did work. At that time grub wouid just read and run the bootblocks on the FreeBSD MBR-partition (the first 16 sectors coming from /boot/boot). But nowadays grub needs to be configured the os brands, gpt labels, bsd labels, ufs2 filesystems, device.hints files, kenv variables, and lots more to obtain FreeBSD menu entry, but, in contrast, apparently cannot boot FreeBSD anymore.
 
I boot FreeBSD from a Grub menu all the time although I have Linux and FreeBSD on the same disk. I could try booting FreeBSD from a second disk, but suspect it's fairly straightforward.
 
balanga said:
I boot FreeBSD from a Grub menu all the time although I have Linux and FreeBSD on the same disk.
Click to expand...
And how do You get it to do that?
If I try with Freebsd on the same disk, grub just shows a blue menu with white, highlighted "FreeBSD", and I wouldn't call that booting. And when I look into the docs, there are endless description about how to change the color from blue to something else, and how do design splash screens, and that's all there is.
 
This is part of my grub.cfg with three different FreeBSD installations. I put these at the top of the cfg so that they are first in the list. This is on a GPT partitioned disk which I find much easier to manage than MBR

Code: 
menuentry "FreeBSD 13.0-RELEASE amd64 ***** STABLE default - use for XWindows ******  !" {
    insmod ufs2
    insmod part_gpt
    set root=(hd0,2)
    kfreebsd /boot/loader
}

menuentry "FreeBSD 13.0-RELEASE i386 ***** TESTING - use for XWindows ******  !" {
    insmod ufs2
    insmod part_gpt
    set root=(hd0,4)
    kfreebsd /boot/loader
}

menuentry "FreeBSD 11.2-RELEASE i386 ***** Holding area for P018 ******  !" {
    insmod ufs2
    insmod part_gpt
    set root=(hd0,5)
    kfreebsd /boot/loader
}
 
I recently did this on an old Dell Latitude, with an already existing MBR partitioning scheme, originally used to boot Windows XP if I remember correctly.

First I installed FreeBSD 13.0-MATE with BSDlabels on partition 1, then I installed Debian 10.9 on partitions 2 and 3, with one ext4 and one swap partition. Then I could only boot Debian, as expected.

Next I used Debian to edit /etc/grub.d/40_custom, adding this at the end:
Code: 
menuentry "FreeBSD-13.0-MATE" {
  insmod ufs2
  root=(hd0,1)
  kfreebsd /boot/loader
}
Next I ran update-grub from Debian, and rebooted, and it all worked fine with no problems.

Later I installed another FreeBSD instance on the 4th and final partition, expecting that I would have to reinstall Debian again afterwards. To my surprise, rather than booting the new FreeBSD I had just installed on partition 4, it still booted to the same Debian boot menu. So I used Debian and added another menuentry after the first one:
Code: 
menuentry "FreeBSD-13.0-KDE" {
  insmod ufs2
  root=(hd0,4)
  kfreebsd /boot/loader
}
Now I'm able to boot any of the 3 installs with no problems. I've been using it for over a month now.

I don't know why FreeBSD didn't overwrite the grub boot loader. Maybe it detected what I was trying to do and kindly cooperated?

I think that to boot from a second disk, you would replace the "hd0" designation with "hd1" but I've never tried to do that.

There might be a problem with mixing MBR and GPT partitioning schemes? I don't know but I wouldn't automatically expect it to be a problem.

For my older, GPT-only systems, I was using a slightly different syntax, like this:
Code: 
menuentry "FreeBSD11.2-RELEASE" {
  insmod ufs2
  root=(hd0,gpt2)
  kfreebsd /boot/loader
}
I've never messed with grub.cfg and can't claim to understand it.
 
balanga said:
This is part of my grub.cfg with three different FreeBSD installations. I put these at the top of the cfg so that they are first in the list. This is on a GPT partitioned disk which I find much easier to manage than MBR
Click to expand...
Thank You. I tried quite that a couple of times, it just shows the menu and does nothing further. :(

I am using MBR because the provided installation image does so. But then I am wondering: somehow grub would need to know the MBR-partition number and the BSDlabel-partition number (because they are nested) before being able to access an ufs-path. And I don't see where that would be configured.

But now the machine has died anyway and can no longer be accessed. Seems it didn't like these experiments. :/
Vull said:
Next I used Debian to edit /etc/grub.d/40_custom, adding this at the end:
Code: 
menuentry "FreeBSD-13.0-MATE" {
  insmod ufs2
  root=(hd0,1)
  kfreebsd /boot/loader
}
Next I ran update-grub from Debian, and rebooted, and it all worked fine with no problems.
Click to expand...
I am certain I tried that one, too. Result was same as always: grub would show the menu and then wait and do nothing else.

Vull said:
There might be a problem with mixing MBR and GPT partitioning schemes? I don't know but I wouldn't automatically expect it to be a problem.
Click to expand...
Those machines are Dell blades (R210 II etc.), mfd 2012 or earlier, and can run without GPT in pure MBR mode.
 
The linux grub bootloader is powerfull. I use it to boot freebsd-on-zfs, alpine-linux-on-zfs, void-linux-on-zfs.
The best way is to let grub find the freebsd bootloader.
For chainloading freebsd-on-zfs it is as easy as,
Code: 
menuentry "ZFS ON ROOT CHAINLOADING" {
 insmod part_msdos
 insmod part_gpt
 insmod zfs
 search -s -l ZT
 kfreebsd /ROOT/default/@/boot/zfsloader
}
 
You must log in or register to reply here.
Back
Top