login
Search
I have a weird bootup problem with 2.6.0-test[56] kernels.
Kernel boots fine until root filesystem mount stage, where it spits:
VFS: Cannot open root device "306" or hda6 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on hda6
Needless to say, it works fine with old 2.4.22. Whats more strange, it worked fine with same config and 2.6.0-test1 kernel. I patched straight to 2.6.0-test5 where it broke, and tried test6 lately with the same result.
Here're some snippets from my .config:
# fgrep IDE .config|grep '^[^#]'
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
# fgrep EXT .config|grep '^[^#]'
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# grep 'PARTITION\|DISKLABEL' .config|grep '^[^#]'
CONFIG_PARTITION_ADVANCED=y
CONFIG_OSF_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_SGI_PARTITION=y
CONFIG_SUN_PARTITION=y
part of /etc/lilo.conf:
image=/boot/vmlinuz-2.6.0-test6
label=2.6
read-only
root=/dev/hda6
I did a lot of googling, found only one case similar to mine, which went unresolved:
http://www.ussg.iu.edu/hypermail/linux/kernel/0308.0/0091.html
Tried to contact the author, but the guy's hotmail account is locked.
I'm out of my wits as to whats going on. Any advice is appreciated.
U Have to add CONFIG_MSDOS_PARTITION=y
I had this problem too. After much fiddling around i realised, that u have to add support for MS Dos Partitions if you select the Advanced Partition Stuff (for example to access Mac partitions).
with Support for Mac and for MS DOS in Advanced Partition selection kernel 2.6.8 is working fine
I had the exact same problem.
I had the exact same problem. Works fine now thanks to you all.
mkinitrd requires the modules-init-tools package (Debian) which was not included by default.
LeMac
Same problem...
and removing CONFIG_PARTITION_ADVANCED worked for me. Now to just get my network card working...
Dido on the problem
I had the same problem with GRUB.
my GRUB:
________________________________________
title Debian GNU/Linux, kernel 2.6.15
root (hd0,0)
kernel /vmlinuz-2.6.15 root=/dev/hde3 ro
savedefault
boot
initrd /initrd.img-2.6.15
_______________________________
The error (and I don't know how it happened was that the initrd line got moved to after the boot line.
So the solution I had was as below:
________________________________________
title Debian GNU/Linux, kernel 2.6.15
root (hd0,0)
kernel /vmlinuz-2.6.15 root=/dev/hde3 ro
initrd /initrd.img-2.6.15
savedefault
boot
sysfs
try to compile with support for sysfs. maybe that will fix your problem.
Advanced Partitioning
I had this problem too, and disabling advanced partitioning removed the problem. I don't have a SATA-disk, but an old 20GB IDE-disk and I have a really old computer to which I installed gentoo linux so the problem is not with only SATA-drives.
I didn't need the advanced partitioning, I was just testing different kernel settings and wanted to try to add support for stuff I didn't know if I needed later, so disabling the advanced partitioning didn't cost me anything, just a litte time to compile the kernel again.
Thank you all for good pointers, without you I would have been lost on where to start looking for the solution.
VFS:Unable to mount root fs
I'm hoping I'm not the first one to feel stupid and that I'm the first one to be honest. I built my Slackware system on another machine, swapped the disk over to my 'spare' and got exactly the same error. The mistake? The drive was hdb on the first, hda on the second - the error is due to lilo's root=/dev/hdb
I booted from the Slack CD, mounted the problem disk, chrooted, edited lilo.conf, lilo, reboot... then a second error due to the hdb in /etc/fstab from the Slack setup on the first machine.
I hope this saves someone some time! It was a 'LBA' response that got me looking through lilo.conf - it has been a very long night...
Sean
x
I encountered the "VFS: Canno
I encountered the "VFS: Cannot open root device" problem when upgrading my kernel from 2.4 to 2.6 on a debian system. I have two sata drives which are supported as scsi drives (CONFIG_SCSI_SATA) in the 2.6 kernel, and not as ata drives (CONFIG_BLK_DEV_IDE_SATA) as they were in the 2.4 kernel.
The move to supporting sata drives as scsi devices required that the kernel be loaded with the assistance of initrd (CONFIG_BLK_DEV_INITRD). Now, scsi drives use a different naming convention to ata drives. So, previously my two sata drives were referred to as hde and hdf (the ata naming convention) using the 2.4 kernel, using the kernel 2.6 they were referred to as sda and sdb (the scsi drive naming convention).
This meant that my boot manager's (grub) config file should have referred to the root partition as sda4 (it's located on the fourth partition of the first sata disk) and not hde4. Although I used debian's package kernel-package, make-kpkg, to build and package the kernel and debian's package management tool, dpkg, to install the newly built and packaged kernel, the changes automagically made to grub didn't reflect the change in drive naming convention. So I ended up with the following section in my grub config file, /boot/grub/menu.lst :
title Debian GNU/Linux, kernel 2.6.8-20050130
root (hd0,3)
kernel /boot/vmlinuz-2.6.8-20050130 root=/dev/hde4 ro
initrd /boot/initrd.img-2.6.8-20050130
savedefault
boot
But the following is what should have been there:
title Debian GNU/Linux, kernel 2.6.8-20050130
root (hd0,3)
kernel /boot/vmlinuz-2.6.8-20050130 root=/dev/sda4 ro
initrd /boot/initrd.img-2.6.8-20050130
savedefault
boot
And there was the source of my woes.
As an aside, I should also mention that if this name change is the source of your problems, you will also want to update your /etc/fstab, to reflect the changes to the names of your drives there too.
Cheers,
Paul.
Thanks Paul!I am using sl
Thanks Paul!
I am using slackware linux on a Dell Dimension 9100 with a SATA drive and got this problem moving from 2.4 to 2.6 kernel. Changing lilo.conf from
boot=/dev/hda2
to
boot=/dev/sda2
and then making the same change to /etc/fstab fixed the problem.
I have one problem similar (a
I have one problem similar (and sata too), my question is the following: because i have two kernels 2.4 and 2.6, kernel 2.4 works with hdx and kernel 2.6 with sdx, how i put into fstab file two references: sdx and hdx, because if don't run with the new kernel 2.6 I need to run with 2.4???
sorry for my english
in advance, thanks
Hi, I have a Toshiba laptop
Hi,
I have a Toshiba laptop and I was getting the same problem with VFS kernel panic message.
I noticed that before this message there was a notice about irq conflicts, so
I tried compiling the cdrom as a module (CONFIG_BLK_DEV_IDECD=m), which worked.
another possible solution
I was having an issue like this. My root= var was pointing to sda1 and booting was 50/50. I changed it to hda1 and it worked.
Hi just having same problem
Hi
just having same problem after upgrade from 2.4 to 2.6 on debian (kernel compilation)
try to fix it using your tips
let u know about outcome
LVM could be the answer
For years I've had trouble when upgrading kernels. Most of the time after trying everything, I would give up and wait for a new Redhat/Fedora release. Now I am need of exchanging the current set of bugs in kernel 2.6.15 for a newer hopefully less impactful set in kernel 2.6.22. I am waiting for it to be a stable release which looks like could be any day now. I know I will encounter the boot problems again, but I need to try. (definition of an idiot: one who keeps trying the same thing expecting a different result). While looking for something else I came across the following:
The system is not recognizing my boot LVM partitions and kernel panics.
You need to run "lvmcreate_initrd", which will create an
lvm-initrd file in /boot. Then edit grub.conf to use the new initrd. This will make your lvm tools available at boot and your VGs will come online. To do this with a rescue disk do the following (change /mnt/sysimage to whatever your actual root is mounted as):
mount -t proc proc /mnt/sysimage/proc
chroot /mnt/sysimage /bin/bash
source /etc/profile
lvmcreate_initrd
exit
umount /mnt/sysimage/proc
sync
shutdown -r now
This sounds like a logical solution and when I get the stable release I'll try it. This solution eliminates the need to disable stuff you really wanted just to boot.
It and much more cool info is at:
Rise up Labs
If anyone tries it successfully or otherwise before me, please post.
Paul Hickey
My Fix
I had exactly the same problem.
After going over the forums endlessly, it turned out that my recent live upgrade of debian had somehow erased my initrd file.
Not to say there wasn't a file, it just had 0 bytes.
Luckily there was a backup gzip file (initrd.img-xxxxx.dpkg-bak, where xxxxx is your kernel version)
So I booted into a live cd, mounted the partition and unzipped a copy (important: don't let gzip delete the original).
Then everything worked just fine, even with my root=/dev/sdc1 kernel command line.
I think the problem was that the SCSI drivers needed to interface with my hard drive were loaded as modules, and were thus in the initrd file.