On Wed, 20 Mar 2013 12:29:49 +0100 "Dr.-Ing. Edgar Alwers" <[email protected]> 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." <[email protected]> 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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
