[RFC] Dropping support for legacy persistent storage symlinks
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.
On 2022-06-15 11:35, Franck Bui 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".
I know I use those symlinks, as we were told to use them instead of device names. If they are going to go, what should we use instead in fstab and other files? VERY CONFUSED. Looking on this machine only: fstab: LABEL=ssd-swap swap swap defaults 0 0 cryptotab: cr_cripta /dev/disk/by-uuid/dbdb68a9-7af4-499b-8df3-c95d1dde9626 \ none none I don't have access to all my computers this moment, but I can look up more examples. cr_cripta /dev/disk/by-partlabel/ssd_home_cr none none -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 15.06.22 um 11:35 schrieb Franck Bui:
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.
Why should they be "legacy"? Who did decide this? I used them for 20 years now, they are recommended to use like this on many openSUSE wiki pages, and I had never problems with such links. And they were always stable for me. Why should they be "not stable" or "not accurate"? Hmm, Manfred
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.
On 15.06.2022 19:15, Manfred Schwarb wrote:
Am 15.06.22 um 11:35 schrieb Franck Bui:
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.
Why should they be "legacy"? Who did decide this? I used them for 20 years now, they are recommended to use like this on many openSUSE wiki pages, and I had never problems with such links. And they were always stable for me.
Why should they be "not stable" or "not accurate"?
This is probably misunderstanding. It is only about some links generated by /usr/lib/udev/rules.d/61-persistent-storage-compat.rules You can read this file to check whether you ever used these links at all.
Hmm, Manfred
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.
On Wed, 2022-06-15 at 20:07 +0300, Andrei Borzenkov wrote:
On 15.06.2022 19:15, Manfred Schwarb wrote:
Am 15.06.22 um 11:35 schrieb Franck Bui:
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.
Why should they be "legacy"? Who did decide this? I used them for 20 years now, they are recommended to use like this on many openSUSE wiki pages, and I had never problems with such links. And they were always stable for me.
Why should they be "not stable" or "not accurate"?
This is probably misunderstanding. It is only about some links generated by /usr/lib/udev/rules.d/61-persistent-storage-compat.rules
You can read this file to check whether you ever used these links at all.
Indeed. For clarification: First of all, these symlinks are generally rarely used, because they are for _device_ identifcation, whereas users typically configure _filesystem_ identification using by-uuid or by-label. The latter methods are absolutely independent of the proposed change. The device symlinks might be used in filter expressions in /etc/lvm.conf, for example. If this is the case, you may need to fix your filters. Details - NMVe: Later kernels have settled on the generic "wwid" sysfs attribute, which is a superset of the previously used methods "eui", nguid", etc, and also of the legacy use of the SCSI translation layer. - SCSI: The compat symlinks are only relevant for SATA disks, where they create an additional symlink. On my system, it looks like this: scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E -> ../../sda scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E -> ../../sda The first link is missing a '_' between product ID and serial number, That's the compat link. - path_id: this also matters to SATA disks only. The compat link is a /dev/disk/by-path/pci...scsi... link, whereas udev's path_id built-in generates a /dev/disk/by-id/pci...ata link. Example: pci-0000:00:17.0-ata-3.0 -> ../../sda pci-0000:00:17.0-scsi-2:0:0:0 -> ../../sda The second one here is the compat symlink. Regards Martin
On 2022-06-17 10:10, Martin Wilck wrote:
On Wed, 2022-06-15 at 20:07 +0300, Andrei Borzenkov wrote:
On 15.06.2022 19:15, Manfred Schwarb wrote:
Am 15.06.22 um 11:35 schrieb Franck Bui:
...
This is probably misunderstanding. It is only about some links generated by /usr/lib/udev/rules.d/61-persistent-storage-compat.rules
You can read this file to check whether you ever used these links at all.
Indeed. For clarification:
First of all, these symlinks are generally rarely used, because they are for _device_ identifcation, whereas users typically configure _filesystem_ identification using by-uuid or by-label. The latter methods are absolutely independent of the proposed change.
The device symlinks might be used in filter expressions in /etc/lvm.conf, for example. If this is the case, you may need to fix your filters.
Details
- NMVe: Later kernels have settled on the generic "wwid" sysfs attribute, which is a superset of the previously used methods "eui", nguid", etc, and also of the legacy use of the SCSI translation layer. - SCSI: The compat symlinks are only relevant for SATA disks, where they create an additional symlink. On my system, it looks like this:
scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E -> ../../sda scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E -> ../../sda
The first link is missing a '_' between product ID and serial number, That's the compat link.
Ok, in this case what should we use? sda? scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E? scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E? Something else?
- path_id: this also matters to SATA disks only. The compat link is a /dev/disk/by-path/pci...scsi... link, whereas udev's path_id built-in generates a /dev/disk/by-id/pci...ata link. Example:
pci-0000:00:17.0-ata-3.0 -> ../../sda pci-0000:00:17.0-scsi-2:0:0:0 -> ../../sda
The second one here is the compat symlink.
Same question. sda? pci-0000:00:17.0-ata-3.0? pci-0000:00:17.0-scsi-2:0:0:0 Something else? Sorry if I'm being thick, but I don't understand what are the wrong ones and the correct ones. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On Fri, 2022-06-17 at 10:39 +0200, Carlos E. R. wrote:
On 2022-06-17 10:10, Martin Wilck wrote:
On Wed, 2022-06-15 at 20:07 +0300, Andrei Borzenkov wrote:
On 15.06.2022 19:15, Manfred Schwarb wrote:
Am 15.06.22 um 11:35 schrieb Franck Bui:
...
This is probably misunderstanding. It is only about some links generated by /usr/lib/udev/rules.d/61-persistent-storage-compat.rules
You can read this file to check whether you ever used these links at all.
Indeed. For clarification:
First of all, these symlinks are generally rarely used, because they are for _device_ identifcation, whereas users typically configure _filesystem_ identification using by-uuid or by-label. The latter methods are absolutely independent of the proposed change.
The device symlinks might be used in filter expressions in /etc/lvm.conf, for example. If this is the case, you may need to fix your filters.
Details
- NMVe: Later kernels have settled on the generic "wwid" sysfs attribute, which is a superset of the previously used methods "eui", nguid", etc, and also of the legacy use of the SCSI translation layer. - SCSI: The compat symlinks are only relevant for SATA disks, where they create an additional symlink. On my system, it looks like this:
scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E -> ../../sda scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E -> ../../sda
The first link is missing a '_' between product ID and serial number, That's the compat link.
Ok, in this case what should we use?
The non-compat link, i.e. the latter. I thought this was obvious from thw thread's topic, sorry,
sda?
scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E?
scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E?
Something else?
- path_id: this also matters to SATA disks only. The compat link is a /dev/disk/by-path/pci...scsi... link, whereas udev's path_id built- in generates a /dev/disk/by-id/pci...ata link. Example:
pci-0000:00:17.0-ata-3.0 -> ../../sda pci-0000:00:17.0-scsi-2:0:0:0 -> ../../sda
The second one here is the compat symlink.
Same question.
The former.
sda?
pci-0000:00:17.0-ata-3.0?
pci-0000:00:17.0-scsi-2:0:0:0
Something else?
Sorry if I'm being thick, but I don't understand what are the wrong ones and the correct ones.
"compat" stands for "legacy"; i.e. the ones that shouldn't be used any more. Out of curiosity: are you using these links, and if yes, what for? Martin
On 2022-06-17 13:50, Martin Wilck wrote:
On Fri, 2022-06-17 at 10:39 +0200, Carlos E. R. wrote:
On 2022-06-17 10:10, Martin Wilck wrote:
On Wed, 2022-06-15 at 20:07 +0300, Andrei Borzenkov wrote:
On 15.06.2022 19:15, Manfred Schwarb wrote:
Am 15.06.22 um 11:35 schrieb Franck Bui:
...
This is probably misunderstanding. It is only about some links generated by /usr/lib/udev/rules.d/61-persistent-storage-compat.rules
You can read this file to check whether you ever used these links at all.
Indeed. For clarification:
First of all, these symlinks are generally rarely used, because they are for _device_ identifcation, whereas users typically configure _filesystem_ identification using by-uuid or by-label. The latter methods are absolutely independent of the proposed change.
The device symlinks might be used in filter expressions in /etc/lvm.conf, for example. If this is the case, you may need to fix your filters.
Details
- NMVe: Later kernels have settled on the generic "wwid" sysfs attribute, which is a superset of the previously used methods "eui", nguid", etc, and also of the legacy use of the SCSI translation layer. - SCSI: The compat symlinks are only relevant for SATA disks, where they create an additional symlink. On my system, it looks like this:
scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E -> ../../sda scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E -> ../../sda
The first link is missing a '_' between product ID and serial number, That's the compat link.
Ok, in this case what should we use?
The non-compat link, i.e. the latter. I thought this was obvious from thw thread's topic, sorry,
sda?
scsi-SATA_SK_hynix_SC300_MFJ63N456110303C1E?
scsi-SATA_SK_hynix_SC300_M_FJ63N456110303C1E?
Something else?
- path_id: this also matters to SATA disks only. The compat link is a /dev/disk/by-path/pci...scsi... link, whereas udev's path_id built- in generates a /dev/disk/by-id/pci...ata link. Example:
pci-0000:00:17.0-ata-3.0 -> ../../sda pci-0000:00:17.0-scsi-2:0:0:0 -> ../../sda
The second one here is the compat symlink.
Same question.
The former.
Thanks.
sda?
pci-0000:00:17.0-ata-3.0?
pci-0000:00:17.0-scsi-2:0:0:0
Something else?
Sorry if I'm being thick, but I don't understand what are the wrong ones and the correct ones.
"compat" stands for "legacy"; i.e. the ones that shouldn't be used any more. Out of curiosity: are you using these links, and if yes, what for?
I don't know yet, because till now I did not know which they were. Now I have to check. I just tried to download the referenced script in the OP, and run it in my main computer (Leap 15.3):
cer@Telcontar:~> bash ./find-legacy-symlinks.sh Failed to retrive the compat symlink generation number, assuming generation 1. ln: failed to create symbolic link '/run/udev/rules.d/61-persistent-storage-compat.rules': Permission denied Failed to send reload request: Permission denied cer@Telcontar:~>
I have, or had, these:
cer@Telcontar:~> grep "/dev/disk/by-path/" /etc/fstab /etc/crypttab cer@Telcontar:~> grep "/dev/disk/by-id/" /etc/fstab /etc/crypttab /etc/fstab:#/dev/disk/by-id/md-uuid-825b22e8:af550e83:93727666:fb8987fd /data/raid xfs defaults,nofail 1 3 /etc/crypttab:#cr_criptaQ /dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ-part9 none none /etc/crypttab:#cr_other /dev/disk/by-id/ata-ST3500418AS_9VM7ZCQQ-part10 none noauto /etc/crypttab:#cr_sdd2 /dev/disk/by-id/ata-ST3500418AS_5VM2RW2X-part2 none none /etc/crypttab:#cr_sdd3 /dev/disk/by-id/ata-ST3500418AS_5VM2RW2X-part3 none none cer@Telcontar:~>
-- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Fri, 2022-06-17 at 14:11 +0200, Carlos E. R. wrote:
I have, or had, these:
cer@Telcontar:~> grep "/dev/disk/by-path/" /etc/fstab /etc/crypttab cer@Telcontar:~> grep "/dev/disk/by-id/" /etc/fstab /etc/crypttab
Ah yes, crypttab would be one candidate where they'd make sense.
/etc/fstab:#/dev/disk/by-id/md-uuid- 825b22e8:af550e83:93727666:fb8987fd /data/raid xfs default s,nofail 1 3
This is actually more like a file system UUID, thus no problem.
/etc/crypttab:#cr_criptaQ /dev/disk/by-id/ata- ST3500418AS_9VM7ZCQQ-part9 none none /etc/crypttab:#cr_other /dev/disk/by-id/ata- ST3500418AS_9VM7ZCQQ-part10 none noauto
by-id/ata-... links should be safe.
/etc/crypttab:#cr_sdd2 /dev/disk/by-id/ata-ST3500418AS_5VM2RW2X- part2 none none /etc/crypttab:#cr_sdd3 /dev/disk/by-id/ata- ST3500418AS_5VM2RW2X-part3 none none
Regards, Martin
On 6/17/22 14:11, Carlos E. R. wrote:
cer@Telcontar:~> bash ./find-legacy-symlinks.sh Failed to retrive the compat symlink generation number, assuming generation 1. ln: failed to create symbolic link '/run/udev/rules.d/61-persistent-storage-compat.rules': Permission denied Failed to send reload request: Permission denied cer@Telcontar:~>
You need to run the script as root.
On 2022-06-17 18:48, Franck Bui wrote:
On 6/17/22 14:11, Carlos E. R. wrote:
cer@Telcontar:~> bash ./find-legacy-symlinks.sh Failed to retrive the compat symlink generation number, assuming generation 1. ln: failed to create symbolic link '/run/udev/rules.d/61-persistent-storage-compat.rules': Permission denied Failed to send reload request: Permission denied cer@Telcontar:~>
You need to run the script as root.
Why does it need to write files to my system directories? :-? -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 2022-06-17 19:10, Carlos E. R. wrote:
On 2022-06-17 18:48, Franck Bui wrote:
On 6/17/22 14:11, Carlos E. R. wrote:
cer@Telcontar:~> bash ./find-legacy-symlinks.sh Failed to retrive the compat symlink generation number, assuming generation 1. ln: failed to create symbolic link '/run/udev/rules.d/61-persistent-storage-compat.rules': Permission denied Failed to send reload request: Permission denied cer@Telcontar:~>
You need to run the script as root.
Why does it need to write files to my system directories? :-?
On one machine of the three I can reach this instant:
cer@Isengard:~> cd bin cer@Isengard:~/bin> md checks cer@Isengard:~/bin> cd checks cer@Isengard:~/bin/checks> wget "https://raw.githubusercontent.com/fbuihuu/find-legacy-symlinks/main/find-leg..." --2022-06-17 19:13:25-- https://raw.githubusercontent.com/fbuihuu/find-legacy-symlinks/main/find-leg... Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.110.133, 185.199.109.133, ... Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2819 (2,8K) [text/plain] Saving to: ‘find-legacy-symlinks.sh’
find-legacy-symlinks.sh 100%[=====================================>] 2,75K --.-KB/s in 0s
2022-06-17 19:13:25 (12,6 MB/s) - ‘find-legacy-symlinks.sh’ saved [2819/2819]
cer@Isengard:~/bin/checks> su -c "bash ./find-legacy-symlinks.sh" Password: Failed to retrive the compat symlink generation number, assuming generation 1. trigger: unrecognized option '--settle' trigger: unrecognized option '--settle' cer@Isengard:~/bin/checks> cer@Isengard:~> cat /etc/os-release NAME="openSUSE Leap" VERSION="15.2" ...
The other two are clean:
cer@Legolas:~/bin/checks> su -c "bash ./find-legacy-symlinks.sh" Password: This system is using compat symlink generation '2'. This generation doesn't have any legacy symlink at this moment, hence your system can't possibly rely on such symlinks, all is good. cer@Legolas:~/bin/checks>
-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 6/17/22 22:30, Carlos E. R. wrote:
On one machine of the three I can reach this instant:
cer@Isengard:~/bin/checks> su -c "bash ./find-legacy-symlinks.sh" Password: Failed to retrive the compat symlink generation number, assuming generation 1. trigger: unrecognized option '--settle' trigger: unrecognized option '--settle'
I'll fix it thanks for reporting.
On 6/17/22 19:10, Carlos E. R. wrote:
You need to run the script as root.
Why does it need to write files to my system directories? :-?
The script needs to mask the rule file that deals with the compat symlinks and for that it needs to temporarily create a symlink to /dev/null in /run/udev/rules.d/. The root privs are also needed to re-trigger some uevents.
On 6/17/22 10:10, Martin Wilck wrote:
Indeed. For clarification:
First of all, these symlinks are generally rarely used, because they are for _device_ identifcation, whereas users typically configure _filesystem_ identification using by-uuid or by-label. The latter methods are absolutely independent of the proposed change.
Exactly, thanks Martin for clarifying this here and in your other posts.
The device symlinks might be used in filter expressions in /etc/lvm.conf, for example. If this is the case, you may need to fix your filters.
Forgot to check /etc/lvm.conf in the bash script will do. Thanks.
On Fri, 2022-06-17 at 05:55 -0400, Cristian Rodríguez wrote:
On Wed, Jun 15, 2022 at 12:15 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Why should they be "not stable" or "not accurate"?
device numbers were never stable.please do not use this stuff to mount filesystems, use UUID= instead.
I don't think Manfred was talking about device numbers (aka major/minor numbers). Anyway, by-path links aren't stable either. PCI bus/device/function enumeration can change when hardware is added to or removed from the system, or sometimes even when the BIOS is updated. SCSI host/bus/target/lun enumeration is also not cast in stone. Especially the host number may change depending on probing order. Martin
Am 17.06.22 um 15:25 schrieb Martin Wilck:
On Fri, 2022-06-17 at 05:55 -0400, Cristian Rodríguez wrote:
On Wed, Jun 15, 2022 at 12:15 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Why should they be "not stable" or "not accurate"?
device numbers were never stable.please do not use this stuff to mount filesystems, use UUID= instead.
I don't think Manfred was talking about device numbers (aka major/minor numbers).
I was talking about the sentence "... initialized with persistent storage symlinks (those located in /dev/disk/by-*) which later were considered broken or not accurate" Which means all /dev/disk/by-* are considered legacy, i.e. even /dev/disk/by-uuid/* But probably I got it wrong. Probably the meaning is "some of them later were considered broken" On my box, I have #>ls -l /dev/disk/by-id/ |grep "nvme0n1$" lrwxrwxrwx 1 root root 13 2022-06-17 15:48 -Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-20025385581b03fdf -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-SNVMe_Samsung_SSD_970_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-eui.0025385581b03fdf -> ../../nvme0n1 And the the script tells me: legacy: /dev/disk/by-id/-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-20025385581b03fdf /dev/disk/by-id/nvme-SNVMe_Samsung_SSD_970_S463NF0K512719M which means probably, that /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-eui.0025385581b03fdf are OK. Cheers, Manfred
Anyway, by-path links aren't stable either. PCI bus/device/function enumeration can change when hardware is added to or removed from the system, or sometimes even when the BIOS is updated.
SCSI host/bus/target/lun enumeration is also not cast in stone. Especially the host number may change depending on probing order.
Martin
On Fri, 2022-06-17 at 16:05 +0200, Manfred Schwarb wrote:
Am 17.06.22 um 15:25 schrieb Martin Wilck:
On Fri, 2022-06-17 at 05:55 -0400, Cristian Rodríguez wrote:
On Wed, Jun 15, 2022 at 12:15 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Why should they be "not stable" or "not accurate"?
device numbers were never stable.please do not use this stuff to mount filesystems, use UUID= instead.
I don't think Manfred was talking about device numbers (aka major/minor numbers).
I was talking about the sentence "... initialized with persistent storage symlinks (those located in /dev/disk/by-*) which later were considered broken or not accurate"
Which means all /dev/disk/by-* are considered legacy, i.e. even /dev/disk/by-uuid/* But probably I got it wrong. Probably the meaning is "some of them later were considered broken"
Exactly. See my previous posts. It also follows from Franck's remarks about /usr/lib/udev/compat-symlink-generation.
On my box, I have #>ls -l /dev/disk/by-id/ |grep "nvme0n1$" lrwxrwxrwx 1 root root 13 2022-06-17 15:48 - Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1
This is quite obviously a "bad" symlink. The question is not whether you have it, but whether you reference it somewhere.
/usr/lib/udev/compat-symlink-generation/usr/lib/udev/compat-symlink- generationlrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme- 20025385581b03fdf -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme- SNVMe_Samsung_SSD_970_S463NF0K512719M -> ../../nvme0n1
These two are also "compat" symlinks.
lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme- Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1
This is the ${ID_BUS}/${ID_SERIAL} symlink. It will remain.
lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-eui.0025385581b03fdf -> ../../nvme0n1
The last one is the "best" one. "eui.0025385581b03fdf" is probably the content of the "wwid" sysfs attribute.
And the the script tells me: legacy: /dev/disk/by-id/-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-20025385581b03fdf /dev/disk/by-id/nvme-SNVMe_Samsung_SSD_970_S463NF0K512719M
which means probably, that /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-eui.0025385581b03fdf are OK.
Yes. Regards Martin
On 6/17/22 16:05, Manfred Schwarb wrote:
I was talking about the sentence "... initialized with persistent storage symlinks (those located in /dev/disk/by-*) which later were considered broken or not accurate"
Which means all /dev/disk/by-* are considered legacy, i.e. even /dev/disk/by-uuid/* But probably I got it wrong. Probably the meaning is "some of them later were considered broken"
Yeah, sorry for the confusion.
On my box, I have #>ls -l /dev/disk/by-id/ |grep "nvme0n1$" lrwxrwxrwx 1 root root 13 2022-06-17 15:48 -Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-20025385581b03fdf -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-SNVMe_Samsung_SSD_970_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-Samsung_SSD_970_PRO_512GB_S463NF0K512719M -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 2022-06-17 15:48 nvme-eui.0025385581b03fdf -> ../../nvme0n1
And the the script tells me: legacy: /dev/disk/by-id/-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-20025385581b03fdf /dev/disk/by-id/nvme-SNVMe_Samsung_SSD_970_S463NF0K512719M
which means probably, that /dev/disk/by-id/nvme-Samsung_SSD_970_PRO_512GB_S463NF0K512719M /dev/disk/by-id/nvme-eui.0025385581b03fdf are OK.
Indeed.
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
On 6/16/22 19:11, josef Reidinger wrote:
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 to make sure as my initial wording was pretty confusing: I didn't mean to drop all symlinks in /dev/disk/by-* but some of them whose names were considered broken but we kept for the sake of backward compatibility.
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.
Good point, actually /proc/cmdline should be checked as well. Thanks.
On 2022-06-17 18:59, Franck Bui wrote:
On 6/16/22 19:11, josef Reidinger wrote:
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 to make sure as my initial wording was pretty confusing: I didn't mean to drop all symlinks in /dev/disk/by-* but some of them whose names were considered broken but we kept for the sake of backward compatibility.
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.
Good point, actually /proc/cmdline should be checked as well.
What about: Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L Elesar:~ # ? -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Am 15.06.22 um 11:35 schrieb Franck Bui:> 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".
Strangely I got the following in the journal: kernel: Linux version 5.18.2-1-default (geeko@buildhost) (gcc (SUSE Linux) 12.1.0, GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.38.20220525-6) #1 SMP PREEMPT_DYNAMIC Tue Jun 7 06:08:54 UTC 2022 (695cfee) kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.18.2-1-default root=/dev/mapper/system-root showopts quiet udev.compat_symlink_generation=0 [...] systemd-udevd[322]: Unknown udev kernel command line option "udev.compat_symlink_generation", ignoring. But some links disappeared, so I assume it worked. No problems though, I also grepped for them a bit and found nothing. Aaron
On 6/17/22 21:47, Aaron Puchert wrote:
systemd-udevd[322]: Unknown udev kernel command line option "udev.compat_symlink_generation", ignoring.
But some links disappeared, so I assume it worked. No problems though, I also grepped for them a bit and found nothing.
Hm, since v246 udevd (the daemon) complains about kernel command line option prefixed with "udev." it doesn't know and that's the case here because "udev.compat_symlink_generation" is only used by the rules file... The option should probably be renamed to avoid the warning, which is safe to ignore in this case. Not sure if it's really worth it though. Thanks for reporting.
What is the plan to avoid users running into problems when doing an upgrade without prior checking the system? Can they at least use udev.compat_symlink_generation=something to get the links back? ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 6/20/22 10:24, Arvin Schnell wrote:
What is the plan to avoid users running into problems when doing an upgrade without prior checking the system? Can they at least use udev.compat_symlink_generation=something to get the links back?
Well the point of this RFC would be to drop the support of legacy symlinks. Hence keeping the old code to allow users to restore them would defeat the goal. Here I'm trying to figure out whether deprecating the compat symlinks would be acceptable. If so, the next step would be to officially deprecate them during a period so openSUSE users have time to update their system when it's needed (it should be relatively rare though). Once the deprecation period is done and the compat symlink support would be dropped for good and there wouldn't be any way to restore them. That's the only way I can think of to get rid of this obsolete code. This can't be done automatically AFAIK.
participants (10)
-
Aaron Puchert -
Andrei Borzenkov -
Arvin Schnell -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Franck Bui -
josef Reidinger -
Manfred Schwarb -
Martin Wilck