[RFC] Dropping support for legacy persistent storage symlinks

Franck Bui

15 Jun 2022 15 Jun '22

09:35

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.

Show replies by date

Carlos E. R.

15 Jun 15 Jun

14:36

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)

Manfred Schwarb

16:15

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.

Andrei Borzenkov

17:07

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.

Martin Wilck

17 Jun 17 Jun

08:10

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

Carlos E. R.

08:39

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)

Martin Wilck

11:50

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

Carlos E. R.

12:11

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)

Martin Wilck

13:42

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

Franck Bui

16:48

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.

Carlos E. R.

17:10

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)

Carlos E. R.

20:30

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)

Franck Bui

20 Jun 20 Jun

08:07

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.

Franck Bui

08:06

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.

Franck Bui

17 Jun 17 Jun

16:47

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.

Cristian Rodríguez

09:55

On Wed, Jun 15, 2022 at 12:15 PM Manfred Schwarb 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.

Martin Wilck

13:25

On Fri, 2022-06-17 at 05:55 -0400, Cristian Rodríguez wrote:

...

On Wed, Jun 15, 2022 at 12:15 PM Manfred Schwarb 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

Manfred Schwarb

14:05

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 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

Martin Wilck

14:56

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 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

Franck Bui

16:50

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.

josef Reidinger

16 Jun 16 Jun

17:11

On Wed, 15 Jun 2022 11:35:41 +0200 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".

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

Franck Bui

17 Jun 17 Jun

16:59

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.

Carlos E. R.

18 Jun 18 Jun

15:08

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)

Franck Bui

20 Jun 20 Jun

08:10

On 6/18/22 17:08, Carlos E. R. wrote:

...

What about:

Elesar:~ # cat /etc/default/grub_installdevice /dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NB0J535704L

Checking the content of this file makes sense too, thanks!

Aaron Puchert

17 Jun 17 Jun

19:47

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

Franck Bui

20 Jun 20 Jun

08:32

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.

Arvin Schnell

08:24

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, 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

Franck Bui

09:08

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.

713

Age (days ago)

718

Last active (days ago)

List overview

Download

27 comments

10 participants

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

[RFC] Dropping support for legacy persistent storage symlinks

tags

participants (10)