# /dev/sda /dev/sdb mixup with portable media

## kiskoller

I am having issues with Linux "naming" my hard drives. I haven't found enough information about this process, so i thought maybe you guys can help me:

Here is the thing: Now i have an Intel SSD with 40 GB space, that is my main HD where my OS should be. It has 3 partitions, 1 for boot, another for root, and one for home. 

When nothing else is plugged, I get this:

```
ls /dev/sd*

/dev/sda /dev/sda1 /dev/sda2 /dev/sda3
```

This is all sound and well. However, if I plug a pendrive  (with 1 partition) into my PC and turn the rig on, this is what im gonna get:

```
/dev/sda /dev/sda1 /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdb3
```

Obviously my pendrive became sda and my SSD became sdb. However with this "shuffle" I can't boot into the system because Lilo is going to search fo the root drive at /dev/sda2, and I get kernel panic because nothing is found in the pendrive.

This also makes installation very hard, the only workaround i found so far is using CD to install stuff, and unplug my pendrive before turning the rig in.

The motherboard is an Asus 990FX Sabertooth, and I am using AHCI drivers for the SSD.

Any ideas how to solve this?

regards,

kiskoller, proud gentoo user.

----------

## NeddySeagoon

kiskoller,

Use the UUIDs to identify the filesystems.

In /etc/fstab, this just works.  You will need to look up the syntax.

In grub.conf its a bit harder as the kernel does not understand UUIDs.  You will need to use an initrd to mount root using the UUID.

Its all well documented once you know what to look for

----------

## kiskoller

I did what you said I should, I copied the UUID thing and edited my fstab. However the problem is still here. I plug in the pendrive=no boot. I go without it = perfect boot. I feel i screwed something up with my fstab, so here is it

```
# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>

#/dev/sda1              /boot           ext4            noauto,noatime  1 2

#/dev/sda2              /               ext4            noatime         0 1

#/dev/sda3              /home           ext4            noatime         0 0

/dev/cdrom              /mnt/cdrom      auto            noauto,ro       0 0

/dev/fd0                /mnt/floppy     auto            noauto          0 0

tmpfs                   /var/tmp/       tmpfs           size=15G        0 0

UUID="97fe71df-a18f-4b59-a8fa-085a820d065e"     /boot   ext4    noauto,noatime  1 2

UUID="ad0b52a7-e08a-4899-ab68-299eff430938"     /       ext4    noatime         0 1

UUID="77e6c620-ec3f-4ef3-b238-5eeccdd37194"     /home   ext4    noatime         0 0

```

Thank you for your fast response, that's why I love this distro  :Smile: 

PS I am using Lilo not grub. Should i edit lilo.conf the same way?

----------

## NeddySeagoon

kiskoller,

I've not checked your fstab syntax but thats not the issue yet.

The problem is the (real_)root=/dev/sd...  in your grub.conf 

You need to use a UUID there too.

----------

## kiskoller

I did the same with lilo.conf, still exactly the same situation.

I have no grub.conf, because I am using lilo. Can this problem be solved in lilo?

here is my lilo.conf, it is very simple:

```
boot=/dev/disk/by-id/ata-INTEL_SSDSA2M040G2GC_CVGB038502LW040NGN

default=gentoo

image=/boot/bzImage

        label=gentoo

        read-only

        root=/dev/disk/by-uuid/ad0b52a7-e08a-4899-ab68-299eff430938

```

----------

## kiskoller

What I really don't understand is the fact that I still get kernel panic, although there is no config file at all at the whole system with /dev/sda2 in it. Both fstab and lilo.conf are using this universal id thing to select the hard drive, yet with the pendrive plugged in I still get the problem...  :Sad: 

----------

## NeddySeagoon

kiskoller,

You are mising what I said in my very first reply. 

```
root=/dev/disk/by-uuid/ad0b52a7-e08a-4899-ab68-299eff430938 
```

