kernel boot switches from proper internal sata to external SCSI drive with resulting panic
 

Greetings,
I am running Slackware 14.1, the 32-bit SMP kernel and with an Adaptec 2940 SCSI host adapter. I am having a problem when I install an external SCSI non-bootable removable media drive. Normally, the system boots from an internal SATA drive, but when I install an external SCSI drive on the system, the boot stops short with a kernel panic. It looks like the kernel is trying to mount the external SCSI drive as sda rather than the correct internal SATA drive, and finding it isn't a proper Linux disk, it panics. If I turn off the external drive's power, then the boot proceeds normally. However, then the external drive does not get recognized after boot by turning on its power. I am stopped from accessing this external drive either way.

Is there some way to have a specific drive mapped to sda?

Thanks in advance.
Girvin Herr

You can pass PARTUUID to kernel instead of /dev/sdxx.

Edit: You may want to search, here is the first hit I got http://unix.stackexchange.com/questi...fs-with-a-uuid

Emerson,
Thanks for your quick reply.
I have seen this, but I also read that it only works with GRUB. I am using LILO. Also, the link you specified says that I must be using initrd (initramfs), which I may not. I will try it, just to see if it will work, but I am skeptical.
Thanks again.
Girvin

Sounds like you need to switch your lilo.conf and fstab to UUIDs. I have an in-depth post covering that here.

The only thing I didn't mention in that post is using UUIDs in the boot process requires using an initrd (at least at one point it did... not sure if that's been overcome), so, if you aren't already running a generic kernel, now might be the time to switch :) (astrogeek verified below that this is no longer necessary)

You can configure lilo with UUIDs, here is an example from my own:

If using an initrd you can specify the root partition in mkinitrd using UUIDs as well...

You will also want to make corresponding changes in your Slackware /etc/fstab.

You need initrd if you use UUID, not needed for PARTUUID.

I don't think that is true (anymore? I have never encountered such a problem to my knowledge).

If you configure lilo.conf with UUID and use UUID refs in /etc/fstab, you shouldn't have any problems that I am aware of. (Will verify later todaay, but pretty certaain of that).

*** UPDATE - Quick boot of system configured that way, I can verify that there is no problem using UUIDs in lilo.conf without initrd.

astrogeek,

what kernel version it is that can find partition by UUID?

This one is 3.10.17-smp (Slackware 14.1), I am typing from that machine now.

I am also 95% sure I used this same method on Slackware 12.1/2 which would have been 2.6.24 kernel (I can verify that, or not, later as well).

Thanks for all the good leads and suggestions.

This sounds great and I verified that this method is documented in the lilo.conf manpage. However, I am puzzled. In my system, the entries in /dev/disk/by-id and /dev/disk/by_uuid are symlinks to the partitions in /dev/sda*. Therefore, unless there is an unknown-by-me mechanism that makes these links special, if /dev/sda1, for instance, is changed, as it seems to be doing now, wouldn't the IDs that point to /dev/sda1 change too? If so, then I am in the same boat.

That said, my puzzlement will not stop me from trying it.

Thanks again.
Girvin

astrogeek,

Something is off here. I just tried with kernel 4.6.2 and it finds root partition with PARTUUID and does not with UUID ... me scratching head ...

I confirm that there is no need to have an initrd when using UUID. Labeling a hard disk or a partition has nothing to do with using an initrd or not. See "man lilo.conf".

@Emerson: Did you check the UUID you wrote in lilo.conf?

Those /dev/sdx assignments and the corresponding symlinks are created by the kernel at boot, so they will always be correct. In fact, that is the purpose of using the UUIDs: If disk sda is changed to sdb in some other context, the UUID will follow and thus still point to the correct disk. That is essentially the problem solved by UUIDs.

Not being a grub user I can't say anything about that end, but maybe you could post the relevant lines from your lilo.conf, with and without UUID, and output of ls -l /dev/disk/by-uuid when booted we could see what is happening.

astrogeek,

this is not about bootloader, this is about kernel. Bootloader merely passes the root= to the kernel. From this point kernel finds and mounts the root filesystem. See below. It works with root=PARTUUID=e486ed6b-01 and it ends with kernel panic root filesystem not found with root=UUID=a5fad4af-d297-465b-8767-8ad18ee8d993