On Wed, 15 Jun 2022 11:35:41 +0200 Franck Bui <fbui@suse.de> wrote:
Hi,
udev has some code to keep backward compatibility with systems that might have been initialized with persistent storage symlinks (those located in /dev/disk/by-*) which later were considered broken or not accurate enough and thereby were renamed in order to have more reliable names. This is actually done by udev rules file /usr/lib/udev/rules.d/61-persistent-storage-compat.rules.
First of all if your system has /usr/lib/udev/compat-symlink-generation file installed and its content is "COMPAT_SYMLINK_GENERATION=2" then you can stop reading the rest of this email as your system is not affected at all.
Otherwise it would be nice to check whether your system is relying on compat symlinks by booting with the following option appended to the kernel command line: "udev.compat_symlink_generation=0".
If your system still boots and behaves as expected then your system probably doesn't rely on legacy symlinks.
Otherwise if your system doesn't boot properly with this option set then it likely means that some of your system config files (such as /etc/fstab) have references to one of these legacy symlinks.
To help finding and fixing them, reboot with the previous boot option removed and try to run the bash script available in the following git repo: https://github.com/fbuihuu/find-legacy-symlinks. Running the script (it doesn't take neither option nor argument) should list the legacy symlinks generated by udev and should tell whether they're included in either /etc/fstab or /etc/crypttab.
In case you need help to get rid of these symlinks, please open a bug report and assign it to "systemd-maintainers@suse.de".
Thanks.
Hi Franc, for me it is fine to drop those legacy symlinks as it is confusing when it should be persistent, but it is not in some cases. Just please check in your bash script also /etc/default/grub as those symlinks are often used in resume= parameter in bootloader and with wrong one annoying things happen. Thanks Josef