Bug#1069182: initscripts: udev initscript SHOULD NOT clear the udev database at startup

[Alex Volkov]

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