Bugzilla – Bug 860394
ipv6.disable=1 on cmdline delays init completion more than 2 minutes
Last modified: 2014-01-28 16:10:12 UTC
Created attachment 575788 [details] y2logs from host kt400 13.2m0 http installation mailing list thread starter: http://lists.opensuse.org/opensuse-factory/2014-01/msg00078.html To reproduce: 1-include ipv6.disable=1 on Grub Legacy cmdline 2-try to boot Actual behavior: 1-"LVM: activation generator successfully completed ~@8.######" displays on last tty1 line 2-more than 2 minutes pass 3-init proceeds Expected behavior: 1-init completes in less than a minute Notes: 1-Plymouth not installed 2-Happens on at least 5 different installations, possibly as many as 9; most (or all?) 32 bit 3-All installations originally created as 13.1 or older and upgraded to current Factory as long as a month or more ago 4-No wireless* rpms installed; no wireless available on LAN 5-One NIC on eth0; no other NICs 6-NetworkManager not installed 7-LVM is not used 8-RAID is not used 9-Most filesystems EXT2 or EXT3 (no btrfs, no xfs, no reiserfs), several MSDOS 10-happens every boot whether or not 13.1 or older was last booted 11-No apparent evidence of any filesystems having previously been shut down dirty 12-Delay was not occurring on systems when first initialized to Factory shortly after 13.1 release was announced (trouble began sometime in middle to late December, or maybe early January) 13-I did a fresh installation from Factory that did not include samba (server) or nfs-kernel-server on one system and this did not occur on first few boots, but delay did start happening sometime after adding samba and nfs-kernel-server with zypper; this installation no longer exists, but its y2logs are attached
Created attachment 575797 [details] y2logs from host gx27c I found a Factory installation made December 20 (on 32 bit host gx27c), last updated December 29, that did not have this problem. It has neither Wicked nor NetworkManager installed. I added locks: yast2-samba-server, yast2-samba-client, cifs-utils, samba-client, yast2-network, glib-networking, kernel*, sysconfig-network, samba, nfs-kernel-server- wicked-service, wicked, and answered keep obsolete in answer to all questions posed by zypper -v dup. Nevertheless, it now suffers this 2+ minute init delay.
Created attachment 575799 [details] dmesg from host gx27c
Removing the comment 1 locks and repeating zypper -v dup left gx27c with 2+ minute init delay continuing. Head from systemd-analyze blame: 9.091s systemd-fsck@dev-disk-by\x2dlabel-home\x2dp13.service 7.841s systemd-udev-settle.service 6.121s systemd-fsck@dev-disk-by\x2dlabel-fedorap09.service 5.273s systemd-fsck@dev-disk-by\x2dlabel-pub\x2dp15.service 4.892s systemd-fsck@dev-disk-by\x2dlabel-mageiap11.service 4.142s systemd-fsck@dev-sda12.service 3.972s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 3.913s systemd-fsck@dev-disk-by\x2dlabel-usrlcl\x2dp14.service 2.469s systemd-udev-root-symlink.service 2.459s systemd-logind.service 2.376s cycle.service 2.336s wickedd.service 2.263s wicked.service 2.207s systemd-vconsole-setup.service 2.129s rpcbind.service 2.076s lvm2-activation.service 2.040s rsyslog.service 1.783s kmod-static-nodes.service 1.607s lvm2-activation-early.service 1.588s dev-hugepages.mount 1.556s dev-mqueue.mount 1.494s nfs.service 1.493s nfsserver.service 1.433s systemd-modules-load.service 1.364s systemd-remount-fs.service 1.257s cifs.service 1.141s wickedd-dhcp4.service 1.119s wickedd-dhcp6.service 1.111s wickedd-auto4.service
Created attachment 575844 [details] tail of /var/log/zypp/history Before installing these 50 packages on 13.2 host big41 (last completely updated Dec. 12), init took reasonable time, but afterward, it is long delayed same as in previous comments.
Created attachment 575853 [details] /var/log/zypp/history tail with .bash_history tail appended I recloned big41's x86_64 13.1, changed its repos to Factory, then selectively installed groups of packages from among those in comment 4's attachment. The init delay began on installing the following group: 2014-01-25 17:25:02|install|cups-libs|1.5.4-15.1|x86_64||OSS|6e2fbcc0a4591a2df1cafc75413258f39d40d0626612fd91636e81b509b3f452| 2014-01-25 17:25:03|install|cups-libs-32bit|1.5.4-15.1|x86_64|root@big41|OSS|e3df45d9133baf58d5c036c9b7d062a90687f5a9b2cec58c9b370ada54dd4b86| 2014-01-25 17:25:04|install|cups-client|1.5.4-15.1|x86_64|root@big41|OSS|f8eea520e18abd4d1d9156fd61aa719de41cb1c6b107854e4289b39e75618671| # 2014-01-25 17:25:19 cups-1.5.4-15.1.x86_64.rpm installed ok # Additional rpm output: # Updating /etc/sysconfig/cups... # redirecting to systemctl try-restart cups # 2014-01-25 17:25:19|install|cups|1.5.4-15.1|x86_64|root@big41|OSS|dbd805bb2273ec0539a9856c59db209029ea202569db008d629baf3cdb6e8d65| Next I confirmed the problem continues after doing 'zypper -v dup', and is worked around by omitting ipv6.disable=1 from cmdline. Next I removed selected *cups* packages one by one and rebooted after each. Finally after removing cups-1.5.4-15.1 the init delay was gone. To confirm, I booted host gx27b, removed cups (which did not also remove cups-pk-helper, system-config-printer-applet & system-config-printer as on host big41), and found its init delay gone as well.
Does this mean the delay is caused by cups? Beside this why do you disable nowadays IPv6?
(In reply to comment #6) > Does this mean the delay is caused by cups? I don't know how to tell, but I suppose it must be cups-related in some fashion, because removing the package avoids the delay. I also suspect systemd plays some role. > Beside this why do you disable nowadays IPv6? 1-Because I can. :-) 2-AFAICT https://www.kernel.org/doc/Documentation/networking/ipv6.txt has not been revoked. 3-I like simple. I don't like dealing with a complicated subject obfuscated by components I don't need or use. 4-As to specific details of problems encountered in the past with IPV6 I don't remember. I only remember it avoided trouble I don't need.
(In reply to comment #7) > I don't know how to tell, but I suppose it must be cups-related in some > fashion, because removing the package avoids the delay. I also suspect systemd > plays some role. If this happens even without cups.socket and cups.path then it has nothing todo with systemd. And even with cups.socket and cups.path systemd is only the forwarder and nothing more or less.
I reopened bnc#857372 and assigned it to me. I will try to clean up the mess - regardless that my knowledge regarding systemd unit files is very limited. For the full story see bnc#857372 ... ;-) *** This bug has been marked as a duplicate of bug 857372 ***