Per Jessen composed on 2016-04-01 10:13 (UTC+0200):
204 seconds for Grub's initrd message to clear, 235 seconds to see a shell prompt with 4.5.0 on TW host big 41.
Hi Felix
there's a lot of information here, too much to dig through. Have you managed to identify where the delays are happening? If it's not in the
Only one delay apparent each.
logs, it must be the initrd loading which you would presumably see.
You seem to be right. The delay is obviously at vmlinuz/initrd load time, as the Grub loading messages stay on screen for the entirety of the delay. The problem is finding a way to troubleshoot. Until this started last year, I had no idea this kind of problem existed. Googling has turning up nothing like it so far. Today I spent time cataloging which have the problem. It's very random as to which kernels/initrds, but so far it's limited to 3 HDs, one of which is a clone of one of the others, made to determine if the disk hardware could be where the fault lies. It's not the disk hardware. The clone has the same problem kernels/initrds, and they go with the disk when moved to a different machine. All problem disks are .5TB or less. Two are old enough that likelihood of 4k sectors is remote. The other, st3500411sv, is plenty new enough that it could have 4k sectors, but fdisk and spec sheet report 512b. So far, the problem has been exclusive to 64 bit installations on EXT4 / filesystems, with one exception. One 32 kernel/initrd has the problem, on the only 64 bit AMD machine I have, using a pair of PATA disks. All others with the problem have only a single HD, and all others are on Intel CPUs and single SATA disks. What may be a new clue is that the problem disks each have at least one installation on which a bunch of dm* modules load, and on which df and mount report partitions by /dev/mapper names instead of by device names. http://fm.no-ip.com/Tmp/Linux/Delays/ contains the day's data collection. big31-linux.txt gx62b-linux.txt hpg33-linux.txt Above list which kernels/initrds do or don't suffer the delays. The others contain the mount, df and lsmod outputs from several installations, among which are two that are outputting /dev/mapper/* instead of /dev/sd*, plus the partitioning logs. None of the problem disk installations include RAID or LVM. However, because I do so much cloning, imaging and hardware shuffling around here, I suspect it's possible some kind of dm or md info escaped somewhere onto the disks with the delays. I don't yet have any ideas how to locate such info if it exists. /proc/mdstat does not exist on any where I've looked for it. Suggestions and ideas welcome. -- "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-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org