CentOS 4 installer sees /dev/sda, but after boot it's /dev/sdb

Jeff Larsen jlar310 at gmail.com
Thu May 1 14:23:15 CDT 2008


On Thu, May 1, 2008 at 8:27 AM,  <Scott_Collier at dell.com> wrote:
> Hey Jeff,
>
>  I've seen boot disks change when some of our customers add MD arrays.
>  Here's a old process I created using udev rules to flip them back.  You
>  can test it if you like....  You have a bit of a different issue because
>  fdisk isn't recognizing /dev/sda., but I thought I'd pass this along
>  anyway.
>
>
>
>  Here's what happened with my customer:
>
>  Customer installed RHEL4.4 on a PE6850 w/ PERC5/I controller attached to
>  internal drives and everything was fine.  Then customer attached a
>  MD1000 to a PERC5/E controller and rebooted and the devices were
>  swapped.  Meaning /dev/sda (Previously internal) were now /dev/sdb and
>  /dev/sdb (Previously external) are now /dev/sda.
>
>  Here's output of broken "fdisk -l"
>
>  Disk /dev/sda: 5495.1 GB, 5495142219776 bytes
>  255 heads, 63 sectors/track, 668079 cylinders
>  Units = cylinders of 16065 * 512 = 8225280 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
>  /dev/sda1               1      267350  2147483647+  ee  EFI GPT
>
>  Disk /dev/sdb: 146.6 GB, 146695782400 bytes
>  255 heads, 63 sectors/track, 17834 cylinders
>  Units = cylinders of 16065 * 512 = 8225280 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
>  /dev/sdb1   *           1        5099    40957686   83  Linux
>  /dev/sdb2            5100        6374    10241437+  83  Linux
>  /dev/sdb3            6375        7649    10241437+  83  Linux
>  /dev/sdb4            7650       17834    81811012+   5  Extended
>  /dev/sdb5            7650        8924    10241406   83  Linux
>  /dev/sdb6            8925        9185     2096451   82  Linux swap
>
>
>
>  As you can see, devices are flipped.
>
>
>  To fix the problem, we:
>
>  Use udevinfo to get unique attributes about the devices you are going to
>  write a rule for.
>  udevinfo -a -p /sys/block/sda | grep -i model
>  Gives the following output:     SYSFS{model}="LD 0 RAID1  139G"
>  b.      udevinfo -a -p /sys/block/sda | grep -i size
>  Gives the following output:     SYSFS{size}="286515200"
>  c.      udevinfo -a -p /sys/block/sdb | grep -i model
>  Gives the following output:     SYSFS{model}="PERC 5/E Adapter"
>  SYSFS{size}="10732699648"
>
>  2.      Now that we have unique information about each device, we can
>  write a udev rule and rename each device.
>  cd /etc/udev/rules.d
>  vi 51-perc.rules
>  Place the following into the file:
>  SYSFS{size}="10732699648", SYSFS{model}="PERC 5/E Adapter", NAME="sdb"
>  SYSFS{size}="286515200", SYSFS{model}="LD 0 RAID1  139G", NAME="sda"
>  c.      Issue a "udevstart"
>
>
>  Now output of fixed "fdisk -l"
>
>
>  Disk /dev/sda: 146.6 GB, 146695782400 bytes
>  255 heads, 63 sectors/track, 17834 cylinders
>  Units = cylinders of 16065 * 512 = 8225280 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
>  /dev/sda1   *           1        5099    40957686   83  Linux
>  /dev/sda2            5100        6374    10241437+  83  Linux
>  /dev/sda3            6375        7649    10241437+  83  Linux
>  /dev/sda4            7650       17834    81811012+   5  Extended
>  /dev/sda5            7650        8924    10241406   83  Linux
>  /dev/sda6            8925        9185     2096451   82  Linux swap
>
>  WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util
>  fdisk doesn't support GPT. Use GNU Parted.
>
>
>  Disk /dev/sdb: 5495.1 GB, 5495142219776 bytes
>  255 heads, 63 sectors/track, 668079 cylinders
>  Units = cylinders of 16065 * 512 = 8225280 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
>  /dev/sdb1               1      267350  2147483647+  ee  EFI GPT
>
>
>
>  Now you can see that the devices are flipped back to normal.
>
>  Two more points of interest:
>
>  You can turn on udev logging in "/etc/udev/udev.conf "  You can just
>  change logging from "no" to "yes"
>  This outputs udev messages into "/var/log/messages", then just "tail -f
>  /var/log/messages" when you issue "udevstart" and look at errors, they
>  are pretty specific
>  You can grab a absolute unique attribute by calling "scsi_id" in your
>  udev rules file.  Not covered here.
>
>
>  Thanks
>  Scott Collier
>
>
>
>
>
>
>
>  -----Original Message-----
>  From: linux-poweredge-bounces at dell.com
>  [mailto:linux-poweredge-bounces at dell.com] On Behalf Of Jeff Larsen
>  Sent: Thursday, May 01, 2008 12:00 AM
>  To: linux-poweredge-Lists
>  Subject: Re: CentOS 4 installer sees /dev/sda, but after boot it's
>  /dev/sdb
>
>
>
> On Wed, Apr 30, 2008 at 7:50 PM, jeff nichols <jeff.n at linuxmail.org>
>  wrote:
>  >
>  >  I've seen the virtual cdrom take /dev/sda on 9th gen servers - do you
>  have a DRAC5?
>
>  Yes we have DRAC5. But we used virtual CD media to install and the first
>  HD RAID array during install was /dev/sda. Boot disk array became sdb
>  after first live boot. Makes no sense that it changes.
>  Maybe it has something to do with different hardware drivers being
>  available in the installer kernel versus live kernel. Perhaps a question
>  for the CentOS list. I wonder if other distros see the same thing.
>
>  I've pretty much just decided to live with it, though it challenges my
>  obsessive-compulsive nature. Fortunately, CentOS uses disk labels for
>  booting and /etc/fstab, so the only gotcha in the future if the device
>  assignment changed would be database configuration for direct disk
>  device access.
>
>  --
>  Jeff
>
>
>
> _______________________________________________
>  Linux-PowerEdge mailing list
>  Linux-PowerEdge at dell.com
>  http://lists.us.dell.com/mailman/listinfo/linux-poweredge
>  Please read the FAQ at http://lists.us.dell.com/faq
>

Thanks for all that Scott. Very helpful. Turns out that /dev/sda is
the virtual floppy. We never use that so if the DRAC will allow us to
disable it, but leave the virtual CD enabled, we may try that. But
again, this is obsessive compulsive disorder at work, there is no real
fault with the system. Everything is working fine.

-- 
Jeff



More information about the Linux-PowerEdge mailing list