Slackware64 13.1 - won't boot after update - VFS Cannot open root device
Hi, I have been trialling Slack 13.1 on a spare 32b system for a couple of weeks, and today I took the plunge and put it on my main machine. I completely re-partitioned the drive (using the Slack disk) and installed Windows7 on one partition and Slack 13.1 on another. The install worked fine and I tested that it boots from LILO into both Windows and Slack perfectly. I then ran:
slackpkg update slackpkg install-new slackpkg upgrade-all And since then it fails to boot with the following: Code:
VFS: Cannot open root device "802" or unknown block(8,2) It updated the kernel during the update, but I let it run LILO when prompted. If I choose Windows instead of Linux it boots fine, this only happens with Linux. I can successfully boot if I use the Slack install disk and type "huge.s root=/dev/sda2 rdinit= ro" like the boot screen suggests, so I have access to the boot files etc. If I type "fdisk -l /dev/sda" it looks like this: Code:
Device Boot Start End Blocks ID System Code:
# Windows |
One thing to note is that you are no longer running Slackware 13.1 (the most recent stable release) but instead, you let slackpkg upgrade your computer to slackware-current (the development release):
Code:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) What happened during the upgrade, I don't know. One thing I notice is that the new kernel thinks your drive is /dev/sde instead of /dev/sda - that is the reason why the root filesystem can not be found (lilo will be looking for /dev/sda). If that is correct, you will have to boot your computer with the string "linux root=/dev/sde2" at the lilo prompt to force the use of the changed drive name. If that gets you further, the next issue will be updating your /etc/lilo and /etc/fstab to use /dev/sde instead of /dev/sda, or to find out why this change of device name happened, and fix that. Eric |
Thanks for the reply.
I changed lilo.conf lines from: "boot = /dev/sda" to "boot = /dev/sde" and "root = /dev/sda2" to "root = /dev/sde2" But it was still exactly the same. I don't know if this is relevant, but the next time I tried to boot from the disk I am sure I typed "huge.s root=/dev/sda2 rdinit= ro" exactly as before, and this time it failed with almost exactly the same message but listed "sda" where it was "sde" last time, and it referenced kernel version 2.6.33.4. I rebooted from the disk and ran the same command again and it booted successfully. Unless I made a typo the first time but I was pretty careful. Anyway, thanks for the info about the updates, I thought that the current one was for the most recent release and didn't realise it was for development. After reading your reply I have checked the mirrors file and only just noticed the 13.1 up near the top. I'll fresh install tomorrow and run the stable update properly and see what happens. Does the updater keep a log somewhere? I can look for it if anyone on the development team is interested in what went wrong. |
I reinstalled this morning and updated from a mirror in the 13.1 section - all is well. I'm hesitant to mark this thread as solved though, it would be misleading as I have swerved the problem rather than fixed it.
|
Hello there
I was testing my kernel config with 2.6.35.7; after many times trying to figure out why it kept giving me a kernel panic, I found this thread and entered another disk at the lilo prompt
Slack2635 root=/dev/sdb5 It booted normally to a maintenance prompt (but not to a kernel panic telling me that it couldn't find 8,5), so I guessed this was the problem. Next I booted to Slack (as the maintenance login had the silesystem as read-only) and modified my fstab to use /dev/sdb5 instead of /dev/sda5 as my root device. Now it booted with no problems, in fact I'm writing these lines from this very box. I do not know what happened (yet), but I did notice I have a small 8MB disk labeled as sda. Code:
root@rehavam-b:~# fdisk -l /dev/sda The stock Slackware kernel from /current does boot on /dev/sda with no problems whatsoever. Here is my config (only relevant lines) Code:
CONFIG_BLK_DEV=y |
Update: Without the SCSI lowlevel drivers, the small disk dissappears
I don't quite know -yet- which driver causes that thing to be, but I managed to boot my 2.6.35 on sda by not using any SCSI lowlevel drivers, since I use SATA (ahci), not pure SCSI as my primary disk, and I saw that sh&/&(/(&/ty disk registers as the scsi0 device.
This didn't happen with 2.6.33 and I plan to reactivate the SCSI lowlevel driver on my kernel (just in case), after I figure out which driver creates that disk. |
Hint: could it be a ramdisk? Next time you check this out, check out what you can find about this disk. (in dmesg there ought to be some info about what this 8MB sda disk is)
|
Linux has the ram disk as device 1, device 8 is something that is under the SCSI layer which could be nearly anything (else).
With 8MB I'm thinking a flash drive is attached to the machine and is causing the problem. You need to read back the console messages (or use dmesg) to find out what the extra device is. FYI the fdisk out put also looks nothing like a ram disk 1. It should complain on first running about no valid partition table 2. Fdisk should create a disk identifier at start not leave it at 0x00000000 3. I/O size should be 512/512 not 512/32768 4. On x86_64 (possibly x86 as well) ram disk size is 16MB not 8MB |
I also thought it was a ramdisk, it is not.
My ramdisk is 1MB large, so that rules out the possibility of that entity being a ramdisk. It is something created by one of the lowlevel SCSI drivers, I just don't know which one -yet. I will, however, try those drivers until I find it.
|
All times are GMT -5. The time now is 05:31 AM. |