[opensuse-factory] boot is taking much too long
15.352s lvm2-activation.service 11.897s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 11.140s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 9.890s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 9.159s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 9.026s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 7.504s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 7.367s network.service 6.848s systemd-fsck@dev-disk-by\x2dlabel-13home.service 5.599s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 5.585s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 4.778s lvm2-activation-early.service 3.014s home.mount 2.750s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 2.667s systemd-fsck@dev-disk-by\x2dlabel-suse114.service 2.651s systemd-fsck-root.service 2.537s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 2.372s disks-E.mount 2.370s systemd-udev-root-symlink.service Why is LVM even in there? I used it briefly 6 or 8 years ago. I never expect to use it again. fsck? Are all partitions going down dirty even when I didn't even boot 13.2 last? -- "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
On Wed, 15 Jan 2014 09:20:26 -0500
Felix Miata
15.352s lvm2-activation.service 11.897s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 11.140s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 9.890s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 9.159s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 9.026s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 7.504s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 7.367s network.service 6.848s systemd-fsck@dev-disk-by\x2dlabel-13home.service 5.599s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 5.585s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 4.778s lvm2-activation-early.service 3.014s home.mount 2.750s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 2.667s systemd-fsck@dev-disk-by\x2dlabel-suse114.service 2.651s systemd-fsck-root.service 2.537s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 2.372s disks-E.mount 2.370s systemd-udev-root-symlink.service
Why is LVM even in there? I used it briefly 6 or 8 years ago. I never expect to use it again.
fsck? Are all partitions going down dirty even when I didn't even boot 13.2 last?
Edit /etc/lvm/lvm.conf and set use_lvmetad to 1 and restart. It's a known issue. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmilasan@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-15 15:27 (GMT+0100) Robert Milasan composed:
Edit /etc/lvm/lvm.conf and set use_lvmetad to 1 and restart. It's a known issue.
Did not visibly help in that there is still a very long pause after LVM activation generator successfully completed @13.276375, after which is ~120.+. What does one need to do to see a boot log equivalent to what sysvinit produced in /var/log/? -- "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
On Wed, 15 Jan 2014 09:52:22 -0500
Felix Miata
Did not visibly help in that there is still a very long pause after LVM activation generator successfully completed @13.276375, after which is ~120.+.
You can then try: systemctl mask lvm2-activation.service systemctl mask lvm2-activation-early.service in case use_lvmetad set to 1 is not helping. The other question, don't know. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmilasan@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 15/01/14 11:52, Felix Miata escribió:
What does one need to do to see a boot log equivalent to what sysvinit produced in /var/log/?
boot with "debug". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-15 11:56 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed:
What does one need to do to see a boot log equivalent to what sysvinit produced in /var/log/?
boot with "debug".
Doing that avoids the init delay entirely. :-p Instead of time landmarks >140., last time in resulting /var/log/messages is 49.389575. -- "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
El 15/01/14 15:52, Felix Miata escribió:
On 2014-01-15 11:56 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed:
What does one need to do to see a boot log equivalent to what sysvinit produced in /var/log/?
boot with "debug".
Doing that avoids the init delay entirely. :-p
You have found a race condition then, the module loading hangs "sometimes" depending the phase of the moon. what kernel version are you using ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-15 15:56 (GMT+0100) Robert Milasan composed:
On Wed, 15 Jan 2014 09:52:22 -0500 Felix Miata wrote:
Did not visibly help in that there is still a very long pause after LVM activation generator successfully completed @13.276375, after which is ~120.+.
You can then try:
systemctl mask lvm2-activation.service systemctl mask lvm2-activation-early.service
in case use_lvmetad set to 1 is not helping.
Those too failed to have any discernible effect. LVM timestamp where delay occurred has dropped from 13.# previously to 9.#. 14.565s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 12.213s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 11.502s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 10.788s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 10.349s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 9.008s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 8.515s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 6.781s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 6.206s systemd-fsck@dev-disk-by\x2dlabel-13home.service 4.811s disks-E.mount 4.522s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 4.041s network.service 3.441s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 2.937s systemd-fsck-root.service 2.505s disks-C.mount 2.467s rpcbind.service 2.438s systemd-udev-root-symlink.service 2.327s systemd-fsck@dev-disk-by\x2dlabel-suse114.service FWIW, all those fsck lines correspond to ext3 filesystems on ICH5 that get mounted via ext4 driver. I tried removing all but 3 ext3 mounts from fstab and rebooting, but without apparent effect. I tried with all but / partition removed, also to no avail. I do on tty1 from splash=verbose fleetingly see early a red FAILED for load kernel modules, but this whether current kernel 3.13.rc7 or prior 3.12.1. -- "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
On 2014-01-15 16:09 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed:
You have found a race condition then, the module loading hangs "sometimes" depending the phase of the moon.
what kernel version are you using ?
32 bit desktop: 3.12.1-2.1 3.13.rc7-1.1 3.13.rc8-2.1.g7ce0a21 I tried a custom boot stanza to load the 13.1 kernel/initrd. There is no similar hang this way, but after about 50. or so it just keeps repeating welcome to emergency mode and several systemd-journal lines. -- "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
El 15/01/14 17:01, Felix Miata escribió:
On 2014-01-15 16:09 (GMT-0300) Cristian Rodríguez composed:
Felix Miata composed:
You have found a race condition then, the module loading hangs "sometimes" depending the phase of the moon.
what kernel version are you using ?
32 bit desktop: 3.12.1-2.1 3.13.rc7-1.1 3.13.rc8-2.1.g7ce0a21
Sorry, I was apparently in the clouds when I replied to this thread and confused this post for another in the general list that asked for a problem related to a kernel module hanging and taking a long time to boot. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata wrote:
Those too failed to have any discernible effect. LVM timestamp where delay occurred has dropped from 13.# previously to 9.#.
14.565s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 12.213s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 11.502s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 10.788s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 10.349s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 9.008s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 8.515s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 6.781s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 6.206s systemd-fsck@dev-disk-by\x2dlabel-13home.service 4.811s disks-E.mount 4.522s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 4.041s network.service 3.441s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 2.937s systemd-fsck-root.service 2.505s disks-C.mount 2.467s rpcbind.service 2.438s systemd-udev-root-symlink.service 2.327s systemd-fsck@dev-disk-by\x2dlabel-suse114.service
---- Is that a breakdown and your system booted in 14.5s or is that cumulative @ 2 minutes? cf. /etc/sysVinit on a large system with 40+TB of disk space: 38 seconds to login prompt from when kernel starts boot (services start ~12 seconds, all FS's mounted at 19.2s... remainder of time is service starts... ----------- If that's a breakdown, you have sysVinit by a good 24 seconds! If it is cumulative, um... that wouldn't be good. If fsck is your prob, tried XFS? (no fsck... file system mounts start at 15.8s and finish at 19.2 for ~16 file file systems w/10 on device mapper). I really hope that is a breakdown, since systemd was supposed to be so much faster than sysVinit...those figures don't make sense... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-15 15:02 (GMT-0800) Linda Walsh composed:
Felix Miata wrote:
Those too failed to have any discernible effect. LVM timestamp where delay occurred has dropped from 13.# previously to 9.#.
14.565s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 12.213s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 11.502s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 10.788s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 10.349s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 9.008s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 8.515s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 6.781s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 6.206s systemd-fsck@dev-disk-by\x2dlabel-13home.service 4.811s disks-E.mount 4.522s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 4.041s network.service 3.441s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 2.937s systemd-fsck-root.service 2.505s disks-C.mount 2.467s rpcbind.service 2.438s systemd-udev-root-symlink.service 2.327s systemd-fsck@dev-disk-by\x2dlabel-suse114.service
Is that a breakdown and your system booted in 14.5s or is that cumulative @ 2 minutes?
That's the head from 'systemd-analyze blame'. Boot takes over 2.4 minutes. 13.1 only takes about 1/3 of that on the adjacent identical size and type partition.
I really hope that is a breakdown, since systemd was supposed to be so much faster than sysVinit...those figures don't make sense...
I think it likely Cristian was right that some kind of race is going on. -- "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
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. -- "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
El 15/01/14 16:33, Felix Miata escribió:
On 2014-01-15 15:56 (GMT+0100) Robert Milasan composed:
On Wed, 15 Jan 2014 09:52:22 -0500 Felix Miata wrote:
Did not visibly help in that there is still a very long pause after LVM activation generator successfully completed @13.276375, after which is ~120.+.
You can then try:
systemctl mask lvm2-activation.service systemctl mask lvm2-activation-early.service
in case use_lvmetad set to 1 is not helping.
Those too failed to have any discernible effect. LVM timestamp where delay occurred has dropped from 13.# previously to 9.#.
14.565s systemd-fsck@dev-disk-by\x2dlabel-fedora20.service 12.213s systemd-fsck@dev-disk-by\x2dlabel-15pub.service 11.502s systemd-fsck@dev-disk-by\x2dlabel-os131p20.service 10.788s systemd-fsck@dev-disk-by\x2dlabel-suse122.service 10.349s systemd-fsck@dev-disk-by\x2dlabel-14usrlcl.service 9.008s systemd-fsck@dev-disk-by\x2dlabel-suse123.service 8.515s systemd-fsck@dev-disk-by\x2dlabel-suse121.service 6.781s systemd-fsck@dev-disk-by\x2dlabel-fedora19.service 6.206s systemd-fsck@dev-disk-by\x2dlabel-13home.service 4.811s disks-E.mount 4.522s systemd-fsck@dev-disk-by\x2dlabel-03boot.service 4.041s network.service 3.441s systemd-fsck@dev-disk-by\x2dlabel-fedora18.service 2.937s systemd-fsck-root.service
FWIW, all those fsck lines correspond to ext3 filesystems on ICH5 that get mounted via ext4 driver. I tried removing all but 3 ext3 mounts from fstab and rebooting, but without apparent effect. I tried with all but / partition removed, also to no avail.
what does your fstab contains exactly ? most of the time is being spent actually fsck'ing the partitions in question. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-21 17:49 (GMT-0300) Cristian Rodríguez composed:
what does your fstab contains exactly ? most of the time is being spent actually fsck'ing the partitions in question.
Removing all fstab lines except for / has no apparent effect: it still takes close to 3 minutes to boot. -- "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
On 2014-01-21 17:49 (GMT-0300) Cristian Rodríguez composed:
FWIW, all those fsck lines correspond to ext3 filesystems on ICH5 that get mounted via ext4 driver. I tried removing all but 3 ext3 mounts from fstab and rebooting, but without apparent effect. I tried with all but / partition removed, also to no avail.
what does your fstab contains exactly ? most of the time is being spent actually fsck'ing the partitions in question.
No need to fsck has become apparent, and certainly not for all possible mounts for every boot regardless of what was booted last. Actual fstab content is identical for 13.1 and 13.2, except for the mount points of the 13.1 & 13.2 partitions and exchange of 1 for 2 at ends of their lines, e.g.: LABEL=os131p20 / ext3 noatime,acl 1 1 LABEL=os132p21 /disks/suse132 ext3 noatime,acl 1 2 LABEL=os131p20 /disks/suse131 ext3 noatime,acl 1 2 LABEL=os132p21 / ext3 noatime,acl 1 1 Each's fstab has 11955 bytes in 150 lines, the vast majority of which are noauto network types nfs or cifs, but removing them all has no effect on boot time. LVM is not used. RAID is not used. Partitions existing number at least 30 on the two systems I'm currently aware of having this trouble. All natives on the two systems I'm currently aware of having this trouble are swap, ext2 or ext3. FAT, NTFS and/or HPFS partitions are present on both systems. -- "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
Felix Miata wrote:
No need to fsck has become apparent, and certainly not for all possible mounts for every boot regardless of what was booted last.
Partitions existing number at least 30 on the two systems I'm currently aware of having this trouble. All natives on the two systems I'm currently aware of having this trouble are swap, ext2 or ext3. FAT, NTFS and/or HPFS partitions are present on both systems.
Have you thought about trying a file system that doesn't need an fsck step? I.e. if it is pausing in the fsck step now, but you tried booting from a partition that didn't need an fsck step, you could disable that step and see if skipping it entirely would speed up your boot. Perhaps it isn't the fsck step at all, but perhaps output is being buffered somewhere and the problem is in one of the steps immediately after the fsck, but isn't getting written to the log or console? Anyway, if fsck seems to be part of the problem -- then boot from a file system which doesn't need an fsck step. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-01-21 14:30 (GMT-0800) Linda Walsh composed:
Anyway, if fsck seems to be part of the problem -- then boot from a file system which doesn't need an fsck step.
It seems to have nothing to do with the problem except for producing inexplicable entries in blame output. No fscking is apparent while watching boot proceed. Stripping all fstab lines except for / has no impact on boot time, and affects only 13.2, not 13.1, on the very same systems using the very same partitions and filesystems. -- "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
On 2014-01-21 14:30 (GMT-0800) Linda Walsh composed:
Anyway, if fsck seems to be part of the problem -- then boot from a file system which doesn't need an fsck step.
It seems to have nothing to do with the problem except for producing inexplicable entries in blame output. No fscking is apparent while watching boot proceed. Stripping all fstab lines except for / has no impact on boot time, and affects only 13.2, not 13.1, on the very same systems using the very same partitions and filesystems. -- "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
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. -- "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
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. -- "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
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
Cups-related: https://bugzilla.novell.com/show_bug.cgi?id=860394 -- "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
Felix Miata wrote:
On 2014-01-21 14:30 (GMT-0800) Linda Walsh composed:
Perhaps it isn't the fsck step at all, but perhaps output is being buffered somewhere and the problem is in one of the steps immediately after the fsck, but isn't getting written to the log or console?
It seems to have nothing to do with the problem except for producing inexplicable entries in blame output. No fscking is apparent while watching boot proceed. Stripping all fstab lines except for / has no impact on boot time, and affects only 13.2, not 13.1, on the very same systems using the very same partitions and filesystems.
What comes after fsck?... On my system it switches from runlevel-S to runlevel-3 and starts bringing up services. It also happens to be the point in my startup log that 'the kernel log daemon terminates and boot logging starts'... I've noticed some output overlaps at times between the boot log and the kernel log , but in my case, the kernel log catches all of the file-system mounts because the normal boot logging doesn't come up until the file systems are mounted. So... maybe you are seeing kernel log type output that catches the end of the fsck's, and ... (ignorance on my part here) -- is it journald that comes up to take over logging? Maybe it isn't logging anything to disk for some period of time during boot in order to speed up boot? i.e. writing a log to disk while loading lots of things, might be thought to be counter-productive if someone was trying to optimize disk reads during boot, but that's guessing on my part... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Cristian Rodríguez -
Felix Miata -
Linda Walsh -
Robert Milasan