Multibooting GRUB from a btrfs subvolume.

[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!

[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]

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]

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.

[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]

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.

[GreyGeek]

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.
....

For people doing this the first time, before they do the above steps they should FIRST, IF I understand what you are doing, rename their existing @ and @home to @SOMENAME and @homeSOMENAME, and edit the /etc/fstab to point to @SOMENAME and @homeSOMENAME, and then redo the grup-update command to refresh grub.cfg.

That way they'll end up with
FS_ROOT:
@
@home
@SOMENAME
@homeSOMENAME


Otherwise, won't they overwrite their existing @ with the new @ and their existing @home with the new @home when they chose "/ and uncheck the "Format" box? Yes? No?

[oshunluvr]

For people doing this the first time, before they do the above steps they should FIRST, IF I understand what you are doing, rename their existing @ and @home to @SOMENAME and @homeSOMENAME, and edit the /etc/fstab to point to @SOMENAME and @homeSOMENAME, and then redo the grup-update command to refresh grub.cfg.

That way they'll end up with
FS_ROOT:
@
@home
@SOMENAME
@homeSOMENAME


Otherwise, won't they overwrite their existing @ with the new @ and their existing @home with the new @home when they chose "/ and uncheck the "Format" box? Yes? No?

Yes, absolutely. This post was supposed to be more about creating and using a grub subvolume as a stand-alone grub install but I complicated it a bit with adding a new distro install at the same time.

[GreyGeek]

Thanks for the confirmation!

Based on what I think I know about Btrfs installations I wanted to be sure I understood what you are doing.

I’ve never attempted to set up the multi-boot system you are running, but plan to definitely switch to it when I do a fresh install of KDE Neon UE based on 18.04.

That will include switching from device names (/dev/sd X) to UUIDs. I’m going to use my two newest WD 750GB HD’s as a two drive pool and the oldest HD as archive storage, which I’ll keep spun down till I use it to receive subvolumes.

When I used EXT4 I always created only the “/“ partition so that I wouldn’t have to guesstimate how much space to give to /home or /root or /use or what ever. Each file or directory took what ever space it needed from the available unused space. Your multi-boot Btrfs technique does for booting what using just / does for partitioning.

[oshunluvr]

Partitions? Who needs stinkin' partitions? Now I even have my stand-alone grub in a subvolume thanks to jlittle's idea.

The use of subvolumes is simply brilliant; no more partitioning, easy backups and data transfers, roll-back capability, etc. I only need to partition for grub/efi and that's it.

Right now I'm re-arranging the data on my server. Once that's done, I'll be re-writing my backup automation since I'm moving away from RAID1 for the time being. This will leave my server with a 10TB drive for data - zero partitions, 2x6TB drives for backups - zero partitions, and a 60GB SSD that I boot from. The SSD holds grup. swap. and the installs. My only concern if the SSD fails, I would have to boot to a USB stick. I may just get one of those little thumb-nail sized USB drives and set it up as a backup boot device.

[GreyGeek]

So, what does a directory listing of your FS_ROOT look like?

[oshunluvr]

