Re: Too many levels of symbolic links
Le 22-01-2021, à 14:59:27 +0200, Andrei POPESCU a écrit :
On Vi, 22 ian 21, 08:08:57, steve wrote:
Le 21-01-2021, à 09:45:18 +0200, Andrei POPESCU a écrit :
> On Jo, 21 ian 21, 08:34:34, steve wrote:
> > I have rebooted with udev_log=debug in /etc/udev/udev.conf. I see
> >
> > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Failed to update device symlinks: Too many levels of symbolic links
> > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6' to '../../sdc6'
> > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' to '../../sdc6'
> > Jan 21 08:15:28 box systemd-udevd[607]: sdc6: Preserve already existing symlink '/dev/disk/by-path/pci-0000:00:17.0-ata-2-part6' to '../../sdc6'
> >
> > And the same for other partitions which are all part of a Raid1 array.
> > Other partitions are not impacted. So I guess this is related.
>
> Could you inspect the /dev directory from a live image or similar (i.e.
> with the affected system not running)?
Yes I can do that. What should I look for?
I'm guessing it should be empty ;)
…
At least in buster /dev is a 'devtmpfs' mounted over /dev (is this the
same for you?).
I have
mount | grep devtmp
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=16243620k,nr_inodes=4060905,mode=755)
> Do you have any custom udev rules or any other custom scripts, services,
> etc. plugged into the early startup?
Don't know:
tree /etc/udev
/etc/udev
├── hwdb.d
├── rules.d
│ ├── 51-android.rules
│ ├── 55-Argyll.rules
│ ├── 69-libmtp.rules
│ ├── 70-persistent-cd.rules
│ └── 70-persistent-net.rules.old
└── udev.conf
Maybe the output of 'udevadm test /sys/block/sdc/sdc6' can provide some
interesting information
Sure, a lot of output. Here is what seems worrying (error or failed
word):
sdc6: /lib/udev/rules.d/64-md-raid-assembly.rules:33 Importing properties from results of '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'
sdc6: Starting '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'
Successfully forked off '(spawn)' as PID 16720.
sdc6: '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342'(err) 'mdadm: cannot reopen /dev/sdc6: Device or resource busy.'
sdc6: Process '/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342' failed with exit code 1.
sdc6: /lib/udev/rules.d/64-md-raid-assembly.rules:33 Command "/sbin/mdadm --incremental --export /dev/sdc6 --offroot /dev/disk/by-id/ata-Samsung_SSD_860_EVO_250GB_S3YJNX1K619373P-part6 /dev/disk/by-id/wwn-0x5002538e4051327c-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2.0-part6 /dev/disk/by-path/pci-0000:00:17.0-ata-2-part6 /dev/disk/by-partlabel/Linux\x20RAID /dev/disk/by-partuuid/7acd2c90-b372-4bfb-a517-e14d2a17e342" returned 1 (error), ignoring
as well as 'ls -l /dev/disk/by-*', otherwise I'm out of ideas.
There's a lot there and nothing looking bad at first sight.
Reply to: