I never saw this under 2.6.18-rc3-mm*, and for a while -rc4-mm1 wasn't doing it either. However, I'm now seeing a reproducible problem with -rc4 and later... Setup: 1 disk, basically 2 partitions, an ext3 /boot and a LVM space that / and other filesystems live in. Of late, the 'vgscan' command has been consistently failing to find the volume group, so we end up falling off the end of the initrd startup script when there's no init left. It's not a every-time thing - after 2 to 10 attempted boots, one will work. I was suspecting hardware issues after some problems caused a motherboard swap last week - but -rc3-mm2 is 100% able to boot every time. It *seems* to be a timing-related thing - adding 'loglevel=7' to the boot generates more printk traffic, which seems to slow it down enough to improve chances. My personal guess is that -rc4 is a few percent faster at booting, and the initrd (running 'nash') used to take long enough that the hotplug event that created /dev/sda1 and /dev/sda2 *used* to finish before vgscan got started, but now vgscan is getting going faster and races the hotplug. Any alternative hypothesis, or is it time to dive into the wonders of nash scripting and figure out how to make it wait for hotplug?
Attachment:
pgpCXm0qKqgd5.pgp
Description: PGP signature
- Prev by Date: [PATCH 5 of 23] IB/ipath - drop requirement that PIO buffers be mmaped write-only
- Next by Date: Re: [PATCH 17/17] BLOCK: Make it possible to disable the block layer [try #2]
- Previous by thread: [PATCH 0 of 23] IB/ipath - updates for 2.6.19
- Next by thread: [PATCH 00/18] BLOCK: Permit block layer to be disabled [try #4]
- Index(es):
 |