Announcement

**otisklt** · Jul 01, 2023, 10:21 PM

There are some good mulit-boot btrfs/grub resources here: https://www.kubuntuforums.net/forum/...trfs-subvolume

I would suggest trying a sudo update-grub command to see if it can pick up the Kubuntu and add it to the menu for you

**jlittle** · Jul 01, 2023, 11:43 PM

Assuming kali uses grub, and your system has booted into it.

Firstly, does the /etc/default/grub have this line:

Code:

GRUB_DISABLE_OS_PROBER=false

If not, or it is commented out, edit it so that it does, then run sudo update-grub.

The update-grub used to run the OS prober by default, but that was deemed to be a security risk, so now for it to run the weird double negative is needed.

However, with btrfs, I'm not sure the os-prober works.

So, another approach is creating the file /boot/grub/custom.cfg on kali with the contents:

Code:

menuentry 'Kubuntu from custom'  {
    search --no-floppy --set=root --label kubuntu
    linux /@/boot/vmlinuz root=LABEL=kubuntu ro rootflags=subvol=@
    initrd /@/boot/initrd.img
}

Grub these days checks for custom.cfg at boot time.

Now,

Each distro on a its own single partition

With btrfs this is not necessary; several distro installs can share one btrfs, and juggling free space by resizing partitions is obviated. A huge time saver. The different installs just have to use different subvolumes, with grub and /etc/fstab adjusted accordingly. IMO becoming up to speed with this approach is really good when problems occur; one can boot into snapshots to try things. At dist-upgrade time I usually have before and after bootable, and often keep an LTS going (that is, bootable and upgraded). Your install of kali suggests that you are the type of user that would benefit from this flexibility.

**TwoFistedJustice** · Jul 02, 2023, 08:38 PM

I've read Oshunluvr's posts on maintaining grub and multi-booting from a single btrfs partition. I played with it a bit in my skunky-funky kubuntu/kali install and ended up not being able to boot into either. So I wiped them and now I have one big btrfs partition with Kubuntu 22.04, alongside the original ESP and swap.

The short-short version of the steps to begin multi-boot from a single partition as I grasped them are:

1. Boot with live and rename @ and @home
2. Edit fstab to match new names
3. Edit /boot/grub/grub.cfg
4. Edit 40_custom
5. boot into system and run `update-grub`

With a 40_custom entry of:

Code:

menuentry 'MENU_ENTRY' {
  insmod btrfs
  set root='(hd0,Kubuntu22)'
  configfile /boot/grub/grub.cfg
}

One thing I found was that I could not edit grub.cfg from a live-usb. Which leads me to think I should edit the file that explicitly states that I should not edit it as step 1 with live-booting being step 2.

How am I doing?

**oshunluvr** · Jul 03, 2023, 06:32 AM

os_prober didn't work in the past with btrfs partitions other than the host partition because of the use of subvolumes prevented finding the kernel and initramfs files. This was identified as a bug quite awhile ago but I don't know if it was ever fixed.

In my view you have a few choices:

1. Leaving things as they are and:
Add Kubuntu to /etc/grub.d/40_custom like this:

Code:

menuentry 'Kubuntu 22.04' --class kubuntu {
   insmod part_gpt
   insmod btrfs
   search --no-floppy --fs-uuid --set=root <UUID FROM SDA3 HERE>
   configfile /@/boot/grub/grub.cfg
}

Obviously change the above if needed. For example, "@" is the default root subvolume so if you changed it in the Kubuntu install, you would need to change it here also. Also "insmod part_gpt" would need to be "insmode_mbr" if you're not using GPT (you should be IMO). Then make 40_custom executable and run update-grub. This should be maintenance free going forward as any time you do a kernel update to Kubuntu, it will update it's own grub.cfg. It won.t matter if Kali updated gr or not. This is also the easiest option to set up.

Other options include:

2. Moving the Kali subvolumes to SDA3 and booting from a single btrfs file system. This may require renaming subvolume(s).
3. Creating a third install to just handle booting.

The disadvantage to dual booting on a single disk is Kali currently "owns" grub. Thus if Kali becomes unbootable or you remove it, your entire system is not bootable. You could re-install grub from Kubuntu and flip the setyp but you're still in the same predicament of have a "one fail means all are failed" situation. This is why I use the third option.

Both the 2nd and 3rd options are more work to set up, but have advantages like taking advantage of the shared partition space made possible by the use of btrfs subvolumes.

The 3rd option is the most unlikely to leave you with an unbootable computer and adds the advantage of one more bootable OS to "fix" one of the others if need be. I use Ubuntu Server as my "grub" OS with no desktop at all, just console access. I set up it's grub menu to default to my primary OS with a 3 second menu window to change to another if I want to. Once it's set up, I need only update grub on the boot OS when I add or delete an install. I also have set up the ability to boot directly to many different ISOs. This makes it super easy to install a new distro or just try one out in a live session on bare metal.

**Schwarzer Kater** · Jul 03, 2023, 06:48 AM

Originally posted by oshunluvr View Post

os_prober didn't work in the past with btrfs partitions other than the host partition because of the use of subvolumes prevented finding the kernel and initramfs files. This was identified as a bug quite awhile ago but I don't know if it was ever fixed.
[…]

In e.g. openSUSE and Garuda it currently does work, in *Ubuntu and Debian it does not.

As Debian- and *Ubuntu-based systems are two of my three primary systems I use a custom.cfg in /boot/grub to be able to boot from systems that I installed on btfrs partitions.

**TwoFistedJustice** · Jul 03, 2023, 10:44 AM

How does one determine which install "owns" grub?

How can that ownership be changed?

**claydoh** · Jul 03, 2023, 12:11 PM

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.

**oshunluvr** · Jul 03, 2023, 12:20 PM

Originally posted by TwoFistedJustice View Post

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** · Jul 03, 2023, 12:41 PM

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.

**Schwarzer Kater** · Jul 03, 2023, 02:29 PM

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** · Jul 03, 2023, 02:41 PM

Originally posted by Schwarzer Kater View Post

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.

**Snowhog** · Jul 03, 2023, 03:19 PM

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

**jlittle** · Jul 03, 2023, 03:39 PM

Originally posted by TwoFistedJustice View Post

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

Code:

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.

**TwoFistedJustice** · Jul 03, 2023, 04:05 PM

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:

Code:

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:

Code:

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

Announcement

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment