LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   loading mvsas driver changes device order, prevents boot (http://www.linuxquestions.org/questions/slackware-14/loading-mvsas-driver-changes-device-order-prevents-boot-4175474284/)

riwi 08-22-2013 10:10 AM

loading mvsas driver changes device order, prevents boot
 
Hi,

I am running slackware64 14.0 with 2 hba/raid sas/sata cards based on Marvel chips. Actual cards are Highpoint Rocketraid 2740 (16x) and Highpoint Rocket 2720SGL (8x). I don't use hardware raid, I just use the available sata connections.

Slackware boots from a SSD which must be /dev/sda as specified in lilo. When I connect the SSD to a port and in BIOS select that drive to be the primary bootdevice slackware starts booting. But after loading the mvsas driver the drive letter order changes. ie. I see that suddenly another disk which is connected to the sas card becomes /dev/sda and Slackware suddenly cannot find the root device anymore.

I have found that when I connect the SSD to port 9 of the 2740 card the /dev/sda stays with the SSD even after loading the mvsas driver. Connecting the SSD on any other port on the card or on the motherboard leads to the renaming of the /dev/sda after loading the mvsas driver which will cause the boot to fail.

The question is :
Is there any way to force that the boot drive /dev/sda remains the same even after loading the mvsas driver?
I would prefer to connect the SSD to the mother board and boot from that port.
Can udev be used for this?
Maybe I could setup the SSD fixed as /dev/sdz and point lilo to /dev/sdz ? How would I do this?

For the data it is not important which drive denomination is used. I use zfs on Linux and LVM to put drives in pools and volume groups and both zfs and lvm find the member drives fine regardless of how they are connected.

Thanks for any help or suggestions.

slacktroll 08-22-2013 10:15 AM

http://nil-techno.blogspot.se/2012/0...s-by-uuid.html

Try that one!

riwi 08-22-2013 10:45 AM

Quote:

Originally Posted by slacktroll (Post 5013863)

That sounds useful. Thanks!

I have used initrd for ext4 in the past, but am now running with the huge kernel where ext4 is already in.
I will try to make an initrd with cpio and see if that will load OK.
After that I can try with the dev-by-id and uuid names.

I'll backup the SSD to another one because this is risky stuff for me :)

riwi 08-30-2013 05:41 PM

I followed the instructions more or less and it seems to have worked OK :) super!

I created a standard initrd with ext4 just like the README.initrd says.
mkinitrd -c -k 3.2.29 -m ext4
which created the /boot/initrd.gz image.

I changed lilo.conf :
from :
boot = /dev/sda
to :
boot = /dev/disk/by-id/ata-Crucial_CT120M500SSD1_1308092BD91E

And a new boot section added to the lilo menu :
Code:

image = /boot/vmlinuz
  initrd = /boot/initrd.gz
  append = "root=UUID=2b90bdfa-94cf-44c1-b7f6-46910ce341c8"
  label = Linux-initrd
  read-only

I found the UUID by command : lsblk -f (which was a new command for me)

I also adapted my /etc/fstab :
Code:

root@riwinas:~# cat /etc/fstab
/dev/disk/by-id/ata-Crucial_CT120M500SSD1_1308092BD91E-part1        /                ext4        defaults        1  1
/dev/disk/by-id/ata-Crucial_CT120M500SSD1_1308092BD91E-part2        /var            ext4        defaults        1  2
/dev/disk/by-id/ata-Crucial_CT120M500SSD1_1308092BD91E-part3        /home            ext4        defaults        1  2
#/dev/cdrom      /mnt/cdrom      auto        noauto,owner,ro,comment=x-gvfs-show 0  0
/dev/fd0        /mnt/floppy      auto        noauto,owner    0  0
devpts          /dev/pts        devpts      gid=5,mode=620  0  0
proc            /proc            proc        defaults        0  0
tmpfs            /dev/shm        tmpfs      defaults        0  0

Now after booting I see the bootdrive is /dev/sdu
Code:

root@riwinas:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdu1        19G  7.5G  10G  43% /
/dev/sdu2        19G  667M  17G  4% /var
/dev/sdu3        19G  1.1G  17G  8% /home
tmpfs            12G    0  12G  0% /dev/shm
raid1            18T  5.4T  13T  31% /raid1
raid3            16T  12T  4.8T  70% /raid3
raid4            18T  13T  5.1T  71% /raid4

Thanks for the useful link.

By the way i did get some warnings on lilo :
Code:

root@riwinas:/boot# lilo
Warning: Internal implementation restriction. Boot may occur from the first
    16 disks only. Disks beyond the 16th will be flagged INACCESSIBLE.
Warning: 'disk=/dev/sdb  inaccessible' is being assumed.  (0810)
Warning: 'disk=/dev/sdc  inaccessible' is being assumed.  (0820)
Warning: 'disk=/dev/sdd  inaccessible' is being assumed.  (0830)
Warning: 'disk=/dev/sde  inaccessible' is being assumed.  (0840)
Warning: 'disk=/dev/sdf  inaccessible' is being assumed.  (0850)
Warning: 'disk=/dev/sdg  inaccessible' is being assumed.  (0860)
Warning: 'disk=/dev/sdh  inaccessible' is being assumed.  (0870)
Warning: 'disk=/dev/sdi  inaccessible' is being assumed.  (0880)
Warning: 'disk=/dev/sdj  inaccessible' is being assumed.  (0890)
Added Linux  *
Added Linux-initrd  +
10 warnings were issued.

I feared this would lead to trouble if the /dev/sda be moved to disk > 16. But apparently it did not matter (as /dev/sdu is clearly > 16th drive).


All times are GMT -5. The time now is 04:47 PM.