I had a Slack 13.1 machine with 2.6.36 kernel. Then, I updated the kernel to 3.12.1.

This machine has connected: a bootable disk with three partions (/dev/sda1 --> Linux OS files..., /dev/sda2 --> data, /dev/sda3 --> more data), a "dummy" SSD just to store things (/dev/sdb1) and USB ports.

The fact is that whenever I try to start Linux with a USB containing data (not a LiveUSB) connected to the machine, during the startup process there is something going on that assigns the sda device to the USB so it is not possible to mount the Linux partitions in the "bootable disk" due to a Kernel Panic:

VFS: Mounted root (vfat filesystem) readonly on device 8:1.
devtmpfs: error mounting -2
Kernel panic - not syncing: no init found. Try passing init=..

The bootloader I am using is LILO. I don't know if there is anyway to force the boot process not to change device names or pre-assign any of them to a certain device. This is its configuration:

# Linux bootable partition config begins
image = /boot/vmlinuz


/dev/sda1        /                ext4        rw               1   1

As the USB device partition is considered as sda1, it obviosuly doesn't contain any kind of init process or application so I get the kernel panic.

I had tried with root="LABEL=myLabel" or root="LABEL=current" with no luck...I think because it searches for the label in the root node, not in all partitions :S

Any suggestion of what is going on? Is it possible to fix it? Thanks in advance!

  • Welcome to post the year 2000, where we have multiple kinds of disks that are plug and play, and so device names are not stable ;)
    – psusi
    Jan 25 '15 at 1:09

The problem is that the disk names are created sequentially; the first disk to be detected by the kernel becomes /dev/sda, the second is /dev/sdb etc.

The solution to your problem would be to disable use (i.e. detection) of USB disks (including USB drives) until after your system has completed booting. This could be done by configuring the kernel to not include the USB storage driver in the kernel itself but to build it as a module. That way, during booting only the "normal" disk is found, and only after the root filesystem has been mounted does it become possible to load the usb_storage.ko module.

This is assuming you have built the kernel yourself, and you're not using an initrd (initial ramdisk).

  • 1
    That won't really fix it either unless you only have one internal disk, as even their detection order can change from one boot to the next.
    – psusi
    Jan 25 '15 at 1:10
  • This is my real solution :) The key was to build the kernel without the USB modules embedded.
    – aloplop85
    Feb 3 '15 at 22:46

Forget about identifying devices by their dev name. Use UUID and you won't have any problem.

You can identify devices' UUID with blkid command.

By the way, I don't know if LILO supports UUID. In case it doesn't switch to GRUB.

  • 2
    The boot loader doesn't need to use a UUID since the bios always makes it look like whatever disk you booted from is disk 80h. You just need the kernel to find the right disk using the UUID.
    – psusi
    Jan 25 '15 at 1:09
  • It does, at least with GRUB. Otherwise you wouldn't need to use search --no-floppy --fs-uuid --set=root 7820c28d-626a-4019-9e63-38fc10635f9a in your grub.cfg
    – YoMismo
    Jan 26 '15 at 7:40
  • You dont't need it. I still can't figure out why they bother putting that in there since grub wouldn't be able to find /boot/grub/grub.cfg in order to even execute that search command if it didn't already know where /boot was.
    – psusi
    Jan 26 '15 at 21:55
  • You do, try removing that line and you won't boot.
    – YoMismo
    Jan 27 '15 at 7:39
  • I do so all the time and it works just fine, of course, because the line right before the search sets the root to point to the correct place. Thus following the set with a search to re-set the root to the same place is redundant.
    – psusi
    Jan 27 '15 at 13:31

This device-numbering on Linux is one of the worst things about that OS. Every other reasonable*nix uses something like controller/target/lun for addressing disks.

I once solved that problem on my PC by changing the boot-device-order in the BIOS (put USB last).

I do not know if that will work in all situations, since Linux often does not care about BIOS-settings.

  • Controller/target/lun wouldn't help either since that is still a totally arbitrary sequential number assigned to each as it is detected, and yea, the bios settings have no affect at all on the OS once it is booted.
    – psusi
    Jan 25 '15 at 1:11
  • 1
    /dev/disk/by-path and /dev/disk/by-id are both very good at identifying which drive is connected where. Assuming the main drive is either sata or scsi, it's not hard to determine the usb drive. All of these are symlinks to the canonical names.
    – umeboshi
    Jan 26 '15 at 1:59
  • @umeboshi You should base an own answer upon your comment. Take the hint from psusi about UUID and you will have the perfect answer to the problem.
    – Nils
    Feb 2 '15 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.