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

[jlittle]

I tried this out with Kali and it doesn't (quite) work. Kali needs a wildcard character tacked to the end. i.e.

linux /@kali/boot/vmlinuz*
initrd /@kali//boot/initrd.img*

Cool, good to know. I suspect that's not using a symlink but relying on grub to find something to boot; maybe if there are several kernels present you might not get the most recent.

Different distros use different names, and Ubuntu changed the location and name some years ago. For example, when I last installed Gentoo it called the linux executable "kernel" and the initial RAM disc "initramfs". If booting an Ubuntu from an iso the linux is still "vmlinuz" but the initial RAM disc is just "initrd". One can always look in the boot directory (mounting from a live USB) to see what's there.

There are several projects that compile how to boot distros, including Ventoy.

[TwoFistedJustice]

Cool, good to know. I suspect that's not using a symlink but relying on grub to find something to boot; maybe if there are several kernels present you might not get the most recent.

Different distros use different names, and Ubuntu changed the location and name some years ago. For example, when I last installed Gentoo it called the linux executable "kernel" and the initial RAM disc "initramfs". If booting an Ubuntu from an iso the linux is still "vmlinuz" but the initial RAM disc is just "initrd". One can always look in the boot directory (mounting from a live USB) to see what's there.

There are several projects that compile how to boot distros, including Ventoy.

I did a little file renaming to see how Kali would react. On my Kali system I have two kernels: 6.1 & 6.3. I check the kernel version with 'uname -r'

With the * syntax it chose 6.3 over 6.1

I thought it might just be globbing and since the file names are identical up to the second digit it simply chose based on ascii ordering.

I copied all the 6.1 files and renamed them by inserting an "A". So instead of "vmlinuz-6.1 ..." it changed to "vmlinuzA-6.1 ..."

When I rebooted, Kali started up fine and the running kernel version was 6.3. So it ignored my renamed file and chose the latest version.

Then I considered that it might be looking inside the file and getting the version number that way. So I renamed my "A" files like "vmlinuz-6.4" (these were actually 6.1). After restart the kernel version showed as 6.1.

So it must have chosen based on the version in the file name.

[TwoFistedJustice]

You should combine your posts into one NEW contiguous step-wise explanation on how to set up a multi-boot system from scratch using what you've learned.
oshunluvr could then make it sticky.

If oshunluvr agrees I'll be happy to do the write up.

