Multibooting GRUB from a btrfs subvolume.

[oshunluvr]

In 16.04, the last time I encountered this, on my desktop, it depended on how the USB was booted. If the USB boot was in EFI mode, it can only install in EFI mode, and if in BIOS mode likewise. On my desktop the firmware boot device menu had two options for the USB, one called "legacy mode" I think. I seem to recall that it was less simple on some motherboards.

Regards, John Little

Yeah, I remember that too. This time, I booted selecting "USB Device:..." and not "UEFI USB Device:..". It booted just fine, but forced UEFI installation when installing. I don't know if this is a disconnect from the installer-to-system or if it's my BIOS causing the problem. Regardless, I think there should be choice in the matter.

[jlittle]

However, I don't like the thought that the developers have now determined I must use EFI to boot.

In 16.04, the last time I encountered this, on my desktop, it depended on how the USB was booted. If the USB boot was in EFI mode, it can only install in EFI mode, and if in BIOS mode likewise. On my desktop the firmware boot device menu had two options for the USB, one called "legacy mode" I think. I seem to recall that it was less simple on some motherboards.

Regards, John Little

[oshunluvr]

Final step: deleting the unneeded @ and @home subvolumes and everything not needed in @grub.

Before deletion: 246G used.

After deletion: 246G used.

If you're familiar with btrfs, you expected this. When I made snapshots of "@" as "@Kubuntu_1804" and "@grub" no new actual files were copied nor data space used, just the metadata was duplicated. So deleting "@" only deleted metadata.

I also deleted everything in @grub except the contents of /boot/grub and the memtest kernels. I keep memtest on my dedicated grub so I don't need to install it anywhere else. With seven distros installed, if each of them install memtest too - that's a lot of memtest!

I now have a dedicated bootable grub in it's own subvolume.

[oshunluvr]

OK, so I installed Kubuntu to my btrfs file system that already contains 6 other distros. You do this by selecting "Manual" drive configuration during installation, choosing an existing btrfs file system as "/", DO NOT check the "Format..." box, and install.

This leaves the new Kubuntu install in a subvolume called "@" and your new home in "@home". Since I will want to install other distros in the future, I have to change this. I also want to create a bootable grub subvolume from this installation.

After installation I made two snapshots of the new "@", I named one "@Kubuntu_1804" and the other "@grub". I used snapshots instead of renaming because:
1) I wanted a known bootable install in case I mucked up what I was about to do.
2) I needed two copies of 18.04 to do what I've set out to do. Why install twice when I can just snapshot?

At this point, I now have @, @Kubuntu, and @grub all containing the same files. My drive space shows 246G in use at this point. This is notable because it will grow as time goes on.

Next step is to get the @Kubuntu subvolume bootable. To do this you need to edit the fstab file and the grub.cfg (there's nother way to fix the grub.cfg, but this way is easier IMO). I used kate and replace every instance of "@" with "@Kubuntu_1804" (I also snapshoted @home to @Kubuntu_1804_home so I had two home subvolumes at this point. If you do this, you'll need to include this edit in fstab.) To be perfectly - I did these edit in the @Kubuntu_1804 subvolume only.

Now I need to boot into @Kubuntu_1804 to make sure it works. I edited my existing grub.cfg to allow me to boot the new install in the new @Kubuntu_1804 subvolume. I did this by adding a custom grub menu entry like so:

[FONT=monospace][COLOR=#000000]menuentry 'Kubuntu 18.04' {[/COLOR]
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Kubuntu_1804/boot/grub/grub.cfg
[/FONT]

This allowed me to reboot with my existing grub, select the grub menu from Kubuntu 18.04 that was in @Kubuntu_1804/boot/grub - and boot it - and it worked. I am now looking at my new Kubuntu 18.04 install.

Now I wanted to create a boot from a dedicated grub subvolume which I had already created as @grub. This was pretty easy. All I had to do was to mount /boot from @grub somewhere and run grub-install. My btrfs root filesystem resides on sdd3.

The commands:

sudo mkdir /mnt/grub
sudo mount -o subvol=@grub /dev/sdd3 /mnt/grub
sudo grub-install --root-directory /mnt/grub /dev/sda

and that's pretty much it. I did not need to edit fstab or any kernel statements in grub.cfg because this method of booting will not actually boot to @grub - it just uses it to direct the boot to a selected distro.

You will need to create your own custom grub menu to direct your booting stand-alone grub to each installed distro's grub.cfg. I prefer this method because not all distros use the same grub entries so this avoids issues caused by this. My custom grub.cfg looks like this:

[FONT=monospace][COLOR=#000000]#[/COLOR]
# Custom grub config
#
set default='KDE Neon'

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function recordfail {
  set recordfail=0

}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
font="/boot/grub/fonts/unicode.pf2"

if loadfont $font ; then
  set gfxmode=3840x1600
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=3
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=3
  fi
fi

### BEGIN /etc/grub.d/05_debian_theme ###

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
#set_background_image /@KDEneon/usr/share/wallpapers/neonbykde2.jpg";
insmod jpeg
if background_image background1.jpg; then
  true
else
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
fi

### END /etc/grub.d/05_debian_theme ###

### BEGIN Custom menu ###
menuentry 'KDE Neon- It works!' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@KDEneon/boot/grub/grub.cfg
}
menuentry 'KDE Neon - new' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@KDEneon_new/boot/grub/grub.cfg
}
menuentry 'Kubuntu 18.04' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Kubuntu_1804/boot/grub/grub.cfg
}
menuentry 'Kubuntu 16.04' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Kubuntu_16_04/boot/grub/grub.cfg
}
menuentry 'Ubuntu 16.04' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Ubuntu_16_04/boot/grub/grub.cfg
}
menuentry 'Manjaro free' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Manjaro_free/boot/grub/grub.cfg
}
menuentry 'Manjaro nonfree' {
    insmod part_gpt
    insmod btrfs
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    configfile /@Manjaro_nonfree/boot/grub/grub.cfg
}
menuentry 'Memory test (memtest86+)' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
    knetbsd /boot/memtest86+.elf
}
menuentry 'Memory test (memtest86+, serial console 115200)' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4bd4447b-48df-43d8-9781-d444d68ce462
    linux16 /boot/memtest86+.bin console=ttyS0,115200n8
}
menuentry 'KDEneon ISO' {
    set isofile="/neon-useredition-20170608-2351-amd64.iso"
    loopback loop (hd0,2)$isofile
    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
    initrd (loop)/casper/initrd.lz
}
### END Custom menu###
[/FONT]

I created it from a bootable installation, keeping the pieces I wanted and adding the needed menus. I added "It works!" to the top entry so I could verify I was booting from the new grub subvolume and not the old grub partition. I also went back into the custom grub.cfg and changed the all the references to the old grub partition - the UUIDs, the "font=" line, and the two "Memtest" entries to point at the new @grub subvolume.

[oshunluvr]

Well, stuck for the moment. Apparently, you cannot install Kubuntu 18.04 from the ISO unless you use EFI. I don't use EFI. I do not wish to use EFI. I do not need EFI. Looking for a work-around at this point.

Edit: OK, finally got through that. It wasn't a bad as I had expected. I simply booted to the USB stick, ran the installer - Ubiquity - with the "-b" option which skips the boot loader installation. Then I booted into the new Kubuntu 18.04 install manually, ran update-grub which created the needed grub.cfg file, and I was in business. However, I don't like the thought that the developers have now determined I must use EFI to boot. Feels very "Gnome-ish" to me. Seems to me that the option to not use EFI still exists, therefore a good installer would allow that option. Of course, I've never said Ubiquity was a good installer, so...

[oshunluvr]

jlittle gets credit for this idea: I'm going to try this right now:

Booting grub from a stand-alone subvolume.

Here's some detail about the concept, actual steps to follow as I complete them;

Starting with a bootable btrfs install, I'm going to create a new subvolume and copy the contents of /boot/grub to it. Create a custom menu (my preference is to use menu entries that point to other grub.cfg files in each distro). Run grub-install point it at the mounted subvolume. Done. I also have six installs on a single btrfs subvolume. This would be a natural addition.

My method to install subsequent distros involves installing grub with each new distro but not actually booting it, by either:

• Installing grub to a drive other than the actual boot drive
• Installing grub to a partition instead of the boot drive
• Installing grub to the boot drive, then re-running grub-install

The reason for this is every install will have it's own grub files so the grub.cfg can be easily updated when new kernel are installed, etc.


For those of you new to BTRFS and multibooting and to creating and maintaining a dedicated GRUB partition, here's my previous posts on these topics:

https://www.kubuntuforums.net/showth...GRUB-partition
https://www.kubuntuforums.net/showth...ot-How-To-quot
https://www.kubuntuforums.net/showth...ibooting+btrfs
https://www.kubuntuforums.net/showth...es-FIXING-GRUB

These are a bit aged by now though, so do your due diligence before following any of those.

Since Kubuntu 18.04 is out, I will proceed using a new 18.04 installation.

I'm looking forward to this new experiment and your questions!