Sven Hartge wrote:
> I have the same problem as Jesse, roughly since the update to mdadm-3.3
> in Sid.
I am using mdadm 3.3-1 in Sid on the machine I am typing this on now.
But I am using LVM which might be the difference. With LVM the UUIDs
are present but are one layer deeper in the LVM PV layer.
> Suddenly, only UUID symlinks to real devices are present in
> /dev/disk/by-uuid while inside the initramfs, links to device-mapper
> devices or md-devices are missing.
Hmm...
> I am able to boot if I set "GRUB_DISABLE_LINUX_UUID=true" in
> /etc/default/grub, because that sets "root=/dev/md0" instead of
> "root=UUID=...."
Can you verify that the UUID of your root device and the UUID that
doesn't boot on grub's kernel command line are the same?
And old Squeeze system shows me an example. (Couldn't find anything
newer that I am not using LVM upon.)
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-686 root=UUID=afa0808e-1e61-4b83-b0bd-ce98aa89fe64 ro quiet
# blkid
...
/dev/sda5: UUID="afa0808e-1e61-4b83-b0bd-ce98aa89fe64" TYPE="ext3"
The UUIDs match. All is good. Can you check to see if they do or do
not match on your system? I suspect that they do not match and that
is why the system will not boot. Because if they match then it should
work. This is the default when booting Debian Wheezy on installations
(not using LVM).
[An LVM example for comparison so people aren't wondering why it
doesn't have uuids present.
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10-2-amd64 root=/dev/mapper/v1-root ro quiet
With LVM the UUID is stored in the PV and LV metadata.
# pvdisplay | less
...
PV Name /dev/md1
PV UUID Rh2aRI-Y5Ga-1epS-uT03-fFl8-eSTg-gxPEPa
# lvdisplay | less
LV Path /dev/v1/root
LV UUID FtNPli-89Qg-0RoL-U7uX-CPxE-T7m7-Un3vsp
]
Bob
Attachment:
signature.asc
Description: Digital signature