Given the complexity of the process (even though it's not actually THAT hard to do once you get into it ) I would suggest that rather than starting with a new thread which has a long string of corrections and commentary beneath it, as is likely to be the case, I begin it with a markdown file in a public github repo and we manage it from there. Then once it's satisfactory port it over here and make it a sticky. That way the space beneath the sticky is open for questions from those who come after. Then they don't have to dig through multiple pages of sub-posts to get help.

It also has the advantage of being easily accessed by people using other distros outside our little Kububble.

Thoughts?

[jlittle]

... a public github repo ...

A good idea, but that's a commitment...

It also has the advantage of being easily accessed by people using other distros outside our little Kububble.

In the past Google has been very good at sending searchers in to kubuntuforums.net, not on the scale of the Arch wiki but similar. I wonder if that is still the case.

[TwoFistedJustice]

A good idea, but that's a commitment...

IMO it would actually be pretty easy to write a quality how-to that way because github has excellent feedback tools which make suggestions easier to track and implement than a forum thread does. Then there's the advantages git itself provides of branching and reversion.

[TwoFistedJustice]

I've begun a thorough step by step write up for EFI. For now it's on github and mostly unformatted. It's quite long and I still have a ways to go.

Feel free to comment either here or there, whichever suits your methods better.

The public github repo is here: Better Multi-Booting with BTRFS and Linux

Does this forum have the ability to support posts in markdown?

[Schwarzer Kater]

[…]
Does this forum have the ability to support posts in markdown?

I did not find that, but I was able to copy/paste the Markdown output and it was formatted the right way.

[TwoFistedJustice]

I did not find that, but I was able to copy/paste the Markdown output and it was formatted the right way.

I'm not seeing that. Here's what I get:

## Common terminal commands we will use:

"Update grub" means open a terminal and type in the following commands:
```shell
sudo grub-mkconfig
sudo update-grub
```
Renaming files use the move command with sudo.
```shell
sudo mv oldname newname
```


[EDIT]

I just checked vBulletin forum and they say they don't support it:

[Schwarzer Kater]

-----

High Level Overview of Phases

1. Partition Drive
2. Install primary OS (recommend ubuntu variant)
3. Rename subvolumes and configure primary OS
4. Install Second OS (any Linux distro)
5. Rename subvolumes and configure secondary OS
6. Boot into and configure primary OS (again)

What you will need: A bootable USB (recommend Etcher on Linux, Rufus on Windows) with Kubuntu LTS An empty SSD or hard drive, preferably one that never had Windows installed on it (Windows leaves things behind...).

Common terminal commands we will use:


"Update grub" means open a terminal and type in the following commands:

sudo grub-mkconfig sudo update-grub


Renaming files use the move command with sudo.

sudo mv oldname newname


Making a backup copy - use the copy command and add a tilde to the copy name:

sudo cp filename filename~

Phase 1 - Drive Partitioning -- A very sparse overview

-----

-> For a test I just marked the above part from your instructions (thank you, by the way!) with my mouse and copied/pasted it ("Paste", not "Paste without …") and obviously the Markdown layout from your GitHub page was only partly used.

It did work with the Markdown output from my GitLab page, though (I did do that with the Readme part of my scripts - see e.g. the first link in my signature for the outcome in this forum and compare it to https://gitlab.com/scripts94/kubuntu-get-rid-of-snap: not exactly the same but quite close. I had to do some editing afterwards, but it was minimal).

[TwoFistedJustice]

-----

-> For a test I just marked the above part from your instructions (thank you, by the way!) with my mouse and copied/pasted it ("Paste", not "Paste without …") and obviously the Markdown layout from your GitHub page was only partly used.

It did work with the Markdown output from my GitLab page, though (I did do that with the Readme part of my scripts - see e.g. the first link in my signature for the outcome in this forum and compare it to https://gitlab.com/scripts94/kubuntu-get-rid-of-snap: not exactly the same but quite close. I had to do some editing afterwards, but it was minimal).

You're welcome! It's mostly finished. I need to follow through it again to make sure I didn't miss or botch anything. Feedback is welcome.

I think the forum isn't really interpreting markdown. I suspect when you copy the formatted screen output, it pastes as Rich Text or similar. So it doesn't pick up MD tables or back tics.

[Snowhog]

I suspect when you copy the formatted screen output, it pastes as Rich Text or similar.

I think that is correct.

[TwoFistedJustice]

The write up is essentially complete. I'm sure it needs some revisions. I have yet to redo my test system. And of course since I wrote it, I will no doubt overlook some of the bits that are less clear or maybe even wrong.

I'm unclear about partition names/labels. And I'm also not certain of the optimal size for the EFI partition. My test system shows that I'm only using about 6 out of 550 MB. So despite it being Rod Smith's recommendation for 550 MB, I find myself dubious.

I'd appreciate any feedback you all can provide.

If you approve of the write up and you have a github account, please consider starring it so it will go higher in the rankings.

Here's the link:

https://github.com/TwoFistedJustice/...TRFS-and-Linux

[Schwarzer Kater]

[…]
And I'm also not certain of the optimal size for the EFI partition. My test system shows that I'm only using about 6 out of 550 MB. So despite it being Rod Smith's recommendation for 550 MB, I find myself dubious.
[…]

The usual name I have come across is "EFI System Partition" or "EFI system partition".

35 MB seems a bit small for an EFI partition - one could easily run out of space if one installs 4-5 or more different systems with secure boot enabled and different naming of their directories within /boot/efi/EFI (as it should be) - on one of my EFI partitions more than 60 MB are used…
100 MB should be a safe bet for a minimum size (that is the size a Windows installation usually creates IIRC).

But I prefer >300 MB - only because occasionally I have come across Linux installers that complain if it is smaller than that (for whatever technical reason). So I always recommend 304 or 320 MB nowadays.

500 MB or more is a waste of space IMHO, unless one installs really many systems (40-80) including boot loaders, and 500 MB is too small if this was for /boot (and not only /boot/efi).

[TwoFistedJustice]

I updated based on your suggestions Schwarzer Kater. Thank you!

[oshunluvr]

I tried this out with Kali and it doesn't (quite) work. Kali needs a wildcard character tacked to the end. i.e.

linux /@kali/boot/vmlinuz*
initrd /@kali//boot/initrd.img*

After setting this up I updated from 6.1 to 6.3, ran uname -r and confirmed that it used 6.3.


[EDIT]

Contents of @kali/boot


drwxr-xr-x 1 root root 644 Jul 14 14:26 .
drwxr-xr-x 1 root root 258 Jul 13 15:43 ..
-rw-r--r-- 1 root root 258800 May 12 11:20 config-6.1.0-kali9-amd64
-rw-r--r-- 1 root root 262471 Jun 29 05:05 config-6.3.0-kali1-amd64
-rw-r--r-- 1 root root 258800 Jul 14 14:11 config-6.4.0-kali1-amd64
drwx------ 3 root root 4096 Dec 31 1969 efi
drwxr-xr-x 1 root root 106 Jul 13 15:43 grub
-rw-r--r-- 1 root root 76430800 Jul 8 18:37 initrd.img-6.1.0-kali9-amd64
-rw-r--r-- 1 root root 79739435 Jul 13 15:44 initrd.img-6.3.0-kali1-amd64
-rw-r--r-- 1 root root 76430800 Jul 14 14:11 initrd.img-6.4.0-kali1-amd64
-rw-r--r-- 1 root root 83 May 12 11:20 System.map-6.1.0-kali9-amd64
-rw-r--r-- 1 root root 83 Jun 29 05:05 System.map-6.3.0-kali1-amd64
-rw-r--r-- 1 root root 83 Jul 14 14:12 System.map-6.4.0-kali1-amd64
-rw-r--r-- 1 root root 7976256 May 12 11:20 vmlinuz-6.1.0-kali9-amd64
-rw-r--r-- 1 root root 8983392 Jun 29 05:05 vmlinuz-6.3.0-kali1-amd64
-rw-r--r-- 1 root root 7976256 Jul 14 14:11 vmlinuz-6.4.0-kali1-amd64

Obviously Kali does not use the vmlinuz/initrd.img symlinks like *buntus do. So 6.4 is there but you're booting 6.3? Or did you update between posts?