----- On May 28, 2021, at 4:56 PM, Remi Gauvin remi@georgianit.com wrote:

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

quoted

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?

I don't think so ...

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)

I try to follow your guide another time, and just before the reboot i will check
grub-mkrelpath to see if it has changed to @. If yes i will start grub-mkconfig, so that @ is set in the rootflags.
I will also check /boot/grub/grub.cfg.

I will keep you informed.

Thanks for your great help.

Bernd