So if you've recently compiled a kernel without really paying attention (ahem) like me, and you lost your /dev/hdx, check yer /dev/sdx before you go back to 2.6.11.
5.26.2007
2.6.20 broke my friggin raid
Well not really, but it took me a few minutes of poking around to discover that all my IDE drives which are hooked to a Silicon Image PCI0680 card are now following SCSI naming conventions. So now what I thought was a clever attempt at averting trouble in the future by clearly marking all the devices in my system with a shiny silver marker is now just graffiti.
So if you've recently compiled a kernel without really paying attention (ahem) like me, and you lost your /dev/hdx, check yer /dev/sdx before you go back to 2.6.11.
So if you've recently compiled a kernel without really paying attention (ahem) like me, and you lost your /dev/hdx, check yer /dev/sdx before you go back to 2.6.11.
Subscribe to:
Post Comments (Atom)
4 comments:
No one uses that drivers/ide crap these anyways, it's been all libata and udev for years now. Unfortunately it will probably take an rm -fr drivers/ide before anyone starts to take notice ;-)
You aren't even supposed to rely on sdX or hdX anymore. New distributions setup your fstab with UUID instead of device node.
The UUID is assigned when you format and guaranteed to never change as long as you don't format your drives.
assuming your running udev, check out:
/dev/disk/by-uuid
Hot damn, you're right! It looks like my RAID is represented by one UUID there however, the individual drives don't show up. They are listed in /dev/disk though, which is mighty handy. Thanks for the heads up! :)
That is correct. UUIDs come from the filesystem, not the hardware (Assuming that your RAID only has one filesystem.) That's why you can rely on them never changing until you reformat or specifically change it using your FS tools.
Post a Comment