not booting after swapping boot drive to different SATA controller

English Install/Boot/Login
1

Hi,

After attaching my boot drive to another SATA controller the OpenSUSE 13.1 install on the boot drive doesn’t boot anymore.

Waiting for device /dev/root to appear: ......................... Could not find /dev/root. 
Want me to fall back to ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part3 (Y/n)

I don’t understand why it’s not booting as all partitions except for swap are referred to through their UUID.

To try and resolve this I booted into the Rescue mode from the OpenSUSE install DVD (or install USB here). The contents of /dev/disk/by-id and /dev/disk/by-uuid are as follows

ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L
ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part1
ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part2
ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part3
ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part4

17eef133-3073-436b-8af1-4bc20ddc990b
8452-E359
8d2536f2-d284-4bca-8ac1-b80d7a10f1a0
96d51a1b-91b3-4209-ab23-f9cf0a8f51e8
9aa080b9-3d79-4671-a239-6eaa197659cd
B0CE-6610

There are four ext4 partitions on the drive, swap (-part1), boot (-part2), root (-part3) and home (-part4). The short UUIDs are the USB flash drives connected. Then I mounted ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part2 as /mnt/boot and ata-Hitachi_HUA722010CLA330_JPW9K0J818PA7L-part3 as /mnt/root to have a look at fstab and grub2 config.

/mnt/root/etc/fstab contains the entries

/dev/disk/by-id/ata-Hitachi_HUA722010CLA330_JPW9K0J81A552L-part1 swap                 swap       defaults              0 0
UUID=17eef133-3073-436b-8af1-4bc20ddc990b /                    ext4       acl,user_xattr        1 1
UUID=96d51a1b-91b3-4209-ab23-f9cf0a8f51e8 /boot                ext4       acl,user_xattr        1 2
UUID=8d2536f2-d284-4bca-8ac1-b80d7a10f1a0 /home                ext4       acl,user_xattr        1 2

and the boot entry from /mnt/boot/grub2/grub.cfg is

menuentry 'openSUSE 13.1' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-17eef133-3073-436b-8af1-4bc20ddc990b' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_gpt
    insmod ext2
    set root='hd0,gpt2'
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  96d51a1b-91b3-4209-ab23-f9cf0a8f51e8
    else
      search --no-floppy --fs-uuid --set=root 96d51a1b-91b3-4209-ab23-f9cf0a8f51e8
    fi
    echo    'Loading Linux 3.11.10-7-desktop ...'
    linux    /vmlinuz-3.11.10-7-desktop root=UUID=17eef133-3073-436b-8af1-4bc20ddc990b   resume=/dev/disk/by-id/ata-Hitachi_HUA722010CLA330_JPW9K0J81A552L-part1 splash=silent quiet showopts intel_iommu=on
    echo    'Loading initial ramdisk ...'
    initrd    /initrd-3.11.10-7-desktop
}

The swap partition is incorrectly referenced (boot drive was cloned from another system and hadn’t corrected this yet) but / seems to be well referenced to as root=UUID=17eef133-3073-436b-8af1-4bc20ddc990b - manually mounting this UUID confirms that this is the root partition.

Any pointers are appreciated as I’m somewhat stuck here. TIA.

2

This might not help. But I’ll mention it just in case.

The closest that I have come to something like this, was when I attempted to boot a system on an external drive. A computer had failed, do I took out the drive and put in an external enclosure. And I got similar messages to what you are seeing.

As best I can tell, grub was seeing the disk just fine (using BIOS/UEFI) calls. But the kernel was not able to see the disk. There were probably missing drivers for the “initrd”

My solution was to go into rescue mode – mounting all of the disk, chroot to “/mount”, and run “mkinitrd”. That fixed it.

My suggestion: try rebuilding the initrd.

You need to boot from media with the same architecture (32-bit or 64-bit must match the installed system). The install disk is probably your best choice.

Mount the root partition on “/mnt”.

