[SOLVED] Adding another hard drive changes drive id's in /dev/sd*

explorer · 03-29-2011, 02:27 PM

I have a dual boot computer with slackware_64 13.1 and windows.

I have a 120G ide hard drive that I need to add to my computer.
Adding this hard drive changes the drive device id's and slackware won't boot.

as installed, my drives look like this:
/dev/sda1 thru 4 = /boot / swapspace /home
/dev/sdb2 = windows C drive

When I add the extra hard drive, it looks like this:
/dev/sda1 = new 120 drive
/dev/sdb1 thru 4 = /boot / swapspace /home
/dev/sdc2 = windows C drive

I know there is a way to make an initrid and to use the uuid identifications for the drives, and even use labels instead of the long uuid's, but I'm unfamiliar with this process, so I was hoping somebody that's done this before might point me in the right direction.

Gerard Lally · 03-29-2011, 03:01 PM

Quote:

Originally Posted by explorer

I have a dual boot computer with slackware_64 13.1 and windows.

I have a 120G ide hard drive that I need to add to my computer.
Adding this hard drive changes the drive device id's and slackware won't boot.

as installed, my drives look like this:
/dev/sda1 thru 4 = /boot / swapspace /home
/dev/sdb2 = windows C drive

When I add the extra hard drive, it looks like this:
/dev/sda1 = new 120 drive
/dev/sdb1 thru 4 = /boot / swapspace /home
/dev/sdc2 = windows C drive

I know there is a way to make an initrid and to use the uuid identifications for the drives, and even use labels instead of the long uuid's, but I'm unfamiliar with this process, so I was hoping somebody that's done this before might point me in the right direction.

Run blkid as root to get UUIDs for your partitions.

This is what blkid gives me:

Code:

# blkid
/dev/sda2: UUID="2d064cb9-8c4d-4ba6-83c8-3848f06315b0" TYPE="ext4" 
/dev/sda5: UUID="04816210-adc4-4449-8573-f46f4587bb21" TYPE="swap" 
/dev/sda6: UUID="71de796f-b496-4569-b659-d0737eaac89f" TYPE="ext4" 
/dev/sda7: UUID="530a9350-1b52-40aa-b557-22d930ef50db" TYPE="ext4" 
/dev/sda8: UUID="4700d311-3308-495e-8efd-07aa6d6a1b55" TYPE="ext4" 
/dev/sda9: UUID="26c8b97b-6855-435e-afd2-64f727708e0c" TYPE="ext4" 
/dev/sda10: TYPE="ufs" 
/dev/sda12: TYPE="ufs" 
/dev/sda13: TYPE="ufs" 
/dev/sda14: TYPE="ufs" 
/dev/sda1: TYPE="ufs" 
/dev/sdb5: UUID="34ff2203-315b-4a0d-ba50-b50f789f3300" TYPE="xfs" 
/dev/sdc5: UUID="8c3bbf70-673a-4913-8fc2-70e524ef4c95" TYPE="ext2" 
/dev/sdc6: LABEL="fat32" UUID="4D8A-97CB" TYPE="vfat" 
/dev/sdd5: UUID="2B8678E41A7DC274" TYPE="ntfs"

I have four disks, with Slackware, Salix, NTFS and NetBSD partitions.

A quick way to get this information into your /etc/fstab file is to append it and edit the fstab file accordingly:

Code:

# blkid >> /etc/fstab

Now edit /etc/fstab as root.

You will see a line with /dev/sdb1 and its mount options.

eg.

Code:

/dev/sdb1 /boot ext4 defaults 1 2

You will see another line at the bottom with the UUID for /dev/sdb1

Code:

/dev/sdb1 UUID="71de796f-b496-4569-b659-d0737eaac89f" TYPE="ext4"

Take the relevant information from both of these lines and merge it to produce a third line as follows:

Code:

UUID=71de796f-b496-4569-b659-d0737eaac89f /boot ext4 defaults 1 2

This is the line you want to keep for /dev/sdb1. Delete the other two lines.

Do the same for each partition. /dev/sdb2, /dev/sdb3, etc.

Warning:

Make sure to delete all the lines you appended to the end of /etc/fstab earlier. Make sure as well to delete the lines you already had in /etc/fstab once you have properly replaced them with the UUID referenced line, mount point and mount options.

