I can confirm these bugs with udev-215 and sysvinit-core in jessie. udev takes a long time to settle. It takes more than 20 seconds to probe the other partitions, like shown in the dmesg:
[ 11.333067] Bluetooth: HCI device and connection manager initialized [ 11.333077] Bluetooth: HCI socket layer initialized [ 11.333079] Bluetooth: L2CAP socket layer initialized [ 11.333092] Bluetooth: SCO socket layer initialized [ 11.380806] usbcore: registered new interface driver btusb [ 11.426459] usb 2-1.4.3: New USB device found, idVendor=046d, idProduct=c246 [ 11.426465] usb 2-1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 11.426469] usb 2-1.4.3: Product: Gaming Mouse G300 [ 11.426472] usb 2-1.4.3: Manufacturer: Logitech [ 11.428454] input: Logitech Gaming Mouse G300 as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.0/0003:046D:C246.0005/input/input9 [ 11.428659] hid-generic 0003:046D:C246.0005: input,hidraw4: USB HID v1.10 Mouse [Logitech Gaming Mouse G300] on usb-0000:00:1d.7-1.4.3/input0 [ 11.433207] input: Logitech Gaming Mouse G300 as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.4/2-1.4.3/2-1.4.3:1.1/0003:046D:C246.0006/input/input10 [ 11.433509] hid-generic 0003:046D:C246.0006: input,hiddev0,hidraw5: USB HID v1.10 Keyboard [Logitech Gaming Mouse G300] on usb-0000:00:1d.7-1.4.3/input1 [ 39.205197] Adding 7787104k swap on /dev/sda4. Priority:-1 extents:1 across:7787104k FS [ 39.234284] EXT4-fs (sda3): re-mounted. Opts: (null) [ 39.643669] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro [ 40.068194] lp: driver loaded but no devices found [ 40.148968] ppdev: user-space parallel port driver [ 40.431468] loop: module loaded changing udev log level to err "solves" the problem, as suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763041#30 diff --git a/udev/udev.conf b/udev/udev.conf index efe4ff4..61572a2 100644 --- a/udev/udev.conf +++ b/udev/udev.conf @@ -3,4 +3,4 @@ # udevd is started in the initramfs, so when this file is modified the # initramfs should be rebuilt. -#udev_log="info" +udev_log="err" I suppose it is because >=udev-208 assumes a systemd-driven log buffer to write into. Otherwise the log messages accumulate too fast at "info" level, resulting in a timeout. Cheers, Benda -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