Mount the boot, home, other partitions on “/mnt/boot”, “/mnt/home”, “/mnt/boot/efi” (since you seem to have an EFI system).

Then:


# mount --bind /dev /mnt/dev
# mount --bind /proc /mnt/proc
# mount --bind /sys /mnt/sys
# chroot /mnt
# mkinitrd
# exit

then reboot and see if that has fixed the problem.

3

That solved the issue. I’ll need to dig into that a bit further as I don’t understand what exactly I’ve done there when following your instructions. Anyway don’t know how to mark the thread as solved but solved it is! Thanks!

Very useful as I’ve run into this before when cloning OpenSUSE based VMs or restoring a boot disk from an image.

4

Ok I’ll ty to explain

You booted to a outside disk ie the DVD. So that the root partition is the one that the DVD booted OS uses. But you need to be in the one on the hard drive to do the repair. Luckily Linux has a command to allow you to shift the current root partition ie chroot.

So first we mount the root partition from the hard drive to some mount point in this case /mnt but it could be any valid mount point.

But there are several directories that are virtual and need to be in the running root partitions ie /dev /proc, /sys So we first must bind these to the mount point we used to mount the root that is on the hard drive so that when we chroot they will be available.

Then we change root (chroot) to the partition that we mounted at /mnt and then can run mkinitrd to recreate the initrd stuff so it is all pointing to the right location. You could also run yast if you need to install a driver or do any other repair needed Since we are now running on the root partition on the hard drive not the one from the DVD.

chroot is very useful :wink:

5

I’m glad to hear that the problem is solved.

Let me give some more detail there.

The original error message (“Could not find /dev/root”) comes from the kernel. So grub has succeeded in loading the kernel.

Once the kernel is running and is using the “initrd” (which was read with BIOS calls), it starts doing all of its disk access with internal kernel code and device drivers that it loads from the “initrd”. So it looked as if there might be something missing in the “initrd”, and the rebuild solves that.

As to what actually went wrong? That, I do not know. Presumably, when you plugged the disk into a different SATA connector, it needed different device drivers. Maybe this was a different SATA speed, and perhaps SATA 3 requires different drivers from those that work for SATA 1 and SATA 2. But I am only guessing.

6

Read up a bit on initrd and chroot, this is great learning experience. I very much appreciate your help. Thanks nrickert and gogalthorp!

7

Too late to edit: I forgot to mention that the boot drive was initially attached to onboard SATA (Intel C204 chipset) and I moved to PCIe SATA controller with SiL chipset. So it would seem to be a driver issue indeed. Thanks again!

8

Well it looks like I have a similiar issue again… :frowning: but this time with a RAID controller for which there is no module shipping with the default kernel. I’ve an updated module on driver update disk that allows me to run the installer and install to the RAID array attached to the controller.

At next boot however the system is unable to find the root partition, which I gather to be another issue with the initrd missing the module for the RAID controller. I can boot into Rescue, load the module and mount the / partition. When running mkinitrd hit errors out with

Root device: /dev/disk/by-id/scsi-etc (/dev/sdc3) (mounted on / as ext4)
modeprob: Module rr26xx not found. 
WARNING: no dependencies for kernel module 'rr26xx' found

How would I update the initrd correctly with the missing module? Thanks!

edit: I already tried to copy rr26xx.ko into /lib/modules/3.11.6-4-desktop/kernel/drivers/scsi but no go.

9

Hi, I’m clueless here and hope someone can point me onwards again. To summarize,

  1. To move on I did a fresh install of OpenSUSE 13.1 on a RAID array managed by a hardware RAID controller. The driver is located by the installer on the driver update disk (thanks to another helpful person here), which has the kernel module for the RAID controller for 4 different kernels (including 3.11.6-4-desktop and -default).

  2. The installer loads the module and is able to partition, format and install to the RAID1 volume. However after the installation is completed the system fails to boot, it does load GRUB2 and then fails to find /dev/root.

  3. Booted into the Rescue mode (with driver for kernel 3.11.6-4-default from the driver update disk) and chroot to the root partition. mkinitrd gave me

