Bug 18660

Summary: Kernel panic: VFS: Unable to mount root fs on 03:05
Product: [Retired] Red Hat Linux Reporter: David Thiede <dthiede>
Component: anacondaAssignee: Michael Fulbright <msf>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: bero
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-10-27 19:45:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Thiede 2000-10-08 21:23:18 UTC
... autorun Done
   Kernel panic: VFS: Unable to mount root fs on 03:05

I get the kernel panic message when it tries to mount / for the first time.
It was successful in loading the kernel from the same hard disk partition.
I am able to successfully boot the system from the resucue floppy. The
system and kernel in use is from the 7.0 release iso images with the
released patches as of 14:12pdt 8 oct. I had hoped that the
mount-2.10m-6.i386.rpm and friend would resolve this problem but it
didn't.. I thought it possible that the large disk was part of the problem
but then why does it load the kernel from hardisk and does / mount with the
floppy version of the kernel? For reference here is my fstab and fdisk
layout..

LABEL=/                 /                 ext2    defaults              1 1
/dev/hda7               /home             ext2    defaults              1 2
/dev/cdrom              /mnt/cdrom        iso9660 noauto,user,ro,unhide 0 0
/dev/cdrom1             /mnt/cdrw         iso9660 noauto,user,unhide    0 0
/dev/fd0                /mnt/floppy       auto    noauto,user           0 0
/dev/jaz                /mnt/jaz          auto    noauto,user           0 0
/dev/zip                /mnt/zip          auto    noauto,user           0 0
none                    /proc             proc    defaults              0 0
none                    /dev/pts          devpts  gid=5,mode=620        0 0
/dev/hda5               swap              swap    defaults              0 0
/dev/hdd1               /vast             ext2    defaults              1 2

Disk /dev/hda: 255 heads, 63 sectors, 2055 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       765   6144831    b  Win95 FAT32
/dev/hda2           766      2055  10361925    5  Extended
/dev/hda5           766       798    265041   82  Linux swap
/dev/hda6   *       799      1192   3164773+  83  Linux
/dev/hda7          1193      2055   6932016   83  Linux

Comment 1 Bernhard Rosenkraenzer 2000-10-09 09:24:50 UTC
Your lilo.conf is broken. Device 03:05 is /dev/hda5, which happens to be your
swap partition.

I'm quite sure you have a "root=/dev/hda5" somewhere in your /etc/lilo.conf,
where it should be "root=/dev/hda6".

Edit lilo.conf to fix this, then run /sbin/lilo as root.

Comment 2 David Thiede 2000-10-09 14:11:41 UTC
/dev/hda5 used to be my / partitiion. I found that an upgrade to 7.0 failed
because I didn't have enough space in /usr. I used fdisk to merge 4 partitions
together to form a single /. Whille doing this I moved swap from /dev/hda6 to
/dev/hda5 and made / /dev/hda6 with my old /dev/hda10 moving to /dev/hda7 when
things renumbered.

Once the repartion was complete I booted from the install CD and performed a
custom install. I chose mbr as the location for lilo. The install went
flawlessly but when I rebooted I found the problem. Late last night I thought to
compare lilo.conf with the version from my previous install (yess I backed up
completely) and noted that there was an initrd entry that my olld one didn't
have.  The root specification correctly pointed to /dev/hda6 Just for fun, I
commented out the initrd and ran lilo. I got an error message:

    Fatal: sector 18126678 too large for linear mode (try 'lba32' instead)

The man page for lilo doesn't show lba32 but I tried it anyway. This time lilo
ran without error and the system booted correctly from hard disk.

My conclusion is that the install script must not have noticed that lilo failed
to install a new mbr since it would appear from your analysis that /dev/hda5 was
still marked as the boot partition even though the /etc/lilo.conf did not show
this.

BTW, when the system booted after rerunning lilo, I saw a brief spash screen (1
sec?) that seemed to show a graphical boot partition selection screen. That
would be great to have since I really miss the way the classic Amiga handled
selection of a boot disk.

Comment 3 Bernhard Rosenkraenzer 2000-10-10 20:52:17 UTC
Reassigning to anaconda (mount can't do anything about the installer failing to
detect lilo errors).

Yes, lilo now has a graphical prompt - if you want to see it for longer, modify
/etc/lilo.conf and rerun lilo.

Comment 4 Michael Fulbright 2000-10-27 19:45:07 UTC
This is related to bug 13614 and bug 16639 and bug 14351.

Marking as a dupe of bug 13614.

*** This bug has been marked as a duplicate of 13614 ***