will not work with any bootloader that passes the UUID directly to the kernel as the kernel does not understand UUIDs - only kernel device names. It works in /etc/fstab because the user space program mount knows about UUIDS but thats not available when you need to mount root.

Think about it - root contains all the user space programs and /etc/fstab, so root has to be mounted some other way to use UUIDs to mount root.

To mount root using UUIDs you need an intermediate step. The intermediate step is called an Initial RAM Drive or initrd for short.

Its a fake root partition used to hold userspace tools needed to mount the real root filesystem. You need one of these to mount root by UUID.

Rather than me describe it all to you, I'll point you to the wiki.

Thats a fairly comprehensive guide wo makinga an initrd for almost anything you want.  Ony include the bits you need. 

That includes your init script and the programs to support it.

----------

## VoidMage

Well, there's a similar-but-different way.

You can pas UUID directly in kernel command line...but it's gpt PARTUUID, not the one you'd use in fstab.

----------

## NeddySeagoon

VoidMage,

It looks like that implies the use of GPT disklables?

----------

## kiskoller

I am gonna check that alternative solution as soon as I wake up tomorrow, thanks for your help  :Smile: 

----------

## kiskoller

After reading this wiki the situation became much clearer although I still don't get it why are there examples of disk-by-label stuff in different lilo.conf [url= http://www.vdmeulen.net/cgi-bin/man/man2html?8+lilo-uuid-diskid]manuals[/url], and how come I can boot into my rig when there is no pendrive even though I am using only labels and UUIDs everywhere without this initRAM? 

Your theory predicts that if I use only this hacks and no initRAM my kernel or bootmanager or whatever that searches for the hard drive couldn't possibly find t, even without the pendrive in it, because it has no knowledge of the naming system yet...

No matter, I am gonna tweek with this thing because it certainly looks interesting, and hopefully I am going to solve this problem of mine in a matter of days.

Thank you for your help, and sorry for not understanding you for the first time, still learning Linux.

----------

## NeddySeagoon

kiskoller,

The kernel contains an embedded root= which it tries when other things fail

You can boot with no pen drive and no root= statement if you want to.

Lilo does not read the lilo.conf at boot time. Its only read when your run /sbin/lilo.

Lilo then saves eveything needed to boot in a prepresses format.  This has its disadvantages too.

Grub reads grub.conf every boot, so it has to understand it every boot.

The boot process (simplifed is) you power on the system, when power good becomes true, the processor is released from reset and fetches its first instruction from address 0xffff0, which is at the top of the BIOS ROM in 16 bit real mode.

The BIOS does its thing, runs initialisation code in any plug in cards then loads the content of the boot drive logical block address 0 into rAM and jups to the load address. Thats The BIOS handed over to the boot loader.

The boot loader, which can be a mximum of 446 bytes uses the BIOS to load more things by block address on the disk.

This much is common for any boot loader. Grub and lilo diverge here. I will describe grub.

Grub stage1 was loaded by the BIOS above.  It loads grub stage1.5 from the unused space between sector 0 and sector 63, where the first partition starts.

With the stage 1.5 loaded, stage1 jumps to it.

Stage1.5 can read exactly one filesystem type.  It reads /boot to load stage2 then it jumps to stage2.

Grub stage2 reads grub.conf, draws the splash screen and the grub menu, then loads whateve you ask for, or the defualt if you allow the timeout.

Loads whatever you ask for means the kernel file and optionally, the initrd.

The initrd is left at /dev/ram0, where the kernel can find it and everything on the kernel line after the file name is passed to the kernel too. e.g. root=

When its done, grun jumps to the kernel load address.

At this point its just the kernel and optionally the initrd in RAM. That has to be enough to mount root, so the init script can be executed, or the boot process stops here.

Lilo makes a block list of disk blocks to be loaded at boot time when you run /sbin/lilo. It blindly loads those blocks at boot time.

Nothing has to be interpeted at boot time as its all done by /sbin/lilo.

The kernel does not understand root mounting via UUID.  Lilo can address the problem at lilo install time, grub must have an initrd.

-- edit --

