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