Bug#523151: udev: [s390] Fails to configure additional disk/net devices

[Frans Pop]

Package: udev
Version: 0.140-2
Severity: critical
Justification: breaks the whole system
User: debian-***@lists.debian.org
Usertags: s390


After upgrading udev the system fails to boot correctly as my second
disk (dasdb) and network interface (ctc0) are no longer brought up.

The initrd loads correctly and / is mounted correctly. Other than the
two missing devices the system boots correctly. Because dasdb is not
activated I'm missing my /home (which is on LVM).

I also upgraded the kernel, but as I can bring up both devices manually
without any problems I doubt this is a kernel problem.

As I see there are s390 specific rules files present, I'm not sure what
the problem is here.

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 20
-rw-r--r-- 1 root root 1137 2008-10-01 16:51 65_dmsetup.rules
-rw-r--r-- 1 root root 1137 2008-07-15 23:59 65_s390-tools.rules
-rw-r--r-- 1 root root 168 2008-09-12 13:33 65-sysconfig-hardware-net.rules
-rw-r--r-- 1 root root 534 2009-04-08 13:50 70-persistent-net.rules
-rw-r--r-- 1 root root 112 2008-09-12 13:33 85-sysconfig-hardware.rules

-- /sys/:
/sys/dev
/sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dasda1/dev
/sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dasda2/dev
/sys/devices/css0/0.0.0004/0.0.0120/block/dasda/dev
/sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dasdb1/dev
/sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dasdb2/dev
/sys/devices/css0/0.0.0005/0.0.0121/block/dasdb/dev
/sys/devices/virtual/block/dm-0/dev
/sys/devices/virtual/block/ram0/dev
/sys/devices/virtual/block/ram10/dev
/sys/devices/virtual/block/ram11/dev
/sys/devices/virtual/block/ram12/dev
/sys/devices/virtual/block/ram13/dev
/sys/devices/virtual/block/ram14/dev
/sys/devices/virtual/block/ram15/dev
/sys/devices/virtual/block/ram1/dev
/sys/devices/virtual/block/ram2/dev
/sys/devices/virtual/block/ram3/dev
/sys/devices/virtual/block/ram4/dev
/sys/devices/virtual/block/ram5/dev
/sys/devices/virtual/block/ram6/dev
/sys/devices/virtual/block/ram7/dev
/sys/devices/virtual/block/ram8/dev
/sys/devices/virtual/block/ram9/dev
/sys/devices/virtual/mem/full/dev
/sys/devices/virtual/mem/kmem/dev
/sys/devices/virtual/mem/kmsg/dev
/sys/devices/virtual/mem/mem/dev
/sys/devices/virtual/mem/null/dev
/sys/devices/virtual/mem/random/dev
/sys/devices/virtual/mem/urandom/dev
/sys/devices/virtual/mem/zero/dev
/sys/devices/virtual/misc/cpu_dma_latency/dev
/sys/devices/virtual/misc/device-mapper/dev
/sys/devices/virtual/misc/network_latency/dev
/sys/devices/virtual/misc/network_throughput/dev
/sys/devices/virtual/tty/console/dev
/sys/devices/virtual/tty/ptmx/dev
/sys/devices/virtual/tty/sclp_line0/dev
/sys/devices/virtual/tty/tty/dev
/sys/devices/virtual/tty/ttysclp0/dev

-- Kernel configuration:
isapnp_init not present.


-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: s390

Kernel: Linux 2.6.29-1-s390 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages udev depends on:
ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy
ii libc6 2.9-7 GNU C Library: Shared libraries
ii libselinux1 2.0.71-1 SELinux shared libraries
ii libvolume-id1 0.140-2 libvolume_id shared library
ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip
ii s390-tools 1.6.2-1 A set of fundamental utilities for

udev recommends no packages.

udev suggests no packages.

-- debconf information:
udev/new_kernel_needed: false
udev/reboot_needed:

[Frans Pop]

Maybe the following will provide some info:

# udevadm test /sys/bus/ccw/devices/0.0.0121
[...]
udev_device_new_from_syspath: device 0x42b828 has devpath '/devices/css0/0.0.0005/0.0.0121'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared after 0 loops
udev_rules_apply_to_event: RUN '/sbin/hwup -A -D $DEVPATH $env{SUBSYSTEM} %b' /etc/udev/rules.d/85-sysconfig-hardware.rules:2
udev_rules_apply_to_event: RUN 'socket:@/org/kernel/udev/monitor' /lib/udev/rules.d/95-late.rules:17
udevadm_test: run: '/sbin/hwup -A -D /devices/css0/0.0.0005/0.0.0121 ccw '
udevadm_test: run: 'socket:@/org/kernel/udev/monitor'

Could it be that the last parameter for the call to hwup ("%b") is missing?
AFAICT the value for that should be "0.0.0121" in this case.

[Frans Pop]

Post by Frans Pop
# udevadm test /sys/bus/ccw/devices/0.0.0121
[...]
udev_device_new_from_syspath: device 0x42b828 has devpath '/devices/css0/0.0.0005/0.0.0121'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared after 0 loops
udev_rules_apply_to_event: RUN '/sbin/hwup -A -D $DEVPATH $env{SUBSYSTEM} %b' /etc/udev/rules.d/85-sysconfig-hardware.rules:2
/lib/udev/rules.d/95-late.rules:17 udevadm_test: run: '/sbin/hwup -A -D /devices/css0/0.0.0005/0.0.0121 ccw '
Could it be that the last parameter for the call to hwup ("%b") is
missing? AFAICT the value for that should be "0.0.0121" in this case.

Yes, looks like that's it. After downgrading to udev 0.125 I get:

import_uevent_var: import into environment: 'DRIVER=dasd-eckd'
import_uevent_var: import into environment: 'CU_TYPE=3990'
import_uevent_var: import into environment: 'CU_MODEL=C2'
import_uevent_var: import into environment: 'DEV_TYPE=3390'
import_uevent_var: import into environment: 'DEV_MODEL=02'
import_uevent_var: import into environment: 'MODALIAS=ccw:t3990mC2dt3390dm02'
udevtest: looking at device '/devices/css0/0.0.0005/0.0.0121' from subsystem 'ccw'
wait_for_file: file '/sys/devices/css0/0.0.0005/0.0.0121/online' appeared after 0 loops
udevtest: run: '/sbin/hwup -A -D /devices/css0/0.0.0005/0.0.0121 ccw 0.0.0121'
udevtest: run: 'socket:@/org/kernel/udev/monitor'

Note that those 'import_uevent_var' messages are not displayed with 0.140,
but that may be as expected or unrelated.

[Frans Pop]

Post by Frans Pop
udev_rules_apply_to_event: RUN '/sbin/hwup -A -D $DEVPATH
$env{SUBSYSTEM} %b' /etc/udev/rules.d/85-sysconfig-hardware.rules:2

The exact semantics of $id may have changed, I will check with the
upstream maintainer.

I can use $kernel at this point, which seems to have a more stable
semantic.

Thanks Bastian. With the new sysconfig-hardware all's fine again.

Cheers,
FJP