In short:

delete:

Code:

/dev/sdb1 /boot ext4 defaults 1 2

delete:

Code:

/dev/sdb1 UUID="71de796f-b496-4569-b659-d0737eaac89f" TYPE="ext4"

keep:

Code:

UUID=71de796f-b496-4569-b659-d0737eaac89f /boot ext4 defaults 1 2

And the same for the other partitions which have a UUID reference.

justwantin · 03-29-2011, 03:26 PM

When I put 2 sata drives in this box for storage my Slackware and Salix installs on an ide drive seen as sda were then on sdc.

To fix this I had to changed my hdd boot priority in the BIOS so that the ide drive (sdc) was first.

The root file system where my original /etc/lilo.conf resided was now located on /dev/sdc1

I booted up the computer using a rescue disk, edited my lilo.conf to match the changed paths then used chroot to run lilo on sdc1.

I used gparted live on a usb for my rescue system and did something like this.

Quote:

mkdir /sdc1
mount /dev/sdc1 /sdc1
cd sdc1
mcedit /etc/lilo.conf # change paths accordingly, save (F2) and quit
chroot /sdc3 sbin/lilo

I going on memory so in case missed something, google chroot+lilo+rescue.

explorer · 03-29-2011, 09:20 PM

Thanks for the replies gezley and justwantin.

Just wantin - the lilo os selector screen still loads on startup, and windows will start so I think I'm ok with my preferred boot drive in cmos. Thanks.

gezley - that looks do-able, and good directions there. One question - what about lilo ? Won't I need to reconfigure the lilo.conf and run lilo again ? If I am booted up using the DVD while reconfiguring my fstab, will lilo run correctly from there or do I even need to worry about running lilo again ?
Does lilo take direction from the fstab to start slackware with ? I'm not real clear on that.

Gerard Lally · 03-29-2011, 09:33 PM

Quote:

Originally Posted by explorer

Thanks for the replies gezley and justwantin.

Just wantin - the lilo os selector screen still loads on startup, and windows will start so I think I'm ok with my preferred boot drive in cmos. Thanks.

gezley - that looks do-able, and good directions there. One question - what about lilo ? Won't I need to reconfigure the lilo.conf and run lilo again ? If I am booted up using the DVD while reconfiguring my fstab, will lilo run correctly from there or do I even need to worry about running lilo again ?
Does lilo take direction from the fstab to start slackware with ? I'm not real clear on that.

Best thing to do is disconnect the offending disk and boot as normal into Slackware. Then follow my instructions to substitute UUIDs for devices in /etc/fstab. You shouldn't need to run lilo. It seems to be configured OK. What is happening is that when you connect the third disk your root partition in Slackware is changing from /dev/sda2 to /dev/sdb2 and Slackware is unable to boot as a result. It appears from this that lilo is installed to the MBR so no need to reinstall. The Slackware partitions mount points need to remain the same no matter how many disks are in the case and using UUIDs achieves this.

Once you have fstab set up shutdown the computer and reconnect the new disk. Slackware should now boot up properly. You can then follow the same procedure to add the new disk UUID to fstab as well.

explorer · 03-29-2011, 10:08 PM

Quote:

Originally Posted by gezley

Best thing to do is disconnect the offending disk and boot as normal into Slackware. Then follow my instructions to substitute UUIDs for devices in /etc/fstab. You shouldn't need to run lilo. It seems to be configured OK. What is happening is that when you connect the third disk your root partition in Slackware is changing from /dev/sda2 to /dev/sdb2 and Slackware is unable to boot as a result. It appears from this that lilo is installed to the MBR so no need to reinstall. The Slackware partitions mount points need to remain the same no matter how many disks are in the case and using UUIDs achieves this.

Once you have fstab set up shutdown the computer and reconnect the new disk. Slackware should now boot up properly. You can then follow the same procedure to add the new disk UUID to fstab as well.

Thanks again Gezley - OK, gotcha now. With the unique uuid's it doesn't matter if a partition changes from /dev/sda1 to /dev/sdc1 or not as it's looking for the unique uuid which doesn't change.

Ill give it a try either later tonight or tomorrow and post my results back here.

explorer · 03-30-2011, 10:43 PM

