Problem multi booting Debian with BTRFS

[oshunluvr]

The "Label" is what you can set. Strangely, my KDE Partition Manager looks different:


Note that mine says "Partition Name" rather than "Partition Label" - odd. If you are using GPT formatting, the Partition Label is editable. "Label" is the file system label.

I believe the label you want to set is actually the file system label because you actually mount the file system, not the partition. tune2fs can set it among a few other tools. I also believe it should be unmounted, but not 100% sure of that.

Then you can use "LABEL=..." in fstab or grub to mount.

[Snowhog]

Note that mine says "Partition Name" rather than "Partition Label" - odd.

Probably not 'odd'. You are running KDE neon, yes? My KDE neon also reports "Partition Name", but my Kubuntu 23.04 reports "Partition Label". Both are using btrfs.

[oshunluvr]

No doubt that's the difference. Still a bit odd as in why did they change it. I suppose having "Label" and "Partition Label" might confuse one who is unaware of the difference.

[jlittle]

So it sound like I should set my systems up to use labels,

I should point out that using labels rather than UUIDs has critics. I've encountered the attitude "Red Hat advises the use of UUIDs, so any other practice must be stupid". One has to set the labels carefully, and ensure they are unique within a system. Someone could easily put a label on a USB drive to cause trouble, but I imagine the same is true of UUIDs, perhaps not so easily. For me the readability of /etc/fstab and so the reliability of changes to it is the most important consideration, in my painful experience.

and to use the grub.cfg of the distro I am booting into in order to prevent an inadvertent boot-hijack at update.

I don't quite get "prevent an inadvertent boot-hijack at update". I see it as giving options when there's problems.

Can I safely change the label on my current drive?

As far as I am aware, and after a quick web search, yes.

And also, here we see "label" and "partition label". Which of those should I change?

Confusingly, GPT has "file system" labels and "partition" labels. The file system label is what a lot of people, perhaps most, call the "partition" label, and is referred to as the LABEL in /etc/fstab, grub.cfg, and blkid output. The other can be referred to as PARTLABEL, and it is often used as a description. I suspect that the difference in the column heading between Kubuntu and Neon that oshunluvr reports is an attempt to reduce this confusion. I suggest using sudo blkid if clarification is needed.

[oshunluvr]

I don't quite get "prevent an inadvertent boot-hijack at update".

I think the reference might be toward my comment about *buntus not using the /boot symlinks and instead using the kernel version in grub stanzas.

For clarification for those interested: Many distros (and even Ubuntu in the past IIRC) use symlinks to boot to the current and/or one previous kernel version and it's associated initramfs image. Currently *buntus do not.

What this means is in grub.cfg was your boot stanza might look like:

menuentry 'Neon GNU/Linux' --class neon --class gnu-linux --class gnu --class os {
       insmod part_gpt
       insmod btrfs
       search --no-floppy --fs-uuid --set=root 5964f1aa-2e8e-48e1-a3e3-f2069bd6217c
       linux   /boot/vmlinuz root=UUID=5964f1aa-2e8e-48e1-a3e3-f2069bd6217c ro quiet splash
       initrd  /initrd.img
}​

instead of:

menuentry 'Neon GNU/Linux' --class neon --class gnu-linux --class gnu --class os {
       insmod part_gpt
       insmod btrfs
       search --no-floppy --fs-uuid --set=root 5964f1aa-2e8e-48e1-a3e3-f2069bd6217c
       linux   /boot/vmlinuz-6.2.0-32-generic root=UUID=5964f1aa-2e8e-48e1-a3e3-f2069bd6217c ro quiet splash
       initrd  /initrd.img-6.2.0-32-generic
}​

Note the second one has the actual kernel version instead of the symlinks "vmlinuz" and "initrd.ing".

If one were to attempt using the second stanza in a different installations /etc/grub.d/40_custom, a kernel update in the second distro would cause it to be unbootable until 40_custom was also updated and update-grub was executed. Using the symlinks revents having to continuously update 40_custom in your primary install when dual booting.