On 2021-05-28 10:33 a.m., Lentes, Bernd wrote:

quoted

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
#

It's relatively safe to edit the grub.cfg directly... Just be aware that
next time something runs update-grub, your changes will not persist.

But here, the question I'm left with, is why your grub.cfg changed
between the time you renamed the subvolumes and rebooted... You might
have something that does, in fact, execute an update-grub on shutdown?

You can try editing the grub.cfg and reboot and see if that fixes the
problem... but if it reverts to @_bad, you'll either have to
find/disable the script that is updating grub, or change it at boot time
interactively, (which means, needs boots on the floor)