1

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 '15 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. – Christopher Perrin Apr 8 '15 at 16:35
  • can I do that retroactively? I can't do any re-formatting on these drives. – Daniel Apr 8 '15 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 '15 at 16:38
0

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 '15 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/… – Vitaly Greck Apr 8 '15 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.