[SOLVED] Need help setting up multi-boot with btrfs

[oshunluvr]

Sounds like a typo somewhere. Can you post your edited files? grub.cfg and fstab

Or it might be something to do with EFI as I don't use that.

[oshunluvr]

Yeah, that write up was 2012!!! Guess I've been here awhile.

As John pointed out, using the actual kernel version means you have to continually update 40_custom unless you use the vmlinuz and initrd.img links instead.

I, as John still does I think, use the grub config menu from each install to avoid having to do any updating to 40_custom at all:

menuentry 'KDE Neon 22.04' --class kdeneon {
insomd part_gpt
insmod btrfs
insmod gzio
search --no-floppy --fs-uuid --set=root 5964f1aa-2e8e-48e1-a3e3-f2069bd6217c
configfile /@KDEneon_2204/boot/grub/grub.cfg
}

[Snowhog]

I've been trying to use oshunluvr's tutorial on multi-booting from a single partition.

That information was written over ten years ago, so things may have changed. Best to let oshunluvr chime in.

[TwoFistedJustice]

After my first attempt I wiped the drive and started fresh with new EFI, swap, and btrfs partitions.

I've been trying to use oshunluvr's tutorial on multi-booting from a single partition.

I've followed it twice from clean installs and both times I end up stuck at the grub> prompt. The best I've been able to manage from there is to get stuck at the (initramfs) prompt.

I'm guessing that there is something else to do that has either changed since the last update to the tutorial or was omitted, or I just missed something.

I changed:

• /etc/fstab
• /boot/grub/grub.cfg
• /etc/grub.d/40_custom
• @ => @ku
• @home => @ku_home

( I used Kate with find and replace for config-file edits, and manually double checked the results )

I've hit the wall of my knowledge and am out of ideas for now.

Does anyone have any ideas?

Some things I noted:

• At grub> , $prefix is still set with the '@'. Changing it to '@[name]' still gets me stuck at (initramfs).
• Point 4 in the tutorial is unclear. Are we supposed to add a leading forward slash when we change the name in grub.cfg to '/@somename'? (this is how I interpreted it, but am uncertain if that was what was meant as it's written in the passive tense)

[jlittle]

After renaming my subvolumes @ and @home to @kubuntu and @home_kubuntu, when editing grub.cfg should I be doing something like this?
...
and change the last two lines to this:

185 │ linux /@kubuntu/boot/vmlinuz-5.19.0-46-generic root=UUID=[MY-UUID] ro rootflags=subvol=@kubuntu quiet splash $vt_handoff
186 │ initrd /@kubuntu/boot/initrd.img-5.19.0-46-generic
​

That will work till the next kernel update. I suggest

linux /@kubuntu/boot/vmlinuz root=UUID=[MY-UUID] ro rootflags=subvol=@kubuntu quiet splash $vt_handoff
initrd /@kubuntu/boot/initrd.img
​​

APT maintains links in /boot that point at the latest and next latest kernels and initrd.img.

I presume you're aware that if you've modified the grub.cfg that says "do not edit this file" it will be overwritten by the next update-grub (even if you uninstall grub-efi-amd64). Either put the lines in custom.cfg, or name the file something different (say, my_grub.cfg) and change the /boot/efi/EFI/ubuntu.cfg to point to it (assuming no secure boot and a grub that uses it).

When I adopted the independent grub approach I added an entry to get back to the standard grub, which for you would be (untested, naturally):

menuentry 'Advanced options for Ubuntu' {
    search --no-floppy --fs-uuid --set=root [MY-UUID]
    set prefix=($root)/@kubuntu/boot/grub
    configfile $prefix/grub.cfg
}
​

but as it turned out I think I used it once in over 10 years, so now I don't bother. But I always have a bootable USB handy.

[TwoFistedJustice]

I changed all the @ to @kubuntu and all the @home to @kubuntu_home in grub.cfg, fstab, and renamed the subvolumes using mv. I made the entry to 40_custom per oshunluvr's instructions.

On reboot I ended up at the grub> menu.

I poked around a bit in there and found the subvolumes prefixed with / which reminded me of point #4. So I went back and re-edited all the files to add the forward slash.

I ended up again at grub>

It seems the prophecy has come true. All the confusing confusions confused further the already confused.

[TwoFistedJustice]

After renaming my subvolumes @ and @home to @kubuntu and @home_kubuntu, when editing grub.cfg should I be doing something like this?


Take an entry such as:

171 │menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-73ffa900-dca2-47f2-9e0b-f8c1942ef918' {
172 │ recordfail
173 │ load_video
174 │ gfxmode $linux_gfx_mode
175 │ insmod gzio
176 │ if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
177 │ insmod part_gpt
178 │ insmod btrfs
179 │ set root='hd0,gpt2'
180 │ if [ x$feature_platform_search_hint = xy ]; then
181 │ search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 [MY-UUID]
182 │ else
183 │ search --no-floppy --fs-uuid --set=root [MY-UUID]
184 │ fi
185 │ linux /@/boot/vmlinuz-5.19.0-46-generic root=UUID=[MY-UUID] ro rootflags=subvol=@ quiet splash $vt_handoff
186 │ initrd /@/boot/initrd.img-5.19.0-46-generic
187 │ }
​

and change the last two lines to this:

185 │ linux /@kubuntu/boot/vmlinuz-5.19.0-46-generic root=UUID=[MY-UUID] ro rootflags=subvol=@kubuntu quiet splash $vt_handoff
186 │ initrd /@kubuntu/boot/initrd.img-5.19.0-46-generic
​

[jlittle]

How does one determine which install "owns" grub?

It's normally the last to be installed (some installers let you turn off the installation of a boot loader; to do that with ubiquity one can run it with the -b switch.)

How can that ownership be changed?

The last install to run update-grub takes ownership of the boot. update-grub may be run during normal updates, particularly if there's a new linux kernel. It's somewhat unpredictable, and hidden from the user if Discover is used for the updates.

The other posters have suggested using efibootmgr, and I think that's a good suggestion, but it won't tell between various grub installations of Ubuntu variants. For some versions of grub, and without secure boot, the file that counts is /boot/efi/EFI/ubuntu/grub.cfg. I think it's always there, and says where the boot goes, but with secure boot editing it may not work, the location of where the boot goes might be baked into a signed image.

IMO with multiple installs this a failed boot waiting to happen; "braindamage" (an old Unix term).

A solution is to designate which grub install should be the controller and uninstall grub and any other boot loaders in the others. A more flexible approach is to only uninstall the package grub-efi-amd64. Note just that package; the "details" for it says "Installing this package indicates that this version of GRUB should be the active boot loader."

sudo apt install grub-efi-amd64-bin
sudo apt remove grub-efi-amd64

The first is just to mark the package as "manually installed", so that the subsequent removal doesn't take it out.

Another approach is to make a stand-alone grub, independent of any particular distro and install. That's what I do on my desktop and IMO it's far, far less time and effort that way. All that update-grub machinery caused trouble and failed boots so often. One takes on updating it, but there's a couple of simplifications possible that makes the need for updating infrequent; I've gone years without having to make a change.

[Snowhog]

We try not to: Confuse the confused with confusing confusions.

[claydoh]

Oh, I can confuse even more…

Problems can occur when you use two or more distributions that are based on the same "parent" distro, like e.g. Kubuntu 22.04 and Kubuntu 23.04 are both based on Ubuntu, and you use the same EFI partition for them.

I purposely skipped that one for the moment, to lessen the amount of confusing confusions in one post.

That and my break was ending.

[Schwarzer Kater]

Oh, I can confuse even more…

Problems can occur when you use two or more distributions that are based on the same "parent" distro, like e.g. Kubuntu 22.04 and Kubuntu 23.04 are both based on Ubuntu, and you use the same EFI partition for them.
In this scenario GRUB (- in most cases unless the distribution has explicitely changed that) will install files of the same name in the "ubuntu" directory in your EFI partition and overwrite the files from the other Ubuntu-based system when writing to /boot/efi.
(This is one of the reasons why I have a seperate EFI partition on each of my three internal drives.)

TwoFistedJustice - don't let this post confuse you, sorry - it is not important for you:
-> This should not be the case for the OP, though, as Kali Linux is based on Debian and Kubuntu is based on Ubuntu and therefore there will be both a "debian" (or even "kali"?) and an "ubuntu" directory in a single EFI partition.

[claydoh]

Not an expert, but I grok it enough to get myself in trouble 😵💫

Each separate distro will have it's own separate Grub, with separate bootloader files in the EFI partition. Your boot order preference in the bios determines which bootloader you get.

The confusing part is that each grub is capable of booting all the other OS installs (if each has the OS prober option enabled). It doesn't help that grub decided to disable os-prober for valid security reasons, but they never have developed a proper way to fix or replace this, I guess

efibootmgr can change the boot order in the bios so you don't need to reboot to change this.

Windows updates have been known to change the boot order using whatever its equivalent to efibootmgr is.

[oshunluvr]

How does one determine which install "owns" grub?

How can that ownership be changed?

sudo efibootmgr -uv
may reveal which distro installed grub. Generally, the last distro you installed will have installed it's version of grub on SDA. Based on the info you provided above I assume Kali is the grub "owner". One clear indicator is whatever distro is first in the boot menu is the distro that installed grub last.

To change the "owner", boot into that distro and run "sudo grub-install"

I'm not an EFI expert, so Claydoh's info over rides mine in this regard.

[claydoh]

Each os has its own bootloader, so you'll have multiple grubs. You choose which one to use as the "main" one based on your boot device selection in your bios.

One thing to keep in mind that grub is usually only updated during kernel updates, but grub changed it's default actions for this and doesn't probe for new OS installs automatically any more, in most distros. You may want to enable this in your main grub so that it sees both new OS installs as well as existing installs with new kernels, if you have any issues booting other grub selections in your selected boot device.

You can always always use your system's hotkey for boot options to select the desired OS to load.

[TwoFistedJustice]

How does one determine which install "owns" grub?

How can that ownership be changed?