[blfs-support] kernel panic when booting with connected external disk

Michael Shell list1 at michaelshell.org
Wed Mar 20 21:32:34 PDT 2013


On Wed, 20 Mar 2013 12:29:49 +0100
"Dr.-Ing. Edgar Alwers" <edgaralwers at gmx.de> wrote:

> http://dl.dropbox.com/u/8734485/Kernel_Panic_2/dmesg-sda-sdb-18032013
> http://dl.dropbox.com/u/8734485/Kernel_Panic_2/Gparted-sda.png
> http://dl.dropbox.com/u/8734485/Kernel_Panic_2/Gparted-sdb.png
> http://dl.dropbox.com/u/8734485/Kernel_Panic_2/Kernel-1.JPG
> http://dl.dropbox.com/u/8734485/Kernel_Panic_2/Kernel-2.JPG


Under Ubuntu, the internal drive is assigned to sda and the
external drive gets sdb. However, LFS, with the external drive
attached, assigns sda to the *external* USB drive and sdb is
the internal drive, hence the boot failure.

Can you show us what LFS is saying when it assigns sda to the
external USB drive? This is before Kernel-1.JPG.

You can try booting LFS with the USB drive attached via the
root= kernel command line parameter under grub/lilo:

root=/dev/sdb5

The swap space will still be in the wrong place (as entered
in /etc/fstab and I don't see a way to tell the kernel - well
the swapon command - otherwise at the boot prompt), but you
should be able to get the root filesystem going even with
the external drive attached.


On Wed, 20 Mar 2013 13:04:23 +0100
"Pierre M.R." <prousselet at sfr.fr> wrote:

: A workaround is to compile an LFS kernel with usb system as
: *modules* so that the kernel can't know about the external
: HD before mounting root fs and loading the usb modules.


Yeah, that should work. But, there really should be a better solution.
The Linux Kernel developers should provide a way to overcome this
problem which is only going to get worse as more hot-plug interfaces
that can host drives come into being. In fact, from what I read it is
even worse in that on some machines with both ATA and SATA interfaces,
the drives get *random* assignments on each boot because drive discovery
is taking place in parallel between the two interfaces. Uhhhgg!

If the system is recent enough (util-linux version 2.22 or later) it
might be good to go with PARTUUID:

http://archives.gentoo.org/gentoo-user/msg_35eb3187ef8be8a23cdec253b66b5a59.xml

There is a good article on persistent device naming here:

http://wiki.debian.org/Part-UUID

However, a udev based approach will not work for the case at hand
because udev is not available until after the root filesystem is
mounted.

That means that all the /dev/disk/ stuff won't work and it needs
extra rules for udev to create the /dev/disk/by-* stuff anyway.

However, the debian article has one section of interest in this case
"Assigning Persistent Names to Swap Partitions"

because that shows how a UUID can be assigned to a swap partition
and then that UUID referred to in /fstab.

Now, note the beginning of another mess - that UUID's don't provide
an obvious relationship to a physical device. That is, I know
that all partitions of "name" /dev/sda* reside on the same physical
disk. However, if someone gives me two PARTUUIDs, I have no
immediate way from the names themselves of knowing if these two
reside on the same physical disk.

Anyway, I see that as of util-linux version 2.22 (swapon --version)
swapon supports the PARTUUID= tag (in its /etc/fstab entry):

http://karelzak.blogspot.com/2012/09/util-linux-222.html


So, if it were me, I would use gdisk to assign "Partition unique GUID"
(PARTUUID) to all those partitions and then change grub and fstab to
use PARTUUID notation rather than /dev/sdx for / and swap.

Either that, or use Pierre's suggestion to delay the loading of the
usb drivers via modules ... or just don't ever keep the external
drive connected at boot.


Rant again: I think the kernel developers should provide us some
way to be able to specify which drive in the system gets to be
assigned to sda (or other name of the device holding the root
filesystem). I see people have been complaining about this:

http://lists.olug.org/pipermail/olug/2011-July/030909.html

After we get the root filesystem up, we can use udev's facilities.
As it is, I think they are making a mess.


  Mike Shell













 



More information about the blfs-support mailing list