On 2014-01-23 01:59 (GMT-0500) Felix Miata composed:
On 2014-01-21 19:14 (GMT-0500) Felix Miata composed:
On 2014-01-21 14:57 (GMT-0500) Felix Miata composed:
On 2014-01-16 02:26 (GMT-0500) Felix Miata composed:
Boot takes over 2.4 minutes. 13.1 only takes about 1/3 of that on the adjacent identical size and type partition.
I think it likely Cristian was right that some kind of race is going on.
Previous this thread was about host gx27b, but now that I've freshly updated gx150, it has the same long delay. Both are 32 bit, former using desktop kernel, latter using default.
Same problem after freshly updating Factory 13.2 host gx280. :-( Previous update was about 8 weeks ago, and delay was not happening.
Boot time is as expected (reasonable) with fresh HTTP Factory installation to 32 bit host kt400 (with kernel-default). Previous hosts mentioned in this thread were all (IIRC) cloned from 13.1, then upgraded to Factory via zypper dup, so now I suspect is zypper dup is somehow failing to account for something changed from 13.1 to 13.2.
Update: kt400 has the problem now. Both nfs-kernel-server and samba were omitted from installation, which I added with zypper after a normal speed boot or two. I had to manually turn on nfsserver and cifs in chkconfig, nmb and smb in systemctl. 11.068s lvm2-activation-early.service 9.118s systemd-fsck@dev-disk-by\x2dlabel-12home.service 8.515s systemd-fsck@dev-disk-by\x2dlabel-10evergreen.service 8.266s systemd-fsck@dev-disk-by\x2dlabel-os123p17.service 7.701s ntp.service 7.592s systemd-fsck@dev-disk-by\x2dlabel-08suse112.service 6.810s systemd-fsck@dev-disk-by\x2dlabel-06suse121.service 6.150s systemd-fsck@dev-disk-by\x2dlabel-13usrlcl.service 4.697s systemd-fsck@dev-disk-by\x2dlabel-os131p18.service 3.942s systemd-fsck@dev-disk-by\x2dlabel-os122p09.service 3.878s systemd-fsck-root.service 3.393s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 3.150s nmb.service 2.800s nfsserver.service 2.405s systemd-udev-root-symlink.service 2.290s cycle.service 2.276s systemd-fsck@dev-disk-by\x2dlabel-14pub.service 2.061s nfs.service 1.908s dev-hugepages.mount 1.876s systemd-vconsole-setup.service 1.875s sys-kernel-debug.mount 1.841s dev-mqueue.mount 1.669s lvm2-activation.service 1.433s cifs.service 1.386s systemd-logind.service 1.211s wickedd.service 1.159s rpcbind.service 1.073s systemd-sysctl.service 984ms kmod-static-nodes.service 896ms smb.service 747ms usr-local.mount 710ms systemd-modules-load.service 624ms systemd-udev-settle.service 618ms systemd-remount-fs.service 497ms pub.mount 468ms disks-suse121.mount 427ms disks-suse123.mount 408ms disks-suse131.mount 403ms disks-suse114.mount 346ms disks-suse122.mount 335ms home.mount 334ms wicked.service 312ms user@0.service 302ms systemd-random-seed.service 298ms var-run.mount 295ms disks-boot.mount 267ms systemd-tmpfiles-setup-dev.service 193ms wickedd-dhcp6.service 191ms systemd-udev-trigger.service 186ms wickedd-nanny.service 169ms dev-disk-by\x2dlabel-05swapper.swap 162ms wickedd-dhcp4.service 132ms wickedd-auto4.service 111ms systemd-journal-flush.service 109ms disks-suse112.mount 107ms systemd-user-sessions.service 97ms rc-local.service 54ms systemd-update-utmp.service 52ms systemd-tmpfiles-setup.service 45ms var-lock.mount 43ms systemd-udevd.service 41ms systemd-update-utmp-runlevel.service /tmp/ has 30 wicked.* files accumulated that aren't getting cleared at shutdown or startup. Normal /proc/cmdline: root=LABEL=os132p19 ipv6.disable=1 net.ifnames=0 noresume splash=verbose vga=791 video=1024x768@60 3 Removing ipv6.disable=1 from cmdline eliminates delay. 'systemctl disable wickedd.dhcp6' does not eliminate delay. 'systemctl disable wickedd.nanny' does not eliminate delay. What are wickedd-dhcp6.service and wickedd-nanny.service good for? What's the proper way to get Wicked to not try to use ipv6? How do I just go back to ifup? My LAN needs no "management". I've been unable to get Google to find me anything resembling an openSUSE howto for Wicked, and like most man pages, it's too terse for me to get much out of. I've removed Wicked, but ifup eth0 is failing on account of failure of dependency job for network@eth0.service see journalctl -xn, and I can't tell what the output of the latter is supposed to be telling me. Is it supposedly telling me why by saying "Dependency failed for ifup managed network interface eth0"? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org