I finally got around to trying this today. Before hooking up the extra hard drive, I edited my fstab to use the UUID's per your instructions. Then I rebooted to make sure it all worked right and it did, no problem. Then I shut it down, hooked up the extra hard drive and rebooted, but it wouldn't boot - same problem as before, couldn't find the root partition, acts like it still looking for "/dev/sda2".

I unplugged the extra hard drive, rebooted and it came up fine again without the extra drive. My question is again about lilo. When lilo was installed to the mbr, the lilo.conf contained:

image = /boot/vmlinuz
root = /dev/sda2
label = Linux_64
read-only

and it acts like it's still looking for root on /dev/sda2. Can I use UUID's in lilo.conf and run lilo again ? If so, what syntax - "root=UUID=40ae1f29-0ac1-4234-84b8-92a61ed34d81" ? and what about the "image=/boot/vmlinuz" section ?

bgeddy · 03-31-2011, 12:21 AM

I usually find it easier to apply a label to my partitions and use that in fstab and lilo.conf. However as you have gone down the UUID road you need to fix fstab and lilo.conf to accomodate for the UUIDs. Then change the root line to look like this in lilo.conf root="UUID=40ae1f29-0ac1-4234-84b8-92a61ed34d81" - note the quotes. The thing with the LABEL option is you can apply meaningful labels like ROOT, SWAP, HOME etc and use those - I find this more natural than strange long UUIDs.
You need to change fstab to reflect UUIDs of your root, any other, and swap mount points. It's all detailed in man fstab,man mkswap and man blkid. Have a look at man e2label and man tune2fs if you decide to go down the label route

Quote:

and what about the "image=/boot/vmlinuz" section

The image part is only relevant when you actually run lilo so in your case you need the /boot directory mounted and accessable when you run lilo. It's not relevant at boot up as the links to the kernels on disk have already been set when lilo was ran (installed). The "root=" part is passed to the kernel at boot up so this bit is relevant at boot up time.

eternauta2001 · 03-31-2011, 10:47 AM

Edit lilo.conf, not use root=..., use addappend=" root=UUID=<UUID number>". You need create a initrd file (read /boot/README.initrd file)

Code:

image = /boot/vmlinuz
#root = /dev/sda2
addapend= " root=UUID=ed276242-bf16-4c64-b257-768890202a9e"
initrd = /boot/initrd.gz
label = Linux_64
read-only

explorer · 03-31-2011, 01:02 PM

Quote:

Originally Posted by eternauta2001

Edit lilo.conf, not use root=..., use addappend=" root=UUID=<UUID number>". You need create a initrd file (read /boot/README.initrd file)

Code:

image = /boot/vmlinuz
#root = /dev/sda2
addapend= " root=UUID=ed276242-bf16-4c64-b257-768890202a9e"
initrd = /boot/initrd.gz
label = Linux_64
read-only

What will the initrd.gz do for me ?

explorer · 03-31-2011, 03:00 PM

On a different less important test machine running the same version of slackware, I changed the fstab to use UUID's, and created a initrd file and added it to lilo.conf, and modified the root= line in lilo.conf to:

addappend= " root=UUID=ed276242-bf16-4c64-b257-768890202a9e"

and ran lilo to update with the changes, and rebooted and everything worked fine.

When I make the initrd on the other main computer, the extra hard drive won't be attached, so the root partition at that time will be /dev/sda2 - but it will change to /dev/sdb2 once the drive gets attached. So should I pass the -r argument to it with what I know will be the root partition after I shutdown and attach the extra drive ? like this:
"mkinitrd -c -k 2.6.33.4-smp -f ext4 -r /dev/sdb2" ?

Thanks for all the help

explorer · 04-01-2011, 09:09 AM

Quote:

Originally Posted by eternauta2001

Edit lilo.conf, not use root=..., use addappend=" root=UUID=<UUID number>". You need create a initrd file (read /boot/README.initrd file)

Code:

image = /boot/vmlinuz
#root = /dev/sda2
addapend= " root=UUID=ed276242-bf16-4c64-b257-768890202a9e"
initrd = /boot/initrd.gz
label = Linux_64
read-only

OK, got it all working last night. I did have to create an initrd file which was pretty straight forward. Thanks for all of the help with this everybody, I'll mark this thread solved.