Bug#1069182: initscripts: udev initscript SHOULD NOT clear the udev database at startup
Alex Volkov
alex at bootes.sytes.net
Wed Apr 17 13:25:08 BST 2024
Package: initscripts
Version: 3.08-3~bpo12+2
Severity: important
Dear Maintainer,
I don't use systemd and for quite some time I struggled with strange udev
behaviour — it doesn't properly enumerate any LVM volumes, their records
looking like this (note "UDEV_DISABLE" properties):
P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 254:0
N: dm-0
L: 0
Q: 16
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: DISKSEQ=16
E: MAJOR=254
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=5035098
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
This, in turn, leads to problems with apps which rely onto udev for listing
disk devices, e. g. Dolphin doesn't show them in its "Devices" menu, e2scrub
can't find them as it takes the info about filesystems from udev, etc. (See,
for example, the bug #986231 I filed TWO years ago about lsblk being unable to
determine a filesystem type.)
Investigating the issue, I found that the culprit is the obscure procedure
which udev uses to enumerate device-mapper-controlled drives, see, for
example, discussions here:
https://lore.kernel.org/all/CANnVG6mMTcRkWQEEhZSEELfyGHqNkGPx2LmdR9NS+-wkAieGSw@mail.gmail.com/T/
or here:
https://bugs.gentoo.org/330651
In the latter a maintainer specifically notes that "we require the udev
database to be kept even from initrd stage" to avoid disabling drives by
the corresponding udev rule.
Now, /etc/init.d/udev for some reason does this in its start clause:
===
135 # clean up parts of the database created by the initramfs udev
136 udevadm info --cleanup-db
===
Commenting this line out makes things as they should be:
P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 254:0
N: dm-0
L: 0
S: vg0/root
S: disk/by-label/ROOT
S: disk/by-id/dm-uuid-LVM-veczrDUWOJiXGZ3UJouWnb0VybkpMNR7UmTRamNQy5hTnaN6d5OK75lJwPX9DLYW
S: mapper/vg0-root
S: disk/by-id/dm-name-vg0-root
S: disk/by-uuid/74945b3e-925a-418e-92bd-6cd67e393144
Q: 16
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: DISKSEQ=16
E: MAJOR=254
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=3712867
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=vg0-root
E: DM_UUID=LVM-veczrDUWOJiXGZ3UJouWnb0VybkpMNR7UmTRamNQy5hTnaN6d5OK75lJwPX9DLYW
E: DM_SUSPENDED=0
E: DM_VG_NAME=vg0
E: DM_LV_NAME=root
E: ID_FS_LABEL=ROOT
Note that systemd-based systems are not affected, as they seemingly don't
relate to the initrd scripts for starting udev. (Which can raise certain
suspicions as for WHY this is done in the script *provided by systemd* for
non-systemd-based systems, but oh well.)
If there is a valid reason for cleaning the database, the issue needs to be
researched further, of course, but to me deleting the offending line fixes
everything.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991,
'stable'), (99, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.13-bootes0-p-1000 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages initscripts depends on:
ii sysv-rc 3.08-3~bpo12+2
ii sysvinit-utils 3.08-3~bpo12+2
Versions of packages initscripts recommends:
ii e2fsprogs 1.47.0-2
ii psmisc 23.6-1
initscripts suggests no packages.
-- no debconf information
More information about the Debian-init-diversity
mailing list