yum update installed kernel 2.6.32-504.8.1-el6.x86_64, and was correctly installed to /dev/sdb1/boot (ext3).

Physical drives on the machine (with expected/normal/previous device labels):

 /dev/sdb1,   ext3, 70 MB
 /dev/sda has three:
      sda1    ext3, 42 MB
      sda2    ext4, VolGroup00, 1TB LVM
      sda3    unallocated, 7 MB
 /dev/sdc1,     ext3  2 TB

/etc/fstab looks like:

/dev/mapper/VolGroup00-root    /      ext4
/dev/sdb1                      /boot  ext3
/dev/sdc1                      /data  ext3

Now, for the problem description:

After a reboot, sda becomes sdb and sdb becomes sda, and sdc is MIA (cfdisk, fdisk and gparted report no such device). Needless to say, I haven't dis-/connected any additional devices.

Can someone make a suggestion as to what happened? This is behaviour I would expect after drive cables were moved around, or a new device were connected.

My only guess is the sdc drive has failed (since it doesn't appear in dmesg), however since it's after and sda and sdb, why would those two drives be re-ordered?

Additional details/background: Dell R2970, CentOS 5, last reboot ~March 19 perfectly normal, not sure if kernel was updated then, but probably as that is the only reason this machine would have been reboot.

  • Do you find the drive in BIOS? /dev/sd* Device names are not persistent, check here serverfault.com/questions/519120/…
    – Petter H
    Apr 8, 2015 at 16:35
  • You should use UUIDs if you can in your fstab to avoid these problems. You can the UUID of a partation with blkid. Apr 8, 2015 at 16:35
  • can I do that retroactively? I can't do any re-formatting on these drives.
    – Daniel
    Apr 8, 2015 at 16:37
  • @PetterH If I could reboot the machine, I would do so but the best I can do is look in dmesg at boot time, and the drive sdc doesn't appear.
    – Daniel
    Apr 8, 2015 at 16:38

1 Answer 1


Look at the /etc/udev/rules.d/ or similar location for udev. They contain static rules for your devices which have been recognized and stored (drives, net etc.). Some OSes (or distros) have the lack of this functionality.

In rare cases, for example, changing the udev structure or file structure, the information can be reset. And you will have mess of drives.

Do NOT rely on /dev/sd* names. Never ever on the server environment.

Always DO rely /dev/disk/by-uuid/ names because they don't change. Change any links (at bootloader, kernel startup etc.) for UUIDs.

Actions: reinstall bootloader, update configs, update initrd.

  • thanks. I understand what you wrote about udev, but even udev isn't reliable for device names -- It seems the answer is in the link @petter H placed in his comment. I didn't realize device names would change randomly - I thought only when the hardware changed.
    – Daniel
    Apr 8, 2015 at 17:00
  • @Daniel, udev IS reliable for device names like sda, sdb etc. Look at the rules. It's all there. udev invokes scripts to create device block files and can also remap them to different names. More info: stackoverflow.com/questions/18422500/… Apr 8, 2015 at 18:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .