Problem with hard drives...

Hi everybody. I really hope somebody here can help me, cause it’s causing me some serious headaches. I have a Thinkpad W530 with a Crucial M4 mSATA SSD and a Travelstar 7k750 HDD. I tried to install several distros while both hard drives were in my computer, but no distro would succeed to install a bootloader on my mSATA SSD. But it really bothers me, because I wanted to have it on this drive, and not on the HDD (even thought it’s my primary drive), because I want to use the HDD for storage only, not for system boot. So I want to be able to switch it with other drives anytime I want without losing my bootloader. So basically:

/dev/sda - Primary drive, used for storage only
/dev/sdb - mSATA SSD, used for OS(es) and bootloader

To work around the problems, I removed the HDD from my computer for the time of the installation. I succeeded installing every distro I wanted, including the bootloader, except for openSUSE, which bootloader installation failed every time I tried, no matter the bootloader type I chose or its settings. So, to work around this other problem, I installed openSUSE on my biggest partition, without a bootloader, and on a smaller partition, I installed Backtrack, which bootloader I used to boot on openSUSE. Until then, everything worked. I then updated openSUSE, couldn’t boot it anymore and used Backtrack to repair GRUB once again. My /dev/ now looks like this:

/dev/sda - mSATA SSD

Now, here’s the tricky part that gives me a headache: now that the installation is finished, I reinstalled my HDD in my computer. Pretty simple, there’s only one screw. But here’s the problem: the bootloader points to openSUSE properly, openSUSE starts to boot, and then… stops booting. Apparently, the kernel seems fine, but something else can’t find its way around anymore, and I’m not sure what. All I know is that it’s searching for files on the wrong drive. Obviously, the /dev/ reverted to what it was first. openSUSE is trying to find files on /dev/sda, while they are in fact located in /dev/sdb. Since the physical address of the drives will change with the presence or the absence of the main HDD, isn’t there a way to make openSUSE find the right drive? Per example, GRUB doesn’t get messed up because it uses UUID instead of /dev/sdx. I also checked my Backtrack installation, and everything’s fine.

So, why can’t openSUSE not find my drive anymore, and where can I change the address of the drive manually to fix it? I’m pretty sure all I have to do would be to change /dev/sda to /dev/sdb somewhere in a configuration file.

Thanks for anyone who can give me a cue.

My “fstab” has disk entries such as this:

/dev/disk/by-id/ata-SAMSUNG_HD642JJ_S1JNJ90QA04749-part1 /boot

With that way of addressing drives, it should not matter whether it is “/dev/sda” or “/dev/sdb”.

I’m not sure how you managed to get traditional device names (such as “/dev/sdb”). I seem to recall that there is an option in the installer (probably the partitioning section) to choose between device-name, device-id,label, uuid. The default is device-id.

Maybe if you imported partitioning from a previous install, it just uses what was in the previous “fstab”.

So I just restarted my computer with openSUSE (I was writing from BT), and I got it to boot to full capacity. But I still need to make sure the fix is permanent. Here’s what happened: when the boot halted, I read everything and saw that the system was trying to mount /dev/sda1 to /root. I used a shell to re-enter the same command, changing /dev/sda1 to /dev/sdb1, and it mounted correctly. Then I exited the shell and the boot resumed. I’ll boot again to see if the change was saved (I honestly don’t think it was), and I’ll take a picture of my screen so you can see what happens.

No, I already checked fstab, but it uses the right UUIDs. So it’s something different, but I’m not sure what yet.

So here’s the pictures:

In anybody able to pinpoint the problem? Here’s a copy of my fstab (looks fine to me):

/dev/disk/by-id/ata-M4-CT256M4SSD3_0000000012480356EA85-part3 swap swap defaults 0 0
/dev/disk/by-id/ata-M4-CT256M4SSD3_0000000012480356EA85-part1 / ext4 acl,user_xattr 1 1
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0

Thanks again for your help.

Found exactly what happened. Now, I have to figure out how to implement the solution. Here’s a very good explanation, in case somebody else needs to figure this out:

Linux tip: Finding rootfs during boot

Sounds like you’re trying to create a large multi-boot, but you’ve only sorta described one install, and that’s Backtrack(I assume v5) which is based on Ubuntu which uses a Grub2 bootloader. You didn’t describe any of the other OS and didn’t specify whether you’re installing openSUSE 12.1, 12.2 or something else. I don’t know what all the bootloaders you tried is supposed to mean, Legacy Grub? Grub2? Lilo?

When you install multiple distros, you should generally not use one bootloader configured to boot all distros, you should generally expect to chainload your bootloaders so that each OS installer can configure the bootloader however they wish. Since you manually configured Grub, that’s probably a likely candidate for error, did your menu entry specify that the openSUSE root would be on sda?

Am not sure about your problem but it <may> be a consequence of your decision to remove and add drives. Generally, IMO you should not re-configure your internal drives during install and if you had a problem early that should have been a warning.

Bottom line, you’re trying to create a complex multi-boot and doing it in an error-prone manner (doesn’t mean it can’t be done, only that the way you’re doing it is inviting mistakes).


Sorry, I wasn’t very clear. I’m only using a dual boot. I wanted to use openSUSE, but since the installer would fail when it came to the boot loader, I used different distros to see if the problem came from openSUSE or from my configuration. Apparently, it came from my configuration, which doesn’t seem to be handled really well by Linux. I’ve been comparing the installs between openSUSE (12.2), Backtrack (5r3), Debian (6.06) and Ubuntu (12.10). All installations would fail to install the boot loader (in single boot, with completely empty drives) on the SSD as long as the HDD was there. When I took the HDD out, all Debian-based distros would install successfully, including the bootloader. But openSUSE still wouldn’t succeed to install its bootloader. I’ve tried all of them - ELILO, GRUB2, GRUB-EFI. Since it didn’t work, I chose not to install one, make a dual boot (I wanted to do it anyway) with Backtrack, and install GRUB2 to /dev/sda (which is now /dev/sdb). I think that GRUB is configured properly, since Backtrack boots without any problem in the same conditions. I think the problem is coming from the inird image, like described in the above link.

Perhaps show us ‘fdisk -l’ to give us some idea of where you are, and what you have.

Yaaay, it’s fixed! So, here’s exactly what happened. When I added my HDD, the SSD was then the 2nd to be detected, after the HDD, which changed its physical address. I didn’t look at the GRUB configuration file because after I added the HDD, GRUB still seemed to work fine and Backtrack had no boot problem. So I inspected openSUSE’s initrd, and found out that the root disk configuration wasn’t saved in the ramdisk but passed as a variable through an argument. And the program to pass the variable through that argument is… GRUB. So you were right about the GRUB misconfiguration. Since BT still booted, I assumed GRUB only really needed the UUID (I didn’t configure it manually, otherwise I would’ve changed the hd(0,1) right away I guess) of the root partition.

Thanks a lot to everybody who replied to this post, I’ve learned interesting things today. :slight_smile:

Nice you found it. While you are now in a euphoric mood, let me ask you something for the future.
Please post computer facts as terminal text (often much better then a lot of story telling) complete (that is prompt, command, output and next prompt) copied/pasted from the terminal emulator in between CODE tags in a post. You get the CODE tags by cliocking on the # button in the toolbar of the post editor.
Thus not

Here’s a copy of my fstab (looks fine to me):


henk@boven:~> cat /etc/fstab
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part5 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part1 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part6 /home                ext4       defaults              1 2
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part2 /mnt/A               ext4       ro,acl                1 2
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part3 /mnt/A/home          ext4       ro,acl                1 2
proc                 /proc                proc       defaults              0 0
sysfs                /sys                 sysfs      noauto                0 0
debugfs              /sys/kernel/debug    debugfs    noauto                0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0

Most certainly. Sorry about that, I agree it’s much clearer with the “code” tag.

One last note about the grub.conf file… For openSUSE,


while this was used for Backtrack:


So in the future, I’ll know what to change if this happens.