I'm still learing Linux too, after 12 years.

----------

## kiskoller

Wow thank you for your long answer, I really appreciate it.

 *Quote:*   

> Lilo makes a block list of disk blocks to be loaded at boot time when you run /sbin/lilo. It blindly loads those blocks at boot time. 
> 
>  Nothing has to be interpeted at boot time as its all done by /sbin/lilo.

 

I am still trying to understand what you just said.

So the difference is this:

 With running /sbin/lilo Lilo reads the config file in the system, then it "burns" the data into Lilo which upon booting mounts the hard drives said there, while Grub reads grub.conf at boot and then depending on what is written in that config file, it mounts the hard drives. However, for reading that config file you already need to find and mount the hard drive it is in, so you need initRAM?

But then, in this case I should not have this issue, because only Grub would require initRAM and I wouldn't get kernel panic with my box since I never ever used GRUB with Gentoo. And /sbin/lilo obviously finds the hard drives when it reads my lilo.conf, (otherwise it would throw and error and not "burning" it into Lilo). So why does this problem occur with me still? As I said, there is absolutely no config file in my whole system that links the root place to /dev/sda2, everything is saying it is on the drive specified with its UUID, so why does it work when that drive is actually /dev/sda2 and why does boot not work when its actually /dev/sdb2?

Also, why on the first place thinks the Linux kernel, Lilo, or anything for that matter, that a little portable device is actually more important than an internal SSD drive connected to the first Sata port, thus naming the pendrive /dev/sda and the SSD /dev/sdb. This eludes me.

----------

## NeddySeagoon

kiskoller,

Close. Lilo makes a list of Logical Block Addresses on the hard drive(s) which it blinldy load at boot time. Lilo can optionally understand UUIDs.

This list is created from the locations of the files mentioned in lilo.conf. Nothing is interpreted by the boot loader at any time.

Your kernel has root=/dev/sda2 embedded in it.

When other things fail, the kernel uses this embeeded root=, so it tries /dev/sda2 even when you have a USB drive conneted.

Its your BIOS drive enumeration order that confuses grub.  It finds the USB device before the SATA device.

You may be able to change that by changing the boot order. Hower on some BIOSes that has no effect at all.

Grub doesn't care what you write in root= for the kernel. Its just passed on to the kernel.

The kernel does not understand UUID, so its ignored. Eventually, it gets to its embedded  root=/dev/sda2and your system starts or not.

----------

## kiskoller

Okay I am beginning understanding the situation.

What has Grub anything to do with this? As I said I am using lilo. As far as I know, Grub and Lilo are softwares for the same purpose, you can use either lilo or grub, but not both, am I right?

But what about the embedded root thing? If I could simply put /dev/sdb2 into the kernel, and put /dev/sda2 into lilo.conf, that way if lilo fails (because the pendrive) the kernel tries /dev/sdb2? It would solve my issue I guess...

How did I put that =root/dev/sda2 into the kernel in the first place? I did not find anything related to that in the menuconfig, nor with Google...

Again, thank you for your help, it's awesome  :Smile: 

----------

## Gusar

Using /dev/sda2 or /dev/sdb2 won't get you anywhere, because what is "sda2" and "sdb2" changes. You need to use UUID or LABEL. But the kernel doesn't understand those, so you need to use an initramfs. There's no way around it. Whether you use lilo or grub or syslinux, you need an initramfs. Well, unless you use GPT partitions.

@NeddySeagoon: Initial RAM Drive (initrd) and initramfs are two different things. The end result of what they do is the same, but how they're put together differs - initrd is a compressed filesystem image, initramfs is a compressed cpio archive. initrd isn't used anymore nowadays.

----------

## NeddySeagoon

Gusar,

You are quite correct in your discription if initrd vs initramfs.  I tend to use the terms interchangably as the difference in invisible until you want to take the file apart.

Its a long time since I used lilo in anger. Over 10 years ... Ah penny drops again. Its not the root= thats the problem, its the drive changing under the boot up thats the problem.

----------