modprobe: Module rr26xx not found.

but was able to resolve this by inserting the module for kernel 3.11.6-4-desktop in

/lib/modules/3.11.6-4-desktop/kernel/drivers/scsi

and running

depmod -a 3.11.6-4-desktop

.
4) Still doesn’t boot (and this is where I’m stuck now). Looking at the GRUB2 entry I can confirm that root= is pointing to a UUID that matches the root partition on the RAID (confirmed the symlink in Rescue mode).

I have no idea what could be the problem or how to move on from here. Any help is again appreciated. I’ve learned a lot with trial and error but would now like to move on - less error, more progress :). Thanks (again).

edit: should I open a new thread for this as it may be a different issue?

10

Is it true hardware RAID or a FAKE (BIOS assisted) RAID controller? A true hardware RAID should not require a driver since the array will look like a single drive to the OS and will thus be transparent.

FAKE RAID can be a problem if it relies on propritary drivers.

11

Good question. The card is a HighPoint RocketRAID 2642 4 port SATA/SAS, manufacturer site here: http://www.highpoint-tech.com/USA_new/cs-series_rr2600.htm and is labeled as “Hardware assisted RAID”. It has its own BIOS that allows to set a RAID volume as bootable or not (I set mine as bootable of course).

Looking at the chipset however it’s based around a Marvell 88SE6445, which Marvell tells me is a PCIe x4 to 4 SAS/SATA 3Gb/s Ports I/O Controller, no mention of specific RAID features.

So it looks like it may not be an actual hardware RAID controller then? Would that prohibit booting off the RAID array (which wouldn’t make any sense to me then to have the boot volume selection in the RAID BIOS configuration utility)?

Are there any other diagnostic steps I could take to help pinpoint the issue? There’s a --preload option for mkinitrd which I’m going to try next but after that I’m fully out of ideas. Thanks.

edit: thinking on this, it boots to GRUB2 which is on a partition on the same RAID volume. Which tells me the array can be used without a driver in some way. Then there should be a way to boot the OS from there, even with driver-assisted RAID, correct?

12

That is FAKE. ie it can use BIOS to do simple reads like at boot. But that is not full RAID usage and it requires drivers to actually function. True hardware RAID does not require drivers since the hardware is in full control of the array and to the OS it looks like a single drive. Note true hardware controls tend to be a bit expensive but they will works with any OS. I have never seen the point of a over priced FAKE RAID cards since most motherboards come with FAKE RAID and the chips can’t cost more then pennies. So why spend money on FAKE RAID cards that don’t do anything any better then the chips on the MBs?? You must be very careful on buyin RAID cards since the makers tend to obfuscate the nature of the cards ie saying hardware RAID when it is really hardware assisted RAID or FAKE.

13

I understand your point.

In this case I basically needed a second SATA controller to be able to passthrough the onboard SATA controller to a guest. I also would like a RAID1 array for the boot drive. Performance doesn’t matter so much.

In this case we’re talking about an inexpensive controller - 29 GBP on Amazon UK. Considering it’s a PCIe x4 card with 4 SATA ports it’s not so expensive. I bought there a 2 SATA port PCIe x1 controller as well and that was 18 GBP. So pricewise not too bad.

Anyhow the ideal situation for me would be to have the current configuration booting.

-Do you think that cannot be done in this case?

-Would it make a difference in terms of booting if I set it up as two single drives (2x JBOD of 1 disk) and use md for the RAID1?

Thanks.

14

FAKE RAID support is much better then it used to be unfortunately the industry keeps coming up with new proprietary API’s so you got to get the drivers from the maker and those are not always up to date to support the newer kernels.

I think you’d have much better luck setting things up with software RAID. Really there is not much difference performance wise in FAKE and software RAID .

True Hardware cards go for +$200 US