Announcement

**oshunluvr** · Sep 05, 2023, 07:55 AM

Based on your description, you did it right. The first thing that pops into my mind is that maybe Debian doesn't use subvolumes by default and just installed the files somewhere.When BTRFS was newish some installers devs didn't get the subvolume thing at all.

I'm going to fire up a VM and see what Debian installs like.

**TwoFistedJustice** · Sep 05, 2023, 08:41 AM

I gotta learn that VM thing you do. It seems really useful...

**claydoh** · Sep 05, 2023, 09:02 AM

Originally posted by TwoFistedJustice View Post

I gotta learn that VM thing you do. It seems really useful...

That's just Virtualbox, VMWare, or Virt-manager.
I use Virt-manager because it seems to be more performant for me but it is less user-friendly up front.
Virtualbox is probably the easiest to use.

These tools are extremely useful for testing and trying things out before diving in to bare metal.

**oshunluvr** · Sep 05, 2023, 11:30 AM

I use VirtualBox for work and Virt-manager (QEMU/KVM) for play time.

I find VirtualBox easier to use but not as powerful or as fast as KVM. KVM is easier to break because I'm always messing about.

Mostly, when using multiple virtual monitors VirtualBox is much easier. Otherwise, QEMU/KVM is better IMO.

**GreyGeek** · Sep 05, 2023, 11:35 AM

When one chooses the manual HD configuration which is necessary in order to install BTRFS in Debian, the option to format can be avoided and the existing subvolume chosen. Debian does not use @ or @home but uses @rootfs instead, and no @home subvolme unless the user specifically adds it.
If, after installation, you mv @rootfs to @ and change /etc/fstab to show @ as the subvolume name the installation will fail to boot. You'll have to use grub-customizer. Since I don't use @home I didn't see the need to change @rootfs to @. My scripts do all my snapshot and subvol work anyway.

**oshunluvr** · Sep 05, 2023, 01:52 PM

I finally got around to trying this and I found what GG says to be true. The installer did in fact use the subvolume "@rootfs" for installation and no other subvolumes. I installed Debian Live 12.1.0-amd64 KDE ISO to a VM and it installed and booted just fine.

I can't guess a reason why your installation failed. Since the default subvolume name is not "@" like Ubuntu it should have installed just fine.

Fun fact: Assuming you do not have success with a re-attempted install I have done this:

Built a VM of an install to a BTRFS file system.
Did a "btrfs send..." to a file on a shared host folder.
Restored ("btrfs receive...") from the file to a btrfs file system.
Booted it.

I literally installed to a VM, tested it, and then copied it to bare metal and could boot it. I could see having some minor issues initially if you had some atypical network device or some other piece of hardware maybe not working, but it was a fun experiment. It was Ubuntu Server with no desktop environment so it was not a complex setup..

**TwoFistedJustice** · Sep 05, 2023, 05:30 PM

Okay, so I goofed. Here's how I goofed.

My system does indeed have the @rootfs subvolume, which I thought I hadn't seen before. So I cd'd into it. Then I cd'd into '/etc' to look around and found what appeared to be an exact copy of my base Kubuntu installation. Which I thought was weird, but Linux plus not-really-sure-what-I'm-doing means sometimes I just decide to be okay with being confused until I'm not.

Of course now I see my mistake. Did you?

I preceded 'etc' with a forward slash.

So I was in fact looking at my base Kubuntu system.

I should have cd'd into 'etc' without the forward slash.

So now to fiddle around and see if I can get it booting.

I still want to learn how to do VM stuff.

I'm sorry for goofing and wasting other people's time.

**oshunluvr** · Sep 06, 2023, 07:10 AM

Originally posted by TwoFistedJustice View Post

...
Of course now I see my mistake. Did you?

I preceded 'etc' with a forward slash.

So I was in fact looking at my base Kubuntu system.
...

Yeah, NONE of us have EVER done that, LOL

If you have @rootfs/boot/grub/grub.cfg IMO the easiest way to boot it is to add this to your Kubuntu /etc/grub.d/40_custom:

menuentry 'Debian 12' --class debian {
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root <YOUR UUID HERE>
configfile /@rootfs/boot/grub/grub.cfg
}

Then make 40_custom executable and run sudo update-grub. The next time you boot, you will have a menu entry that will load the Debian grub menu. That way when Debian updates it's grub menu, you will still boot it in the exact same way.

Note that I used "part_gpt" in there. If you're using MBR you would need to change that. If you're using compression on your btrfs file system, you might need to add that too like this:

insmod gzio

or whichever compression you're using. You can get hints about what to put in there by looking at the "10_linux" section of your Kubuntu /boot/grun/grub.cfg. The "insmod" lines generally should match up.

**GreyGeek** · Sep 06, 2023, 01:02 PM

Originally posted by oshunluvr View Post

I finally got around to trying this and I found what GG says to be true. The installer did in fact use the subvolume "@rootfs" for installation and no other subvolumes. I installed Debian Live 12.1.0-amd64 KDE ISO to a VM and it installed and booted just fine.

