Richard Jones' Log: Linux fun with grub and mdadm
Last weekend I decided to upgrade to Ubuntu's latest pre-release, Feisty Fawn (release 5) via Kubunutu.
Everything went swimmingly except there were two hitches, both disk-related. My motherboard has a dodgy SATA socket resulting in the BIOS not correctly detecting a drive plugged into that socket about once in every three boots*. There's no subsequent problems with the drive - it's just on boot-up. The result of this is that the BIOS ordering of drives (boot ordering) is slightly different to how Linux sees the drives. This in turn confuses grub which can't seem to figure out what disk to boot from when it configures itself. In the process of solving this issue I discovered the "device.map" file which solved my problem for a little while. Much rebooting and fiddling with grub ensues. I give thanks to the bright person who decided to make the Kubuntu (and presumably Ubuntu "proper") install disk a Live CD giving me access to both a terminal and a web browser with 'net access. Very, very cool.
* this has been a minor annoyance in the time I've had the computer but it's not annoyed me enough - until now with the grub experience - to try to solve it. Until now it just meant that I had to manually hit the boot menu in the BIOS to boot up. A minor inconvenience. The solution was pretty simple - just shuffling the three disks so they avoided SATA port 1 and used ports 2, 3 and 4. This solved my grub problem and as a secondary result I can now boot my computer without manual intervention ;)
It does bring me to my second problem: shifting the drives confused my RAID setup so I had to invoke the mystical mdadm to fix that up. Someone really needs to work on mdadm's interface... My biggest problems stemmed from two things:
- Trying to figure out the correct invocation to make it add both disks to my RAID array.
- Realising that if I got the command-line invocations incorrect I would receive no error, just nothing would happen.
Yes, if I invoked "mdadm /dev/md0 --detail" I would receive some output, but if I instead said "mdadm --detail /dev/md0" I would receive the detailed output that I was actually after. Also, if I "mdadm --manage /dev/md0 -a /dev/sdc4" to add my disk, nothing would happen. No error. Certainly no disk being added to the array. Changing the "-a" to "--add" made it do the right thing. There were numerous other times that I was scratching my head, chasing up false leads tryig to make the damn thing work all because I'd misread a usage statement, given mdadm the slightly wrong argument and it'd just ignored the argument rather than raising an error.
All the other disks are being mounted by uuid -- bloody good idea that!
I haven't looked into whether mdadm.conf can take disk uuids (or labels).
Sean Reifschneider has mentioned disk labels in the past as a solution to the moving "/" partition problem. I've not had a chance to look into the details.
I don't know how it works with raid, but mounting by uuid or disk label (man e2label) is really what you want to be doing. I had serious problems with the feisty upgrade on my mac precisely because I wasn't doing that.