LVM waits for seven minutes (see latest post)

fumbles · 2012-01-15 10:44:13

Once upon a time my computer powered up in ~40 seconds. Alas those days are gone! Nowadays there is a seven minute (approx.) pause between GRUB and any output on the screen.

There are no errors in any log or dmesg that I can find. After GRUB runs there appears to be IO activity and a blinking cursor.

I *think* this started happening shortly after an upgrade.

# uname -a
Linux mediapc 3.1.9-1-ARCH #1 SMP PREEMPT Fri Jan 13 12:43:42 CET 2012 x86_64 AMD E-350 Processor AuthenticAMD GNU/Linux

Any ideas?

Last edited by fumbles (2012-01-20 13:57:23)

thisoldman · 2012-01-15 12:48:09

People will need to know if you are booting to console or X. Log-in manager?

Have you tried booting with the fallback kernel or another OS to compare?
Have you any ignored pacnew or pacsave files? Any alerts in the pacman log that you might have missed?
Have you checked for filesystem errors?

vacant · 2012-01-15 15:24:59

Is the disk access light on during the delay? I've had this when the BIOS thinks the disk is dirty, like after a power cut.

If so I'd check your shutdown procedure, try going to "init 1" first, do a "sync" then watch for messages after typing "halt" (or shutdown, reboot etc).

fumbles · 2012-01-17 11:33:18

thisoldman wrote:

People will need to know if you are booting to console or X. Log-in manager?
Have you tried booting with the fallback kernel or another OS to compare?
Have you any ignored pacnew or pacsave files? Any alerts in the pacman log that you might have missed?
Have you checked for filesystem errors?

Booting to X, Y or Z make no difference as the seven minute pause is during the load of the kernel and once loaded everything works fine.

I have tried the fallback kernel and just booting to single user, both have a seven minute pause. I don't have any other OS to boot.

Yes and most likely, and they would be gone now due to logrotate.

fsck returns ok.

vacant wrote:

Is the disk access light on during the delay? I've had this when the BIOS thinks the disk is dirty, like after a power cut.
If so I'd check your shutdown procedure, try going to "init 1" first, do a "sync" then watch for messages after typing "halt" (or shutdown, reboot etc).

Why yes it is! I'll give it a go

Thanks for your help

vacant · 2012-01-17 12:46:15

I should add that under the "dirty disk" condition the disk access light is constantly on, plus I noticed grub was also a bit slower to load. A few minutes after a slow boot/login the constant disk access light goes out after whatever check the firmware is doing has finished.

fumbles · 2012-01-18 12:05:07

Well I know what is causing the slowness, and the winner is ..... LVM! Went into single user mode and looked at the kernel loading and it was stuck on LVM. Once the system was up I deactivated one of the volume groups then went to activate it again and had to wait seven minutes for it to return! So ... why is this happening!

fumbles · 2012-01-20 11:28:51

I did a vgchange -vvv -a -y and captured the output.

    Creating vg04-tmbkup_20120102-cow
        dm create vg04-tmbkup_20120102-cow LVM-R2jSaEIobw4rZo0sy4x3bdVksbwX0XWbtn0kQ5ALg8aUJIXUv6n78AQunJhv2GRn-cow NF   [16384]
    Loading vg04-tmbkup_20120102-cow table (254:18)
        Adding target to (254:18): 0 268435456 linear 8:17 3538289024
        dm table   (254:18) OF   [16384]
        dm reload   (254:18) NF   [16384]
        Table size changed from 0 to 268435456 for vg04-tmbkup_20120102-cow

It waited around there for 99% of the time.

  LV                VG   Attr   LSize   Origin Snap%  Move Log         Copy%  Convert
  lvol9             vg04 owi-ao 208.00g                    lvol9_mlog  100.00        
  tmbkup_20120102   vg04 swi-a- 128.00g lvol9   65.70

Last edited by fumbles (2012-01-20 13:55:50)

atlantis · 2012-01-20 20:55:14

I can confirm this behaviour.

I have LVM on top of an ecrypted partition. After the first fresh install, grub and kernel image loading was very fast, like a fraction of a second. Already after the first kernel upgrade the kernel image loading got much longer, about 5 seconds, and stayed like that ever since.

Ok, 5 seconds is still much faster than 7 minutes, but I think the underlying problem is the same. Didn't analyze it yet in more detail, however.

After one of the several upgrades I succeeded to get rid of the problem: I rerun mkinitcpio. But after the next upgrade the problem was back, and I couldn't get rid of it anymore.

AsmundEr · 2012-01-31 14:11:03

Atlantis: I was having a similar issue as yours, with about 10 sec. waiting. I finally hunted down the problem: In mkinitcpio.conf, I had the "resume" hook before the "lvm2" hook, which causes the system to wait for 10 sec to see if it can find the resume partition, which of course it can't because lvm is not loaded yet.

I also had "fastboot quiet" in my kernel line in Grub's menu.lst, so the message "Waiting 10 sec for /dev/G0-lswap" was never printed. When I removed those kernel options for debugging, the problem was immediately apparent.

Maybe this is also the problem in your case? At least check your kernel options to see that it is not set to "quiet", which makes debugging difficult.

Arch Linux

#1 2012-01-15 10:44:13

LVM waits for seven minutes (see latest post)

#2 2012-01-15 12:48:09

Re: LVM waits for seven minutes (see latest post)

#3 2012-01-15 15:24:59

Re: LVM waits for seven minutes (see latest post)

#4 2012-01-17 11:33:18

Re: LVM waits for seven minutes (see latest post)

#5 2012-01-17 12:46:15

Re: LVM waits for seven minutes (see latest post)

#6 2012-01-18 12:05:07

Re: LVM waits for seven minutes (see latest post)

#7 2012-01-20 11:28:51

Re: LVM waits for seven minutes (see latest post)

#8 2012-01-20 20:55:14

Re: LVM waits for seven minutes (see latest post)

#9 2012-01-31 14:11:03

Re: LVM waits for seven minutes (see latest post)

Board footer