---------- Forwarded message ---------- From: unix syzadmin <unixsyzadmin@xxxxxxxxx> Date: Thu, Mar 15, 2012 at 1:02 AM Subject: Re: The Redhat linux reboot puts me into a maintenance shell because disks are discovered and name differently. To: Barry Brimer <lists@xxxxxxxxxx> This problem was resolved by using "rdblacklist=lpfc" in the kernel line for /etc/grub.conf and rebuilding the initramfs using dracut. The theory is when initramfs is used during boot phase the lpfc module is not used; so none of SAN disks attached to HBA are discovered. ** excerpt from /etc/grub.conf *** title RHEL 6.1 (2.6.32-131.21.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-131.21.1.el6.x86_64 ro root=/dev/rootvg/root.vol rd_LVM_VG=rootvg rd_NO_LUKS rd_NO_MD rd_NO_DM rdblacklist=lpfc LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto initrd /initramfs-2.6.32-131.21.1.el6.x86_64.img ** end ** # dracut --force /boot/initramfs-$(uname -r).img $(uname -r) On Tue, Feb 28, 2012 at 8:05 PM, unix syzadmin <unixsyzadmin@xxxxxxxxx>wrote: > Thanks, > > I am running RHEL 6.1. > > # more /etc/redhat-release > Red Hat Enterprise Linux Server release 6.1 (Santiago) > > # uname -r > 2.6.32-131.21.1.el6.x86_64 > > ***** Some excerpts from /etc/fstab & fdisk **** > > /dev/mapper/rootvg-root.vol / ext4 defaults 1 1 > UUID=9ac96796-d14a-4013-8e5b-a83da60dc95c /boot ext4 defaults 1 2 > /dev/mapper/rootvg-home.vol /home ext4 defaults 1 2 > /dev/mapper/rootvg-opt.vol /opt ext4 defaults 1 2 > /dev/mapper/rootvg-sysinfo.vol /sysinfo ext4 defaults 1 2 > /dev/mapper/rootvg-tmp.vol /tmp ext4 defaults 1 2 > /dev/mapper/rootvg-usr.vol /usr ext4 defaults 1 2 > /dev/mapper/rootvg-var.vol /var ext4 defaults 1 2 > /dev/mapper/rootvg-swap.vol swap swap defaults 0 0 > tmpfs /dev/shm tmpfs defaults 0 0 > devpts /dev/pts devpts gid=5,mode=620 0 0 > sysfs /sys sysfs defaults 0 0 > proc /proc proc defaults 0 0 > > # fdisk -l /dev/sda > > Disk /dev/sda: 598.9 GB, 598879502336 bytes > 255 heads, 63 sectors/track, 72809 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x000957bb > > Device Boot Start End Blocks Id System > /dev/sda1 * 1 66 524288 83 Linux > Partition 1 does not end on cylinder boundary. > /dev/sda2 66 72810 584317952 8e Linux LVM > > > **** End **** > > Are you suggesting to use logical volume / file-system UUID's instead of > the device mapper names in the /etc/fstab? > What about the root & swap LV/file-sytem mentioned in /etc/grub.conf? Can > we use UUID there as well? > > > # grep kernel /etc/grub.conf > kernel /vmlinuz-2.6.32-131.21.1.el6.x86_64 ro > root=/dev/mapper/rootvg-root.vol rd_LVM_LV=rootvg/root.vol > rd_LVM_LV=rootvg/swap.vol rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 > SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto > > > > Thanks, > > On Tue, Feb 28, 2012 at 7:21 PM, Barry Brimer <lists@xxxxxxxxxx> wrote: > >> > The problem; I guess is that the system is discovering & naming the >> disks >> > in different order everytime the server is rebooted. For example the >> > /dev/sda which represents the raid5 device created on local internal SAS >> > disk is discovered as /dev/sdew ... and I guess this is the reason I am >> > being dropped into the maintenance shell. I tell this because after I >> > login to the maintenance shell I see that the /dev/sda represents a 500G >> > SAN disk instead of a 600G internal disk. The internal disk is named >> > /dev/sdew and if I disconnect the fibre cables; the server boots just >> > fine. >> > >> > Is there a way to make sure that the disks are named consistently across >> > reboots? >> > Please suggest or point me in the right direction. >> >> Your /etc/fstab and /etc/grub.conf (really /boot/grub/grub.conf) should >> use >> LABELs to identify filesystems, not devices. RHEL 6 also allows you to >> specify >> filesystems by UUID. I don't know if that works in RHEL 5 or not. >> > > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
