----- On May 27, 2021, at 10:41 PM, Remi Gauvin remi@georgianit.com wrote:

On 2021-05-27 3:37 p.m., Lentes, Bernd wrote:

quoted

i followed your guide and tried a reboot remotely.
PC stuck in BIOS, someone in the office pressed F2, and system booted
completely.
But unfortunately in the bad system and without X:

root@pc65472:~# mount|grep btrfs
/dev/mapper/vg1-lv_root on / type btrfs
(rw,relatime,ssd,space_cache,subvolid=257,subvol=/@_bad)

This is interesting, because your system is mounting the old subvolume
as root and not the new @.

Check the /etc/fstab, (maybe it would be wise to post it here.).  Maybe
at some point, someone replaced the default 'subvolume=@' with a
subvolid=257?

root@pc65472:~# less /etc/fstab
 ...
/dev/mapper/vg1-lv_root /               btrfs   defaults,subvol=@ 0       1
/dev/mapper/vg1-lv_root /home           btrfs   defaults,subvol=@home 0       2
/dev/sdb1               /data           btrfs   defaults,subvol=@data 0       2
UUID=68dc5e68-fc44-4163-bd75-537adf9f1266 /local          btrfs   defaults        0       0

seems to be ok

If that's the case, you should also check the /boot/grub/grub.cfg and
verify that the kernel boot options specify: rootflags=subvol=@

root@pc65472:~# grep -i '@_bad' /boot/grub/grub.cfg
    font="/@_bad/usr/share/grub/unicode.pf2"
        linux   /vmlinuz-4.4.0-66-generic root=/dev/mapper/vg1-lv_root ro rootflags=subvol=@_bad  splash=verbose   <=== !!!!
                linux   /vmlinuz-4.4.0-66-generic root=/dev/mapper/vg1-lv_root ro rootflags=subvol=@_bad  splash=verbose   <=== !!!
                linux   /vmlinuz-4.4.0-66-generic root=/dev/mapper/vg1-lv_root ro recovery nomodeset dis_ucode_ldr rootflags=subvol=@_bad

I'm hesitating to manipulate grub.cfg directly, because of:

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#


interesting:
root@pc65472:/etc/grub.d# grep -i rootflags /etc/grub.d/*
/etc/grub.d/10_linux:       GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"    <=== the culprit ?


/etc/grub.d/10_linux:
 ...
case x"$GRUB_FS" in
    xbtrfs)
        rootsubvol="`make_system_path_relative_to_its_root /`"
        rootsubvol="${rootsubvol#/}"
        if [ "x${rootsubvol}" != x ]; then
            GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
        fi;;
 ...

grub-mkconfig_lib: (is sourced in /etc/grub.d/10_linux)
make_system_path_relative_to_its_root ()
{
  "${grub_mkrelpath}" "$1"
}

if test "x$grub_mkrelpath" = x; then
  grub_mkrelpath="${bindir}/grub-mkrelpath"
fi

There is a binary "grub-mkrelpath":

root@pc65472:~# which grub-mkrelpath
/usr/bin/grub-mkrelpath
root@pc65472:~# grub-mkrelpath -?
Usage: grub-mkrelpath [OPTION...] PATH
Transform a system filename into GRUB one.

  -?, --help                 give this help list
      --usage                give a short usage message
  -V, --version              print program version

root@pc65472:~#
root@pc65472:~# grub-mkrelpath /
/@_bad  <=== !!!

grub-mkrelpath gives @_bad back, that's the problem. What can i do ?

That doesn't really explain why X wouldn't be working.,,, or why
pressing F2 did anything,, (that would indicated the Bios is
experiencing some kind of error?)

Problem with the BIOS existed already. Problem with X is not severe.
Important is to rollback to the snapshot.

Bernd