Multibooting GRUB from a btrfs subvolume.

[oshunluvr]

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

Everything except /boot/grub and it's contents and I left the three memtest kernels in /boot. EVERYTHING else is gone - no Linux kernels, no other folders.

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ ll /subvol/@grub/boot/[/COLOR]
total 548
drwxr-xr-x 1 root root    112 Apr 27 14:43 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root      8 Apr 27 14:42 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root    120 Apr 27 14:34 [COLOR=#5454FF][B]grub[/B][/COLOR][COLOR=#000000]/[/COLOR]
-rw-r--r-- 1 root root 182704 Jan 28  2016 memtest86+.bin
-rw-r--r-- 1 root root 184380 Jan 28  2016 memtest86+.elf
-rw-r--r-- 1 root root 184840 Jan 28  2016 memtest86+_multiboot.bin
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]~[/B][/COLOR][COLOR=#000000]$ ll /subvol/@grub/boot/grub/[/COLOR]
total 2356
drwxr-xr-x 1 root root     120 Apr 27 14:34 [COLOR=#5454FF][B].[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root     112 Apr 27 14:43 [COLOR=#5454FF][B]..[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root      22 Apr 27 13:41 [COLOR=#5454FF][B]fonts[/B][/COLOR][COLOR=#000000]/[/COLOR]
-rw-r--r-- 1 root root     712 Apr 26 14:26 gfxblacklist.txt
-rw-r--r-- 1 root root    3844 Apr 27 14:34 grub.cfg
-rw-r--r-- 1 root root    1024 Apr 27 13:17 grubenv
drwxr-xr-x 1 root root    6228 Apr 27 13:47 [COLOR=#5454FF][B]i386-pc[/B][/COLOR][COLOR=#000000]/[/COLOR]
drwxr-xr-x 1 root root      68 Apr 27 13:47 [COLOR=#5454FF][B]locale[/B][/COLOR][COLOR=#000000]/[/COLOR]
-rw-r--r-- 1 root root 2397557 Apr 26 14:25 unicode.pf2

[/FONT]

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

Correct

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

The @grub subvolume contains the custom grub.cfg with my menu entries that point at the other grub.cfgs. Each distro subvolume has it's own grub cfg.

To explain: When I boot, I initally see my custom grub menu that looks like this:

KDE Neon
KDE Neon - new
Kubuntu 18.04
Kubuntu 16.04
Ubuntu 16.04
Manjaro free
Manjaro nonfree
Memory test (memtest86+)
Memory test (memtest86+, serial console 115200)
KDEneon ISO'

Each of these entries except the last three point to another grub.cfg. So now since I've added Kubuntu 18.04, it's menuentry within this custom grub.cfg looks like:

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
}

When I initially select Kubuntu 18.04, it doesn't bootup right away, instead a second grub menu appears - the one that's in Kubuntu 18.04 (note the last line in the above menuentry). If I hit "ESC" grub returns to the first (the custom) grub menu that's in @grub. Effectively, they are nested menus. Since I go through two grub menus each time I boot, I set the timeout to 3 seconds in the initial grub.cfg and 5 seconds on the other grub.cfgs. This gives me enough time to change my mind without delaying the boot process too much if don't do anything during bootup. I keep my current (daily driver) distro as the default in the first grub.cfg so if I power up and walk away, my regular distro is booted (KDEneon at this time).

Again: the advantage with this is the custom menu is (mostly) set-it-and-forget-it. I only have to edit it when I add or remove a distro. Each distro, since they all have their own grubs and grub.cfgs, maintain their own grub.cfgs just like they would in a stand-alone installation. Kernel changes are not an issue. Also, since grub is stand-alone, no one distro can muck it up.

A few weeks back when my KDEneon was having trouble booting and I need to roll-back to a snapshot, I just booted to Manjaro, did the roll-back, and rebooted. Done in less than a minute.

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?

grub-install doesn't do anything with grub.cfg except tell the grub bootloader where it is. update-grub creates the grub.cfg in /boot/grub. grub-install points the bootloader at whatever grub.cfg you tell it to. Since I switched the location of my grub files from /dev/sda4 (my previous dedicated grub partition) to the new @grub subvolume in my btrfs file system, I had to tell the bootloader of the new location of the grub files. That's what grub-install does. In fact, I currently have four drives in my computer and for safety purposes I make them all bootable. So I ran grub-install four times, once for each drive. The "--root-directory" tells the bootloader where to go when booting to find it's files and grub.cfg. The bootloader is only on the first 446 bytes of a bootable drive.

As to booting my new Kubuntu 18.04 install; When I installed Kubuntu 18.04 without a bootloader, update-grub did not run. Therefore there was no grub.cfg in the Kubuntu 18.04 to select from my custom grub.cfg and boot from. I had to manually boot it by entering the proper commands to boot it into grub. This was much less difficult than it sounds. Since all my distros reside on the same file system, they have the same UUID. All I had to do was select KDEneon in my first grub menu (the custom one), when the second grub menu (from the grub.cfg in KDEneon) appeared, I pressed the "E" key to enter the grub editor. Then I edited these two lines (the last in the menuentry):

     linux    /[B]@KDEneon[/B]/boot/vmlinuz-[B]4.15.0-15[/B]-generic root=UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 ro rootflags=subvol=[B]@KDEneon [/B] quiet splash $vt_handoff
     initrd    /[B]@KDEneon[/B]/boot/initrd.img-[B]4.15.0-15[/B]-generic

to look like this:

     linux    /[B]@Kubuntu_18.04[/B]/boot/vmlinuz-[B]4.15.0-20[/B]-generic root=UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 ro rootflags=subvol=[B]@Kubuntu_1804[/B]
     initrd    /[B]@Kubuntu_18.04[/B]/initrd.img-[B]4.15.0-20[/B]-generic

I only had to change "@KDEneon" to "@Kubuntu_1804" in three places and correct the kernel version number in two. I had forgotten to note the kernel version that was installed with Kubuntu 18.04 before I rebooted, but no big deal - while in the grub menu, pressing F2 brings up the grub console, where I could "ls" my way into "@Kubuntu_1804/boot" and see the kernel version there.

Once I had successfully booted into @Kubuntu 18.04, I ran update-grub and created a grub.cfg. Then I mounted @grub at /mnt/grub, edited /mnt/grub/boot/grub/grub.cfg (my custom grub.cfg) and added a menuentry for Kubuntu 18.04. Now it boots just like the other six distros.

[oshunluvr]

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

Sorry, I can't help you with EFI. QQmike has a lot of experience and knowledge with EFI, maybe he can help. Hopefully you can get it figured out because moving grub to a subvolume is a brilliant idea! I used to maintain two grub partitions on separate drives to have a backup grub to boot too. Now I can make a backup of @grub just like I do with any other subvolume! Thanks for the idea

[GreyGeek]

....
As to booting my new Kubuntu 18.04 install; When I installed Kubuntu 18.04 without a bootloader, update-grub did not run. Therefore there was no grub.cfg in the Kubuntu 18.04 to select from my custom grub.cfg and boot from. I had to manually boot it by entering the proper commands to boot it into grub. This was much less difficult than it sounds. Since all my distros reside on the same file system, they have the same UUID. All I had to do was select KDEneon in my first grub menu (the custom one), when the second grub menu (from the grub.cfg in KDEneon) appeared, I pressed the "E" key to enter the grub editor. Then I edited these two lines (the last in the menuentry):

     linux    /[B]@KDEneon[/B]/boot/vmlinuz-[B]4.15.0-15[/B]-generic root=UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 ro rootflags=subvol=[B]@KDEneon [/B] quiet splash $vt_handoff
     initrd    /[B]@KDEneon[/B]/boot/initrd.img-[B]4.15.0-15[/B]-generic

to look like this:

     linux    /[B]@Kubuntu_18.04[/B]/boot/vmlinuz-[B]4.15.0-20[/B]-generic root=UUID=8f0c1661-4e84-4512-b875-23bcfd5be1d8 ro rootflags=subvol=[B]@Kubuntu_1804[/B]
     initrd    /[B]@Kubuntu_18.04[/B]/initrd.img-[B]4.15.0-20[/B]-generic

I only had to change "@KDEneon" to "@Kubuntu_1804" in three places and correct the kernel version number in two. I had forgotten to note the kernel version that was installed with Kubuntu 18.04 before I rebooted, but no big deal - while in the grub menu, pressing F2 brings up the grub console, where I could "ls" my way into "@Kubuntu_1804/boot" and see the kernel version there.

Once I had successfully booted into @Kubuntu 18.04, I ran update-grub and created a grub.cfg. Then I mounted @grub at /mnt/grub, edited /mnt/grub/boot/grub/grub.cfg (my custom grub.cfg) and added a menuentry for Kubuntu 18.04. Now it boots just like the other six distros.

So even though you edited the @KDEneon grub.cfg and replaced that term with @Kubuntu_1804, etc., the Neon grub wasn't actually changed and still pointed to Neon on subsequent boots. Doing update-grub fixed its grub.cfg.

Now, would you let me play Biden and post your entire custom grub.cfg?

[oshunluvr]

Correct again, and certainly;

## 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 8f0c1661-4e84-4512-b875-23bcfd5be1d8
font="/@grub/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' {
    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 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    knetbsd /@grub/boot/memtest86+.elf
}
menuentry 'Memory test (memtest86+, serial console 115200)' {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 8f0c1661-4e84-4512-b875-23bcfd5be1d8
    linux16 /@grub/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###

[GreyGeek]

I just noticed that in your custom grub you set
set default='KDE Neon'

BUT, there is no menu entry with that exact name, so it will probably default to the first menu entry:

menuentry 'KDE Neon- It works!'

and thus "it works!" by accident?

[GreyGeek]

I attempted the first part of the multi-boot process:
Sudo -i to root.
Mount -t btrfs /dev/sda1 /mnt
Cloning @ and @home to @Neon1604 and @Neon1604home, and @ to @grub.
I edited @Neon1604/etc/fstab to change /@ to /@Neon1604 and @home to @Neon1604home.

I mv'd @ to @old and @home to @homeold.

I edited /mnt/@Neon1604/boot/grub/grub.cfg to change all lines which contain "...rootflags=subvol=@' to "...rootflags=subvol=@Neon1604".

At this point the instructions suddenly became vague. Upgrade-grub now? The instructions didn't say to update grub at this point. They only say that "Rather miraculously this setting will be preserved when I DO update-grub".

I updated grub. Checking the grub.cfg settings I found that all rootflags changes had reverted back to /@.

I booted into my Neon LiveUSB stick and mounted /dev/sda1 and edited grub.cfg. I changed them back to /@Neon1604.

I rebooted and was thrown into <grub rescue> with the error that "/@/....bold-16.pf2" could not be found. With my LiveUSB stick I fixed that and all other occurances of /@/, of which there are many.
I rebooted.
I was greeted with grub rescue again.

In grub rescue> I did:
set prefix=(hd0,1)/@Neon1604/boot/grub
set root=(hd0,1)
insmod normal
normal


At that moment I booted into my Neon installation.
I didn't have to do:
insmod linux
linux /@Neon1604/boot/vmlinuz-4.8.0-42-generic root=/dev/sda1
initrd /@neon1604/boot/initrd.img-4.8.0-42-generic
boot

Once my desktop appeared I opened a root terminal and issued "update-grub". It completed. Checking the /boot/grub/grub.cfg file I found that all changes of /@ to /@Neon1604 remained. Confidently, I rebooted.

I was again greeted with the grub rescue prompt. THIS TIME the error is
"error: file '/@/boot/grub/i386-pc/normal.mod' not found"

Searching through grub.cfg revealed no call to the i386-pc's folder. At this point I don't know where that call is coming from so I can't change it. A DDG search of the Internet revealed few links and none offered any help.

I redid the previous "set prefix", "set root", "insmod normal" followed by "normal" and was booted up to my desktop.

I know for sure that I am running in @Neon1604 and @Neon1604home because @ and @home no longer exist. They were replaced with @old and @homeold.

That's where I stand right now.

[jlittle]

At some point a grub-install is needed.

On BIOS systems the grub "core image" in the "MBR gap" has the location of the /boot/grub to use. That core image may be compressed, always if the gap is the usual 62 sectors, so a hex dump won't reveal it. "bootinfoscript" hasn't been updated for grub 2.02 so it doesn't give useful info.

In my EFI system the location of /boot/grub is baked into /boot/efi/EFI/ubuntu/grubx64.efi as I reported above. I don't know the correct incantation to get grub-install to set another install's location into grubx64.efi.

Now if your grub shell fu is strong, and you manage to boot into the install in @grub, then running grub-install from there will do the job I think. I think that's a cleverness in oshunluvr's method, exploiting the ease, speed, and minimal resource of btrfs snapshots to have a whole cloned OS to work with, then pruning it back to what's needed.

[Qqmike]

In my EFI system the location of /boot/grub is baked into /boot/efi/EFI/ubuntu/grubx64.efi as I reported above. I don't know the correct incantation to get grub-install to set another install's location into grubx64.efi.

jlittle, I'm not following this thread, nor do I know anything about btrfs. With that said then, you are correct that the location of the grub.cfg that the UEFI uses is hard coded into the efi GRUB executable. I don't know that you can easily hard code your own into the grubx64.efi. But, it may be possible to get what you want another way, using the --no-uefi-secure-boot option in the grub-install command. man grub-install mentions this option. I explain what I am able to explain in my how-to's, and I have tested it. Secure boot, of course, must be turned off. Fwiw, my scribbles are here:

https://www.kubuntuforums.net/showth...l=1#post412601

For example, scrolling down to

UEFI for Kubuntu--simplified. And ... some dual-booting tips for Kubuntu
https://www.kubuntuforums.net/showthread.php/43221-GRUB-2-A-Guide-for-Users/page13?p=373198&viewfull=1#post373198

and checking in SECTION 6 of that how-to:

Section 6: All about dual-booting, 5 ways to do it, how to fix it; creating separate EFI subdirectories for your (K)Ubuntu OSs (using --no-uefi-secure-boot option).; creating and using more than one ESP, changing labels on UEFI boot entries (useful for multiple "ubuntu" entries).

One more thing I noticed in this thread: When using EFI, grub-install defaults to the ESP that is being used by the OS you are booted into when you issued grub-install, and it goes to the default: /boot/efi. You can make it go to another mounted location using the option grub-install --efi-directory=DIR, where DIR is the mounted location of the ESP the OS was set up to use (so the default value of DIR is /boot/efi). With EFI, using the "root" directory option with grub-install, I don't think makes any sense (because the GRUB executables are placed in the ESP and are referenced that way by the EFI, the executables are not referenced in the root filesystem of the OS by the EFI firmware).

[GreyGeek]

My system uses msdos


I have no trouble using grub rescue or editing a menu option on the grub menu to set the proper path to “Linux” and “initrd” to allow bootup and login. My problem is that even though I change grub.cfg to point to @Neon1604 AND those changes survive update-grub, when I reboot grub menu always has “/@/boot...” instead of “/@Neon1604/boot...”.

I’ve used grub-install to switch between /dev/sda1 and /dev/sda, and have even made both bootable. Doesn’t matter, except that it shifted the failure point to “initrdms”.

I thought that perhaps my Btrfs was corrupted because of all the booting changes but a “btrfs check —repair /dev/sda1” showed that it was clean, no errors.

A copy of grub that is being used to display the grub menu is not being updated properly by update-grub (which I’ve also done by booting a LiveUSB of Bionic, mounting /dev/sda1 and chrooting into it).

No matter. I won’t lose anything because of archived snapshots and this will give me the incentive to make some hardware changes. I bought a new Toshiba 750GB HD a year ago and while exploring possible causes for this failure mode I discovered that the Toshiba has 16 Sectors that failed after only 580+ hours of on time. My two WD drives, with 5K hours each, still have 0 failures. I keep my archive drive spun down so I am going to make the Toshiba the archive drive.

What I haven’t decided yet is to install Bionic for the next five years or to continue to roll with Neon.

[jlittle]

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 found a way with EFI, following the spirit (IMO) of oshunluvr's method, with no new stuff.

My boot drive with btrfs is on /dev/sdc2, my only functional install is 18.04 bionic beaver installed in @_bionic and @home_bionic. I have the top level of /dev/sdc2 mounted in /mnt/top. And I have sudoedit set up.

1. Snapshot the bionic root to @grub: sudo btrfs subvolume snapshot /mnt/top/@_bionic /mnt/top/@grub.
2. Edit the fstab in the @grub subvolume to mount / to subvol=@grub with sudoedit /mnt/top/@grub/etc/fstab. Leave the /home mount as it is.
3. Add a grub entry in bionic to boot to @grub, by pasting the first "menuentry" block in /boot/grub/grub.cfg into /etc/grub.d/40_custom after the existing lines there, edit its name (to avoid confusion) and edit the linux and initrd lines to read
   

   linux	/@grub/vmlinuz root=UUID=c908b7ec-dc1d-4594-85e4-f62a9eb4e44e ro rootflags=subvol=@grub
   initrd	/@grub/initrd.img

   Note well that in two lines, there's three edits.
4. Run sudo update-grub. Now grub in the bionic install can boot to the cloned install.
5. Add the converse entry to /mnt/top/@grub/etc/grub.d/40_custom, with @_bionic replacing @grub in three places. Now grub in the cloned install can boot bionic, but we can't start it yet.
6. Reboot, and choose the entry named in step 3, and log in normally. Run findmnt to check that / is on subvol=@grub.
7. Run sudo update-grub to pick up the entry created in step 5.
8. Run sudo grub-install /dev/sdc. Now the EFI entry points at @grub.
9. Reboot, and choose the step 5 entry.

Now I can rejoin oshunluvr's instructions. I can hack away at /mnt/top/@grub/boot/grub/grub.cfg, like I did with my BIOS firmware computers knowing that an update-grub in any install won't change it. That grub.cfg can be much simpler, look the way I want it to, and with a configfile entry pick up the full grub menu in any install, just in case there's something needed there, like an older kernel.

Remaining to do:

• Clean up /mnt/top/@grub/boot/grub/grub.cfg. Remove the entries that boot into linux in @grub, as they'll shortly point nowhere.
• Prune /mnt/top/@grub back to just the boot directory.
• Remove the entry in step 3 above.

[Bings]

My system uses msdos
What I haven’t decided yet is to install Bionic for the next five years or to continue to roll with Neon.

Bionic is supported for three years not five.

I love this thread though, I'm going to be installing Bionic and btrfs on a new drive when I get it shortly. So, this is all great and useful reading

[GreyGeek]

Bionic is supported for three years not five.

I love this thread though, I'm going to be installing Bionic and btrfs on a new drive when I get it shortly. So, this is all great and useful reading

It's usual for hardware maintenance updates end in three years, BUT, software maintenance updates end in five years.
https://www.ubuntu.com/info/release-end-of-life

Like all of Oshunluver's threads, this one is also great, and very informative. For my hardware and configuration, unfortunately, the methodology does not work as well. Specifically, even though changes to config.cfg are preserved through an update-grub command, the actual grub menu that is displayed reverts back to /@/boot/grub/... and has to be edited manually to cause a successful boot. Equally unfortunate, reverting grub.cfg back to /@/ doesn't work and my /@Neon1604 settings are preserved. Without my grub fu I'd be dead in the water right now.

I don't consider the event a total loss, however, because I was intending to update my hardware config in the near future and this experience hastened that move and hardened the direction I am choosing.

Bionic is, by all reports, a stellar release, and I have no clue as to when Neon will be switching to 18.04. I suspect they are waiting till after the first 18.04 bug repair release, so its release may be months away.

Ergo, I will probably being installing Bionic within the next week or so.

[oshunluvr]

At some point a grub-install is needed.

Yes, as I showed in post #3

[oshunluvr]

I just noticed that in your custom grub you set
set default='KDE Neon'

BUT, there is no menu entry with that exact name, so it will probably default to the first menu entry:

menuentry 'KDE Neon- It works!'

and thus "it works!" by accident?

I thought I mentioned this eariler, but I put "It Works!" in the new btrfs grub partition custom grub menu so I could tell I was actually booting from it rather than one of the two grub partitions I had at the time. Once I saw the "It Works" in the menu I knew I was booting from the btrfs grub installation, I edited it out and deleted the former grub stand-alone partitions.

[oshunluvr]

Like all of Oshunluver's threads, this one is also great, and very informative. For my hardware and configuration, unfortunately, the methodology does not work as well.

Thanks, and yes, this thread details a very specific use-case.

It's useful only for booting multiple distros all installed to a single btrfs file system AND using a dedicated grub install to manage how they boot. The really neat thing is, if you are not now using a dedicated grub install but want to, and are currently using btrfs; you don't need to create a partition to use grub in this way.

I started using a dedicated grub partition almost a decade ago after the third time I wiped a distro from a partition that was "hosting" grub without first replacing grub . Back then, I wasn't yet using btrfs in the way I am now and it hadn't occurred to me to transition my dedicated grub partition to a dedicated grub subvolume.

Thanks again to jlittle and Qqmike for the suggestion and for contributing EFI info.

The one serious change I'd like to see in Ubiquity and in fact, to all installers, is to be able to select a subvolume name at install time when choosing btrfs as the installation format. This one change would save 80-90% of the work of doing multiple installs.