Description of problem: After up2date load of many components and the kernal a reboot resulted in the following error ****** Audit (1102031885.811:0) initialized Red Hat nash version 3.5.22 starting mount: error6 moutining ext3 pivotroot:pivot_root(isystroot, /sysroot/initrd) failed 2 unmount/initird/proc failed 2 Kernel panic - not syncing: No init found ****** When I tried loading the previously fine running version 2.6.8-1.521 it was also corrupted with the following error... Note it does get further into the boot than the new version. It sucessfully mounts the USB files system but Checking root filesystem fsck.ext3 unable to resolve 'lLABEL=/' [FAILED] ************ seems like they both could be related the above problem occurs when I try to load either of my earlier kernels 2.6.6-1.435.2.3 or 2.6.5-1.358 **************** Also tryed looking on the web for other people with similar problems found a lead I followed which suggested looking at fdisk -l which I tried. A long time ago, but the partitions seem to be intact. Interestingly the boot sector is listed as hdc1 a HPFS/NTFS partition but my foggy memory seems to think that was required to boot Windows and grub shifts to the linux partition from there.... Please correct if I'm wrong. FYI the partitions are hdc1 1 - 510 HPFS/NTFS boot hdc2 511-523 Linux hdc3 524-1531 Linux hdc4 1532-1661 W95 Ext'd (LBA) hdc5 1532-1661 Linux swap (interesting I don't recall these sharing same cylinders before is this an issue?) ****************************** Interestingly Windows 2000 still boots. I still had that damn thing though (actually 2k seems better than XP but that's progress) ****************** one article I read recommended using the recovery disk to determine if the following were present 1) initrd This was missing, but I remade it with 755 permissions as recommended 2) check etc/grub.conf Problem here is that booting off the CD I couldn't even see the file, and booting on an older version then moving to maintenance mode I can ls the file, but can't read it or open it. So I couldn't check the file as was requested in the article 3) the third thing I forgot, but since 2 is obviously an issue.. I started writing to you. ******************************* Finally I also checked /boot for /grub/grub.com as was recommended in another article I read... This did not exist, the dir /boot exists but was empty even using an ls -a just . and .. In case you are wondering I am running a Athlon XP 2500 Barton 512Mb memory epox 8rda3i mb Nvidia video card 13GB HD 7200 Maxtor running IDE (have read similar problems associated with SCSI but not this time) Floppy, CD R/W liteon, and a 2nd plug in ethernet (1 on MB) I appreciate your patience with this admitted newbee. Was running great just before the up2date upgrade I guess I should be more cautious about that. Version-Release number of selected component (if applicable): See listing of FC 2 releases above, all happened on load of 2.6.9-1.6 How reproducible: 100% Steps to Reproduce: 1.See above just reboot 2. 3. Actual results: Sorry I didn't follow your format Expected results: Sorry I didn't follow your format Additional info: Sorry I didn't follow your format Please help.... I really want to convert. Let me know anything you may want me to try out etc. Thanks in advance! Jim
can you paste the output of cat /etc/fstab and also cat /etc/grub.conf
Several additions I made seem to be missing. Does this one work?
Hi Dave, Your tip did the trick putting me on the right track. The fstab and the /etc/grub.conf files were corrupted. I had a devil of a time changing them but the following worked. The problem was complicated by the following. When the log on would fail, I would logon as root this would allow me read only access. In this mode I was able to read the fstab file and noticed the following lLabel=/ / ext3 defaults 1 1 Label=/boot / ext3 defaults 1 2 and a bunch more stuff I noticed the l before the Label matched the error message. In this mode the etc/grub.conf did not exist. The name was there but the file could not be opened using more or emacs with statements coming back that the file did not exist. I used the rescue cd but during the load there was a problem and an entire image of the existing hd was not done. fortunately the boot directory was and I was able to see the contents of the /boot/grub/grub.conf In this case the title Fedora Core (2.6.9-1.6_FC2) root (hd0,1) kernel /vmlinuz-2.6.9-1.6_FC2 ro root=lLABEL=/ rhgb quiet initrd /initrd-2.6.9-1.6_FC2.img again showing the added l in front of Label. In this case I could modify the file and eliminated the l. Doing this allowed me to load the 2.6.9-1.6 version as far as the others. See my earlier comments about where it was dying. This suggested that if I could indeed modify fstab file I might be okay. Unfortunately due to the error during the loading I couldn't read/see the fstab file, must have died before loading it. I'm not sure what I did is the best way but in any event. I created a directory, then mounted the /dev/hd2 to it which turned out to contain my linux main partition (I have 2 one for the boot and a main one). I got rid of the extra l and now things seem to be fine. So I guess the question is how did the extra l get into these two files during the up2date. That apparently is one problem, I don't know if there are others, but the system seems to be working now. On another note, I noticed a file called fstab.pre-capture. Now I'm not sure what that capture was (could this be a virus or something?) Again, thanks for the tip. Your comments would be most appreciated. Jim
I have no explanation how the extra l got there if you didn't edit it by hand and typo it. The only thing that comes to mind is a possible hardware fault. Have you tried running memtest for a few hours and see if that turns up anything odd ? As this is the only instance of this problem I've seen, I think this is an isolated case which also adds credibility to the idea that this is a localised problem. I don't think there's anything else that I can do here, so I'm going to close this. If for some reason you believe this to still be a kernel bug (ie, you reproduce it when you're sure the hardware is fine), feel free to reopen it.
Okay, I will take your advise on a memcheck. FYI I did not manually edit these files and typo them. They were operational and fine until the update. Have you considered if the update modifies this only once and copies the results into the 2 files? That is the only thing that makes sense to me, that somehow during that process one got corrupted and copied into the other location. Does this make sense based on your knowledge of how the up2date software works? Thanks again. Jim