I can't guess a reason why your installation failed. Since the default subvolume name is not "@" like Ubuntu it should have installed just fine.

Fun fact: Assuming you do not have success with a re-attempted install I have done this:

Built a VM of an install to a BTRFS file system.
Did a "btrfs send..." to a file on a shared host folder.
Restored ("btrfs receive...") from the file to a btrfs file system.
Booted it.

I literally installed to a VM, tested it, and then copied it to bare metal and could boot it. I could see having some minor issues initially if you had some atypical network device or some other piece of hardware maybe not working, but it was a fun experiment. It was Ubuntu Server with no desktop environment so it was not a complex setup..

THAT is certainly going beyond the examples in the chapter and the practice problems at the end of the chapter!

**TwoFistedJustice** · Sep 06, 2023, 05:15 PM

Originally posted by GreyGeek View Post

THAT is certainly going beyond the examples in the chapter and the practice problems at the end of the chapter!

Yeah, it's not enough that he gets an A on every test, and does all the extra credit. He also has to get the Blue Ribbon at the Science Fair!

**TwoFistedJustice** · Sep 06, 2023, 08:32 PM

Originally posted by oshunluvr View Post

Then make 40_custom executable and run sudo update-grub. The next time you boot, you will have a menu entry that will load the Debian grub menu. That way when Debian updates it's grub menu, you will still boot it in the exact same way.

I tried this and it simply took me from Kubuntu's grub menu to Debian's grub menu and then into Debian, which I could also do from K's grub menu.

As I have it right now I can completely bypass Debians grub menu. If I have vmlinuz and initrd symlinks set up, which I do, does that not take care of proper booting after updates?

Here's what I have now for Debian, which includes Oshunluvr's script and the one I nicked from Debian's grub.cfg

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-577ea88b-941e-4d35-99bb-3dd3c85b0792' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod btrfs
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 577ea88b-941e-4d35-99bb-3dd3c85b0792
else
search --no-floppy --fs-uuid --set=root 577ea88b-941e-4d35-99bb-3dd3c85b0792
fi
echo 'Loading Debian 12'
linux /@rootfs/boot/vmlinuz root=UUID=577ea88b-941e-4d35-99bb-3dd3c85b0792 ro rootflags=subvol=@rootfs
echo 'Loading initial ramdisk ...'
initrd /@rootfs/boot/initrd.img
}

menuentry 'Debian 12' --class debian {
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 577ea88b-941e-4d35-99bb-3dd3c85b0792
configfile /@rootfs/boot/grub/grub.cfg
}

**jlittle** · Sep 06, 2023, 11:21 PM

Originally posted by TwoFistedJustice View Post

As I have it right now I can completely bypass Debians grub menu. If I have vmlinuz and initrd symlinks set up, which I do, does that not take care of proper booting after updates?

It does... until, one day, it doesn't. Once, in the last 12 years or so I've been using them, the location of the links was changed, and I think one of their names at the same time, "initrd" to "initrd.img". So having a way back to the generated, up to date, but also horribly bloated, grub.cfg could be a useful backstop, and also gives access to the previous kernels.

At first, I had an entry back to an install's generated grub.cfg so that I could keep the grub menu I used to boot short and clean, but I never really needed it.

In the interest of short and clean and simple, one can also change from the, IMO horrible and error-prone, UUIDs, to labels. My work laptop boots with this entry:

Code:

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

This has the advantage that it's somewhat portable; I just have to label the boot drive "main" when setting up a new system. I've got it on my Ventoy USB.

**oshunluvr** · Sep 07, 2023, 06:38 AM

I started using the 40_custom - nested grub menu - way because *buntus don't use the kernel/initamfs symlinks to boot, they use the actual kernel version. With 4 or more installs continual editing of the kernel versions in a single grub menu became onerous. This also has the added benefit of working with any grub based distro. I actually use a stand-alone GRUB installation (stripped down Ubuntu server) and it holds the grub menu links to the other installs.

Another little trick I use is to be able to boot directly to an ISO rather than creating an external boot device like a USB stick. My 40_custom also has this stanza:

Code:

menuentry 'Latest ISO download' --class iso {
   set isofile="/iso/latest.iso"
   loopback loop (hd2,2)$isofile
   linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
   initrd (loop)/casper/initrd.lz
}

hd2.2 points to a drive partition that is on a hard drive I use for backup storage. When I want to install a new release, I download the ISO there, rename it to "latest.iso" and boot to it. Note that the stanza may vary if the iso is not a *buntu or similar version.

I rarely do this anymore because I'm just not distro hopping like I used to.

**TwoFistedJustice** · Sep 07, 2023, 09:51 AM

So it sound like I should set my systems up to use labels, and to use the grub.cfg of the distro I am booting into in order to prevent an inadvertent boot-hijack at update.

Can I safely change the label on my current drive?

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

Announcement

Problem multi booting Debian with BTRFS

[MULTI BOOT] Problem multi booting Debian with BTRFS

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment