Notes on Installing and Booting FreeBSD from Grub2

Dec 31, 2012   #freebsd  #grub2  #projects 

I have recently spent several days trying to install and boot FreeBSD, Haiku, and OpenIndiana on a single hard drive. I currently have Xubuntu, FreeBSD, and Haiku installed and booting. I am using a FreeBSD 9.0 release live-usb image as my install media.

This process has involved installing FreeBSD five or six times. Below are some notes on what I’ve figured out in the process. Note that I don’t read documentation unless I get really stuck and don’t have a new guess, so these might not be as surprising to someone who’s read the manual more thoroughly.

Installer

I have gathered that the installer allows the following partition types when manually adjusting the partitioning:

  • freebsd
  • freebsd-ufs
  • freebsd-swap
  • freebsd-boot

When I was using a GPT partition table, the installer insisted on making an at least 64K freebsd-boot partition and suggested making freebsd-ufs and freebsd-swap as separate partitions. When I used an msdos MBR partition table, the installer would not allow me to make a freebsd-boot type partition at all. It insisted on making only a freebsd type partition, and then let me slice that up internally as freebsd-ufs and freebsd-swap (but not freebsd-boot).

I don’t know what freebsd-boot is for or why I don’t need it when I use a freebsd type partition. When using a GPT partition table, it did not prompt me to make a freebsd-boot partition if the first partition I made was of type freebsd. If the first partition was of type freebsd-ufs, then it offered to make a freebsd-boot partition for me.

As far as I could tell, FreeBSD never made any attempt to touch Grub or otherwise affect the process of booting. When I installed FreeBSD first (by itself), it did not boot because the computer went into Grub, which was understandably confusing since it was installed by a Linux distro that I’d deleted. If I installed Xubuntu before FreeBSD, then booting from Grub2 (to Xubuntu) was unaffected.

I tried many times to install Grub2 from a gparted livecd using grub-install, but it never seemed to do anything. I gave up, and installed Xubuntu, which automatically and correctly installs Grub2. If you use GPT, then Xubuntu will insist on making a separate partition for Grub2, and will turn on the bios_grub flag. If you use MBR, then there will be no mention of making a partition for Grub2.

As another note, if you want your user to have sudo privileges later on, you should invite them to the wheel group during user creation. It seems that “wheel” is analogous to “admin”. Also, I’m not the only one wondering why it’s called wheel.

Booting from Grub2

It took me a few tries to get this right; I was glad Grub lets you edit the entry you’re trying to boot into. When I was first figuring out how to do this, I found this StackExchange question very helpful.

Grub2 Files to Edit

I learned this part mostly from this detailed Grub2 tutorial.

The entry is placed in the /etc/grub.d/40_custom file. You need root privileges to edit that. After you edit the file, you need to run update-grub (also as root) to actually change Grub2’s behavior.

I have read several places that running update-grub should find my FreeBSD install and create a menu-option for it automatically. However, this was not the case in my experience. Instead, update-grub noted that there was an “unknown Linux” on such-and-such partition, but did not do anything about it.

If you install Grub2 by installing Xubuntu (or another Linux distro that makes the Grub2 boot menu not appear to let you select an OS), then you should also edit /etc/default/grub to comment out GRUB_HIDDEN_TIMEOUT=0 and GRUB_HIDDEN_TIMEOUT_QUIET=true. That means putting a # at the start of those lines. This will make the Grub menu show up on boot. You need to run update-grub for this to take effect.

GPT

When using a GPT partition table, I found that this worked:

 menuentry "FreeBSD" {
    insmod ufs2
    set root=(hd0,gpt3)
    kfreebsd /boot/loader
 }

I had trouble at first figuring out which partition to set root to. Root should get set to the freebsd-ufs partition, not the freebsd-boot one. If you replace the set root line with search --no-floppy --file /boot/loader, then it should tell you the partition. Ostensibly, that line is supposed to let it figure out the right partition and boot by itself. However, for me, it would print the partition name and then fail. (It failed early enough that I was still in Grub, which is convenient.) If I then used the partition it picked in a set root= line, it booted just fine.

MBR

When I used an msdos MBR partition table, the above entry (well, with root changed to (hd0,msdos4)) would land me in the “FreeBSD bootstrap loader”. It left me at a command prompt with a number of possible commands. Running ls there informed me that it couldn’t mount the filesystem.

Eventually, I tried the chainloader version from that StackExchange question, and it worked. To be specific, I used:

 menuentry "FreeBSD" {
    set root=(hd0,msdos4a)
    chainloader +1
 }

Installing sudo

One of the first things I wanted to do on FreeBSD (after getting a graphical desktop working), was install sudo. It seemed very strange to have to log in as root (su -) every time I wanted to install something or similar. The basic outline of how to do this seems pretty straight-forward:

    su -
    cd /usr/ports/security/sudo
    make install clean
    visudo /usr/local/etc/sudoers

Then, in visudo, you’d uncomment a line to make users in the “wheel” group allowed to use sudo. (This line is %wheel ALL=(ALL) ALL, by the way.) I got this process from here.

The first few steps of this go quite nicely. The problem appeared when I tried to run visudo. It was not installed or otherwise couldn’t be found. Through another set of instructions, I got the idea of installing updates first. Installing updates and rebooting did work the first time, but I’ve since done further “experiments”. To summarize:

  • Installing sudo, rebooting: results in not having visudo.
  • Installing sudo, rebooting, installing updates, rebooting: results in having visudo.
  • Installing updates, rebooting, installing sudo: results in not having visudo. You have to reboot again.
  • Installing sudo and updates, rebooting: results in having visudo.

Additionally, the visudo command does not expect a filename as an argument. My final, correct version (from clean install) is:

    su -
    freebsd-update fetch install
    cd /usr/ports/security/sudo
    make install clean
    shutdown -p now

    su -
    visudo

Then edit the file to uncomment %wheel ALL=(ALL) ALL and save. For those scared of vi like I am, note that:

  • You should be able to navigate with the arrow keys.
  • [Ins] will let you start editing text.
  • [Esc] will get you back into not-editing mode.
  • [Backspace] doesn’t work. Use [Del].
  • In not-edit mode, [Shift]+Z [Shift]+Z will save and exit.

You only have to delete one character to uncomment the line, so I think that should be enough. It’s about all I know about vi, and I managed.

Log out of root (exit), and (assuming you’re in the wheel group) you’ll be able to use sudo. For example, sudo echo "hi".

Open Questions

  • What is the freebsd-boot partition for? Why did the installer only insist on making one in GPT when not using a freebsd partition?
  • Would chainloader +1 work in GPT too?
  • Why didn’t kfreebsd /boot/loader work in MBR? Why can’t the FreeBSD bootstrap loader mount the file system in that case?
  • Why didn’t search --no-floppy --file /boot/loader work, even though it selected the correct partition?
  • Why did I have to reboot after installing updates and sudo before visudo would work?