On 11/11/2004 10:20 AM John Swartzentruber wrote:
I just ran an upgrade from FC2 to FC3. The upgrade went smoothly, without any issues or problems, but when it reboots, I see this:After a day of digging and experimenting and learning, I've come up with some pointers for myself, which I will post here so that others having the same problem might get some ideas.
mounting root filesystem mount: error 6 mounting ext3 mount: error 2 mounting none Switching to new root switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempting to kill init!
The only drive in this computer is SATA. Under FC2, this was recognized as /dev/hda. Now, under FC3, it is /dev/sda. I edited my /etc/fstab and edit my grub line to reflect this, but the problem persists.
I can boot from the emergency disc, and mount my drive to edit and look at it. I verified that both partitions (/dev/sda1 and /dev/sda2 exist and are properly labeled -- /boot and / respectively).
I googled and looked at many different posts and messages, none of which seemed to directly apply to this situation. The best that I can figure is that the support for SATA isn't loaded when the system needs to boot. That doesn't quite make sense, however, because this computer was working fine with FC2, and it seems that a clean upgrade would make sure that this would work.
Can anyone give me some help, or at least some good pointers?
The main problem appears to be that support for the SATA hardware wasn't being loaded in the initrd. When I created a new image using mkinitrd with "--with=sata_via", I got past the initial kernel panic and the system booted.
Or mostly. Unfortunately, it eventually had lots of IRQ 10 errors and then died. At some point (correct or not), I copied my old /etc/modprobe.conf file back to the current one, which didn't seem to have much of anything in it. I also added "acpi=off" to my kernel line in /etc/grub.conf. The latter seems to have allowed eth0 to work again. While running in single user mode without the network (this was actually before I tried acpi=off), I made a CD-RW disc with the new udev rpm and updated that.
It looks like the system is mostly working now. I'm running yum update, which is taking awhile to get all of the updates. Then I'll start figuring out whether everything is really working and try to see what the implications of "acpi=off" really are. It clearly solves a big problem, but does it cause other problems?
