Re: Boot failure since 3.3-rc?

["Sune Mølgaard" <sune@molgaard.org>]

Problem solved.

At some point between 3.3-rc3 and 3.3-rc4, something has made the uuids 
in /dev/disk/by-uuid/ different from the uuids that are embedded in md 
raid member v 0.90 metadata.

Failure at my end was caused by my adding (mdN) entries to 
/bot/grub/device.map at some time in the past, mapping them to the 
entries there.

Changing said entries to point to symlinks in /dev/disk/by-id solved 
this for me.

Problem was compunded by the use of initrd since, as one will readily 
surmise post-hoc, a kernel with no other problems will boot if the 
corresponding initrd image was built under a kernel with the old 
behaviour wrt. to /dev/disk/by-uuid mappings, thus prompting one to "git 
bisect good", whereas the kernel built while being booted in that 
kernel, with the initrd image being built under it will fail if it 
exhibits the new behaviour, leading to an off-by-one in the binary 
search of git bisect.

This mail is meant jointly as a "problem solved" message to this list, 
and as explanation for posterity if someone else happens to run into 
similar problems.

Initial confusion was mainly due to the lack of an attached monitor, the 
acquirement of which showed the eroor to be one of failure to mount the 
root fs, and even if that might have been seen via netconsole, I decided 
to order one before realising that some of the kernels would label my 
two ethernet cards differently than what udev picked up at one time and 
made permanent...

In closing: Thank you all for your input and sorry for the noise.

Best regards,

Sune Mølgaard

-- 
Nothing exists except atoms and empty space; everything else is
opinion.
- Democritus