Will hopefully get to report this tomorrow to the Grub folks and the Debian maintainer, but basically it looks like the grub in Lenny can’t cope with systems with lots of disks. We have two storage systems that we use software RAID on and seem to have hit a few problems with grub.
- grub-mkdevicelist only iterates over the first 16 SCSI drives, so if your boot partition is beyond /dev/sdp then you’ll get an error about it not being able to find the boot partition. This is hard coded into a loop in grub-mkdevicelist.c so you can tweak that up to 25 disks safely.
- if you have more than 25 drives (as we do on one system) you’ll hit the next problem as your devices start getting called
/dev/sdaa,/dev/sdab, etc.. grub-mkdevicelist doesn’t handle that correctly. If you bump the number in that loop beyond 25 as it will start trying to find/dev/sd{,/dev/sd|, etc, which it then rejects as they don’t exist. Again that’s fairly easy to work around with a conditional check inget_scsi_disk_name()to at least cope with thesd??pattern (Reported as bug #514967). This then leads to the last problem of.. - Even having the correct device map when your boot device is on
/dev/sdab1still results in Grub in Lenny not being able to locate the boot partition, and we’ve not had time to chase that down any further (reported as bug #514976).
Comments of the type “serve you right for having too many disks” will be ignored.. 😉
Serve you right for having too many disks !
Sorry Andrew, did you say something ? 🙂
Tried using UUID’s or labels in grub? It also makes thing easier to maintain since you can have LABEL=Debian, LABEL=SWAP, LABEL=boot, etc… Don’t know if this would fix grub or not since it might still be grabbing the raw drive entries in its scan but if the problem is occurring because or the extra letters after sdz then maybe it is smart enough to look in /dev/disc/by-label/Debian
Also try using lvm since it makes its own /dev/ entries that might work in grub.
I suspect the problem is the other way around, it’s trying to identify /dev/sdag1 from looking in /proc/mounts and not finding it in the device map.
OK I’ve reported those two bugs, they’re bug #514967 for the device.map creation issue and bug #514976 for the problem with update-grub finding /boot even when device.map is correct.