Btrfs system wont boot from the default subvolume?

There is no real rollback mechanism in Btrfs during booting into a snapshot, but after booting, you have to manually restore it and then reboot again. That is Btrfs design, no matter which tool.

However, I created a new tool for fun, it allows “one-click” simple restore after booting into a snapshot and then reboot. Unfortunately rebooting twice.

1 Like

cool :slight_smile:

Its much the same as timeshift and/or snapper+btrfs-assistant, both have the ability to select a snapshot, hit restore/rollback, reboot.

The grub menu is for system death, so yea takes a little extra.

K, i shall take a look. thx.

Snapshots are subvolumes, but they are a special kind of subvolumes, and as I understand it, they cannot be set as the default subvolume due to the fact that they are snapshots of yet another subvolume.

The clue should be in the name of the snapshots. Snapshots have names starting with a period (“.”) — because they are hidden by default — whereas regular subvolumes have a name starting with an “@” character.

I don’t think btrfs cares whether it’s a read-only or read-write snapshots, you can make it the default either way. It’s up to you to decide how you want to deal with it, but it is supposed to boot from the default regardless of whether it’s read-only or read-write.

Programs like snapper deal with this by creating a read-write snapshot of the read-only snapshot that you choose to rollback to and then sets that as the default.

As long as you are aware that booting from a read-only snapshot is an interesting subject. There are a good few online posts regarding “btrfs booting from read-only snapshot”, I haven’t read any because I never intend to do it, but it seems it can be done.

You’re missing the point of what I am saying. I never mentioned anything about read-only snapshots versus writable snapshots. I was speaking of regular subvolumes versus subvolumes that are snapshots of another subvolume.

Likewise, there is also a distinct difference between booting from a subvolume and setting a subvolume as the default subvolume of the filesystem.

What the default subvolume is, is set in the btrfs filesystem itself. What you boot from is determined by the parameters passed to the kernel at boot-time.

1 Like

I believe you might be missing the point (although I’m very hesitant to even say those words to you). There is no difference between a snapshot and a subvolume except the convention that subvolumes are read-write snapshots.

BTRFS does not differentiate between them at all, it’s just the naming convention that we (or some apps) give them that even denotes any difference.

Yea, which is why i was trying to get to the bottom of what i needed to change in the grub/kernel settings at boot to get to to act in this way. I realize now that Arch is not setup this way.

Did you execute this step as mentioned at the Arch Wiki? :point_down:

I didn’t do an install, I used the update-grub as instructed elsewhere.

It’s all pretty academic now as I’ve moved on, but I did show that it works if you manually mount without mentioning the subvol=, it does indeed mount the default subvolume/snapshot. So there is no reason why is should not be able to boot from it if setup to do so.

sudo mount -U c863c9b5-d87a-4196-bdfb-5002d20e4ce0 /mnt                                                                                                  32 ✘ 

So it did work as intended, it’s just that within all the grub creation scripts there are commands deep down that set the boot back to /@ every time.

if you set the GRUB_CMDLINE_LINUX_DEFAULT and remove all reference to subvol=

GRUB_CMDLINE_LINUX_DEFAULT="root=UUID=c5bf86f84-a752-4841-bcba-21f873673765 quiet splash udev.log_priority=3"

after rebuilding the grub the /boot/grub/grub.cfg looks like below. even if you have set the /etc/default/grub to not use /@ or even have a subvol=

after an update-grub its back to having subvol=X and also things like linux /@/boot/vmlinuz- so also using /@ as path for linux & initrd

menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-5bf86f84-a752-4841-bcba-21f873673765' {
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 5bf86f84-a752-4841-bcba-21f873673765
        linux   /@/boot/vmlinuz-6.9-x86_64 root=UUID=5bf86f84-a752-4841-bcba-21f873673765 rw rootflags=subvol=@  quiet splash udev.log_priority=3
        initrd  /@/boot/intel-ucode.img /@/boot/initramfs-6.9-x86_64.img

I did find where it was being changed in /etc/grub.d/10_linux

case x"$GRUB_FS" in
        rootsubvol="`make_system_path_relative_to_its_root /`"
        if [ "x${rootsubvol}" != x ]; then
            GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
        rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
        bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"

but i was getting down deep in the weeds by then and decided to just leave it and move on. But i still believe that it could be done on Manjaro.

(These script snippets were collected from different places and so may not be accurate i.e. different UUIDs etc, but they are just for demonstration).

EDIT: interesting thread you linked, i might get the VM back up and try grub-install just for kicks.