At this very moment:

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ ll /subvol[/COLOR]
total 4
drwxr-xr-x 1 root root 720 Apr 27 14:41 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root   8 Apr 27 14:42 [COLOR=#5454FF][B]@grub[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]@KDEneon[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]@KDEneon_backup[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Apr 18 06:33 [COLOR=#5454FF][B]@KDEneon_daily_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Apr 16 19:54 [COLOR=#5454FF][B]@KDEneon_daily_3[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 428 Apr 15 18:55 [COLOR=#5454FF][B]@KDEneon_daily_5[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 428 Apr 14 18:55 [COLOR=#5454FF][B]@KDEneon_daily_6[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 396 Apr 13 18:55 [COLOR=#5454FF][B]@KDEneon_daily_7[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Jan 22 16:02 [COLOR=#5454FF][B]@KDEneon_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Jan 22 16:02 [COLOR=#5454FF][B]@KDEneon_home_backup[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 24 09:03 [COLOR=#5454FF][B]@KDEneon_home_daily_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 24 07:34 [COLOR=#5454FF][B]@KDEneon_home_daily_2[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 18 06:33 [COLOR=#5454FF][B]@KDEneon_home_daily_3[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 17 07:01 [COLOR=#5454FF][B]@KDEneon_home_daily_4[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 16 19:54 [COLOR=#5454FF][B]@KDEneon_home_daily_5[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 196 Jun 13  2017 [COLOR=#5454FF][B]@KDEneon_new[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 262 Dec 13  2016 [COLOR=#5454FF][B]@Kubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 224 Apr 27 13:00 [COLOR=#5454FF][B]@Kubuntu_1804[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  32 Apr 26 14:24 [COLOR=#5454FF][B]@Kubuntu_1804_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 282 Jun 27  2017 [COLOR=#5454FF][B]@Manjaro_free[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 228 Feb 26 11:39 [COLOR=#5454FF][B]@Manjaro_nonfree[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 234 Apr 17 06:26 [COLOR=#5454FF][B]@Ubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 234 Apr 17 07:26 [COLOR=#5454FF][B]@Ubuntu_16_04_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
[/FONT]

[GreyGeek]

Final step: deleting the unneeded @ and @home subvolumes and everything not needed in @grub.
.....
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.

So everything in @grub except the files in the root of /boot, and /boot and /sys (?) were deleted?

.....

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.

All those changes are made in the new subvolume. Got that.

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.

Which subvolume is the "existing" grub.cfg in? The one you are currently running under I assume?

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.

I wasn't aware that the grub-install command allowed --root-directory to be more than one device. That command is saving grub.cfg in both /mnt/grub and /dev/sda

Or, is it "--root-directory=/mnt/grub" and /dev/sda is the destination?

[GreyGeek]

At this very moment:

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ ll /subvol[/COLOR]
total 4
drwxr-xr-x 1 root root 720 Apr 27 14:41 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root   8 Apr 27 14:42 [COLOR=#5454FF][B]@grub[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]@KDEneon[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 286 Apr 25 07:37 [COLOR=#5454FF][B]@KDEneon_backup[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Apr 18 06:33 [COLOR=#5454FF][B]@KDEneon_daily_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 252 Apr 16 19:54 [COLOR=#5454FF][B]@KDEneon_daily_3[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 428 Apr 15 18:55 [COLOR=#5454FF][B]@KDEneon_daily_5[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 428 Apr 14 18:55 [COLOR=#5454FF][B]@KDEneon_daily_6[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 396 Apr 13 18:55 [COLOR=#5454FF][B]@KDEneon_daily_7[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Jan 22 16:02 [COLOR=#5454FF][B]@KDEneon_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Jan 22 16:02 [COLOR=#5454FF][B]@KDEneon_home_backup[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 24 09:03 [COLOR=#5454FF][B]@KDEneon_home_daily_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 24 07:34 [COLOR=#5454FF][B]@KDEneon_home_daily_2[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 18 06:33 [COLOR=#5454FF][B]@KDEneon_home_daily_3[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 17 07:01 [COLOR=#5454FF][B]@KDEneon_home_daily_4[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  48 Apr 16 19:54 [COLOR=#5454FF][B]@KDEneon_home_daily_5[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 196 Jun 13  2017 [COLOR=#5454FF][B]@KDEneon_new[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 262 Dec 13  2016 [COLOR=#5454FF][B]@Kubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 224 Apr 27 13:00 [COLOR=#5454FF][B]@Kubuntu_1804[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root  32 Apr 26 14:24 [COLOR=#5454FF][B]@Kubuntu_1804_home[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 282 Jun 27  2017 [COLOR=#5454FF][B]@Manjaro_free[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 228 Feb 26 11:39 [COLOR=#5454FF][B]@Manjaro_nonfree[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 234 Apr 17 06:26 [COLOR=#5454FF][B]@Ubuntu_16_04[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root 234 Apr 17 07:26 [COLOR=#5454FF][B]@Ubuntu_16_04_1[/B][/COLOR][COLOR=#000000]/[/COLOR]
[/FONT]

Wow!

[jlittle]

$ sudo grub-install --root-directory /mnt/grub /dev/sda

Alas, on EFI the grub-install has problems:

$ sudo grub-install --root-directory /mnt/grub /dev/sdc
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

I suspect I'll have to chroot into the @grub subvolume, or use --efi-directory and --target=x86_64-efi. I want to get better backed up before I try that.

I have noticed that in the ESP, seen as /boot/efi/EFI/ubuntu there's a stub grub.cfg that the bionic installer put there, with only three lines that just loads /@/boot/grub.cfg; but it's not used, bionic is now in @_bionic. Instead, (,gpt2)/@_bionic/boot/grub is baked into the grubx64.efi executable. (I found it with strings grubx64.efi | grep @.)