# IDE/SATA disks switch places after kernel boots

## ISHAIM

Hello,

I have a hardware setup in which I'm trying to set up grub dual boot between an IDE hard drive containing Gentoo and a SATA hard drive containing Windows. I have the option in my BIOS to set the boot priority of connected hard drives. I have set this option to the IDE/Gentoo hard drive as the first priority, which is how I'm able to get to grub in the first place.

Before the kernel continues the boot process, grub can detect that the IDE hard drive is indeed (hd0,0). However, once control is handed off to the kernel, there is a kernel panic, and I can see from the output (wish I had a more elegant/proper name for this) that /dev/sda and /dev/sdb have switched places, judging from their partitions which is also displayed in the output.

From what I'm Googling, I may need to utilize the initramfs guide at http://www.gentoo.org/doc/en/initramfs-guide.xml, but I am uncertain whether this would be the proper solution or not.

I would just like to be sure of this in case I am wrong, and/or any additional advice. Thank you for your time.

----------

## cal22cal

I would suggest using the initramfs and load the ide driver as module.

https://forums.gentoo.org/viewtopic-t-474514.html

----------

## VoidMage

If the drives are gpt partitioned, booting by PARTUUID would be a solution.

----------

## _______0

use

```
blkid
```

to find out the UUID of the harddrives and add it like this in fstab:

```
UUID=long number(without quotes) / ext4 options  0 1
```

----------

## ISHAIM

 *VoidMage wrote:*   

> If the drives are gpt partitioned, booting by PARTUUID would be a solution.

 

VoidMade, is this the same solution as _______0 is suggesting also?

 *_______0 wrote:*   

> use
> 
> ```
> blkid
> ```
> ...

 

-EDIT- You guys appear to be suggesting the same thing according to http://wiki.debian.org/Part-UUID -EDIT-

I like that the UUID solution won't take long, but the lucrative thing about using initramfs is that it looks like it may afford the maintenance option of being able to mount / without a LiveCD I've been so desperately without for the past 5 years   :Embarassed: . Apologies if that goes too far off topic but I feel it's at least related, will keep thread focused.

The other concern I have about using initramfs is, according to the guide, if you use genkernel to make it, they suggest not compiling drivers as modules:

```
To use genkernel for generating an initramfs, it is recommended that you include all necessary drivers and code that is needed to mount your / and /usr file systems in the kernel (and not as modules). Then, call genkernel
```

----------

## VoidMage

uuid reported by blkid and PARTUUID on gpt partitioned disks are different things.

----------

## ISHAIM

Okay, then am I correct in assuming they are -nearly- the same? Perhaps I am not being specific enough? In a PARTUUID implementation on gpt partitioned disks, wouldn't you still use the UUID reported by blkid? I am trying to make sure I understand this correctly as that is the impression I get from reading http://wiki.debian.org/Part-UUID.

----------

## VoidMage

Those numbers are independent.

IIRC, you can check PARTUUID either by gptfdisk or 'udevadm info' on the partition.

----------

## ISHAIM

VoidMage, I still fail to understand what you mean or are getting at. udevadm info --query=all --name=/dev/sda3 returns several lines, one being

```
S: disk/by-uuid/c88942e3-3228-479f-a895-c7a185710fe7
```

This happens to be the same UUID returned by blkid /dev/sda3

```
/dev/sda3: UUID="c88942e3-3228-479f-a895-c7a185710fe7" TYPE="ext3"
```

I've checked the manpage for udevadm and find no reference to "PARTUUID" whatsoever, however http://wiki.debian.org/Part-UUID#In_fstab does infer the addition of UUID's to fstab.

I think I'd prefer the initramfs solution as it can also provide a minimalistic rescue shell (if something goes wrong), so I'll probably be going that route, but due to time constraints and the complexity of setting up initramfs in this way according to http://en.gentoo-wiki.com/wiki/Initramfs,  I may have to temporarily settle for adding UUID's to fstab as _______0 suggested.

----------

## VoidMage

In such case, your disk is most likely not gpt-partitioned. Otherwise it would have 'by-partuuid' symlink and ID_PART_ENTRY_UUID .

----------

## NeddySeagoon

ISHAIM,

The key difference is that with GPT partitioned disks, you do not need an initrd to boot using PARTUUID.

The PARTUUID is a property of the partition, the UUID mostly discussed here is the UUID of the filesystem.

DOS Partitions do not have a PARTUUID property.

On a GPT disk, the PARTUUID is created at the time the partition is created. Unlike the filesystem UUID, it is not changed if you reformat the partition.

----------

## gkmac

 *VoidMage wrote:*   

> In such case, your disk is most likely not gpt-partitioned. Otherwise it would have 'by-partuuid' symlink and ID_PART_ENTRY_UUID .

 

Question: I have a GPT partitioned disk and "udevadm info" does show ID_PART_ENTRY_UUID, but there is no "by-partuuid" to be seen in /dev/disk on my install. Why is this?

----------

## ISHAIM

I'm going to assume my IDE Linux drive is MBR since fdisk doesn't support GPT. That being said, I'm also assuming that means in order to dual boot with 2 physically separate Windows/Linux disks, I will need to use initramfs to stop sda and sdb from switching places once the kernel picks up the boot process from GRUB.

The problem I see is that, according to cal22cal, I should compile the IDE driver as a module, which genkernel doesn't support according to http://www.gentoo.org/doc/en/initramfs-guide.xml, so I'll probably follow the guide at http://en.gentoo-wiki.com/wiki/Initramfs.

I wish there were a way to be sure that initramfs will indeed stop sda and sdb from switching, before doing all the work, although I'm assuming that is how it will work.

----------

## NeddySeagoon

ISHAIM,

With an initramfs (initrd) the kernel partition names need not be used. The initrd contains the userspace tool mount and mount understands filesystem UUIDs.

You use blkid to discover your UUIDs, then in grub you can write root=UUID=<UUID_of_root_filesystem>

You also use UUIDs in /etc/fstab.

----------

## krinn

Because noone told the simplicity answer, here's the "easy" solve.

Put your pata drivers build-in kernel (something that should be already done), and set your sata driver as module, this way when kernel load the sata driver, drives letters are already assign to the drives attach to the pata controller.

Except if you use a driver that handle both controllers, this will works.

----------

## NeddySeagoon

krinn,

Tell why too ...

----------

## krinn

well, easy, first controller load, first disks attach to it get a number.

So loading a controller driver as module will be loaded after any controller buildin kernel.

It's now easy to see the logic

- builin PATA : assigning drive letters : sda to sdX for all drives attach to it

- then loading sata module drivers : assigning what drives letters it could but cannot retake ones already taken : sdX to end so

And this is why it cannot work if you don't have two controllers or a driver that handle both controller.

----------

## NeddySeagoon

krinn,

10/10 ... as expected :)

----------

## krinn

It's warming to get a 10/10, but from you, you can't imagine how proud & happy i'm now.

Thank you neddyseagoon

----------

## s4e8

since 3.8-rc1 kernel, PARTUUID recognize trandictional fdisk partitions too. The format is PARTUUID=XXYYZZTT-PP, XXYYZZTT is MBR signature at byte 1bb,1ba,1b9,1b8, the PP is partition number.

----------

