Bug#809740: initramfs-tools: Completely ignores rootdelay
Hello Ben and Christoph, Ben Hutchings [2016-01-29 13:50 +]: > # systemd maintainers do not want to handle ROOTDELAY For the record, this isn't just a question of *where* to put a "sleep $ROOTDELAY" -- my point is, the previous sleep was entirely non-sensical, and moving it around would still be wrong: - Sleeping some extra seconds *before* the "wait for root fs" loop in local_device_setup() will either be a no-op (if $ROOTDELAY is shorter than the actual time that it takes for the root device to appear), or it's unnecessary waiting (if $ROOTDELAY is longer than necessary). This would have been the case in udev's i-t script, as that runs before "local" (IIRC the sleep used to be in init-top/). - Sleeping some extra seconds *after* the "wait for root fs" loop would be slightly less pointless, as that actually could make a difference (like waiting for more RAID mirror members to join before you boot the system). Still wrong, but at least not a no-op. But if booting a system without it fails, as "I always get a degraded array activated" just means that mdadm's initramfs-tools hook does not do a thorough enough job to assemble the root /dev/md?, or rather, does not wait until enough members are online. This should be done properly for every system with a dynamic waiting loop, we shouldn't expect users to figure out an appropriate $ROOTDELAY by themselves. Static sleeps are never the right answer. So please don't put this into initramfs-tools either -- let's find out what really goes wrong here and fix it properly? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#809740: initramfs-tools: Completely ignores rootdelay
On Sat, 2016-01-30 at 23:57 +0100, Martin Pitt wrote: > Hello Ben and Christoph, > > Ben Hutchings [2016-01-29 13:50 +]: > > # systemd maintainers do not want to handle ROOTDELAY > > For the record, this isn't just a question of *where* to put a "sleep > $ROOTDELAY" -- my point is, the previous sleep was entirely > non-sensical, and moving it around would still be wrong: [...] I know it's nonsensical, but it's a documented feature. We just don't have a proper fix for all the issues it is used to work around. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#809740: initramfs-tools: Completely ignores rootdelay
Processing control commands: > reassign -1 udev 220-4 Bug #809740 [initramfs-tools] initramfs-tools: Completely ignores rootdelay Bug reassigned from package 'initramfs-tools' to 'udev'. No longer marked as found in versions initramfs-tools/0.120. Ignoring request to alter fixed versions of bug #809740 to the same values previously set Bug #809740 [udev] initramfs-tools: Completely ignores rootdelay Marked as found in versions systemd/220-4. -- 809740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#809740: initramfs-tools: Completely ignores rootdelay
Control: reassign -1 udev 220-4 On Sun, 2016-01-03 at 16:21 +0100, Christoph Egger wrote: > Package: initramfs-tools > Version: 0.120 > Severity: important > > Hi! > > the initramfs totally ignores the rootdelay / rootwait parameters and > just instantly boots up. [...] It has never implemented 'rootwait' as it will always wait for devices to appear. The 'rootdelay=' parameter used to be implemented in udev's script, but this was wrongly removed recently for spurious reasons. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#809740: initramfs-tools: Completely ignores rootdelay
Package: initramfs-tools Version: 0.120 Severity: important Hi! the initramfs totally ignores the rootdelay / rootwait parameters and just instantly boots up. As a result I always get a degraded array activated as the second disk is not yet available. The second disk just shows up a few blinks later. Christoph -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 5.5M Sep 23 2013 /boot/initrd.img-3.10-2-amd64 -rw-r--r-- 1 root root 5.6M Nov 15 2013 /boot/initrd.img-3.10-3-amd64 -rw-r--r-- 1 root root 6.7M Dec 19 21:02 /boot/initrd.img-3.16.0-4-amd64 -rw-r--r-- 1 root root 6.8M Sep 25 13:58 /boot/initrd.img-4.1.0-2-amd64 -rw-r--r-- 1 root root 6.8M Dec 19 21:06 /boot/initrd.img-4.2.0-1-amd64 -rw-r--r-- 1 root root 6.8M Jan 3 01:50 /boot/initrd.img-4.3.0-1-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.3.0-1-amd64 root=/dev/mapper/ssd-root ro quiet rootdelay=30 rootwait=30 systemd.log_target=kmsg systemd.debug-shell -- resume RESUME=UUID=160f4b55-b95a-416c-aec0-a20b510e40ee -- /proc/filesystems ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by fuse 94208 3 ebtable_filter 16384 0 ebtables 36864 1 ebtable_filter ip6table_filter16384 0 ip6_tables 28672 1 ip6table_filter iptable_filter 16384 0 ip_tables 28672 1 iptable_filter x_tables 36864 5 ip6table_filter,ip_tables,iptable_filter,ebtables,ip6_tables nfnetlink_queue20480 0 nfnetlink_log 20480 0 nfnetlink 16384 2 nfnetlink_log,nfnetlink_queue bluetooth 512000 0 rfkill 24576 2 bluetooth tun28672 2 sit24576 0 tunnel416384 1 sit ip_tunnel 28672 1 sit nfsd 286720 11 auth_rpcgss61440 1 nfsd oid_registry 16384 1 auth_rpcgss nfs_acl16384 1 nfsd lockd 90112 1 nfsd grace 16384 2 nfsd,lockd sunrpc327680 17 nfsd,auth_rpcgss,lockd,nfs_acl pci_stub 16384 1 vboxpci24576 0 vboxnetadp 28672 0 vboxnetflt 28672 0 vboxdrv 450560 3 vboxnetadp,vboxnetflt,vboxpci binfmt_misc20480 1 bridge114688 0 stp16384 1 bridge llc16384 2 stp,bridge joydev 20480 0 snd_usb_audio 176128 0 snd_usbmidi_lib32768 1 snd_usb_audio snd_hwdep 16384 1 snd_usb_audio hid_generic16384 0 usbhid 49152 0 hid 118784 2 hid_generic,usbhid sr_mod 24576 0 cdrom 57344 1 sr_mod evdev 20480 13 amdkfd122880 1 kvm_amd65536 0 ohci_pci 16384 0 kvm 507904 1 kvm_amd radeon 1490944 2 snd_ca0106 45056 0 psmouse 126976 0 snd_rawmidi32768 2 snd_usbmidi_lib,snd_ca0106 snd_seq_device 16384 1 snd_rawmidi ehci_pci 16384 0 snd_ac97_codec126976 1 snd_ca0106 serio_raw 16384 0 xhci_pci 16384 0 ttm94208 1 radeon r8169 81920 0 pcspkr 16384 0 snd_pcm_oss49152 0 xhci_hcd 172032 1 xhci_pci drm_kms_helper131072 1 radeon ohci_hcd 49152 1 ohci_pci mii16384 1 r8169 snd_mixer_oss 24576 1 snd_pcm_oss ehci_hcd 77824 1 ehci_pci drm 348160 5 ttm,drm_kms_helper,radeon snd_pcm 102400 4 snd_pcm_oss,snd_usb_audio,snd_ac97_codec,snd_ca0106 pata_via 16384 0 firewire_ohci 40960 0 i2c_algo_bit 16384 1 radeon snd_timer 32768 1 snd_pcm snd81920 11 snd_pcm_oss,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_timer,snd_pcm,snd_rawmidi,snd_usbmidi_lib,snd_seq_device,snd_mixer_oss,snd_ca0106 edac_mce_amd 24576 0 usbcore 233472 9 snd_usb_audio,ohci_hcd,ohci_pci,snd_usbmidi_lib,ehci_hcd,ehci_pci,usbhid,xhci_hcd,xhci_pci sp5100_tco 16384 0 soundcore 16384 1 snd ahci 36864 1 ac97_bus 16384 1 snd_ac97_codec k10temp16384 0 edac_core 57344 0 sg 32768 0 i2c_piix4 24576 0 shpchp 36864 0 libahci32768 1 ahci usb_common 16384 1 usbcore wmi20480 0 8250_fintek16384 0 asus_atk0110 20480 0 acpi_cpufreq 20480 1 button 16384 0 processor 36864 1 acpi_cpufreq hwmon_vid 16384 0 loop 28672 0 firewire_sbp2 24576 0
