Bug 141716 - up2date load of new kernal lead to issue and wiped out previous versions loaded
up2date load of new kernal lead to issue and wiped out previous versions loaded
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Depends On:
  Show dependency treegraph
Reported: 2004-12-03 00:04 EST by Jkjgt
Modified: 2015-01-04 17:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-06 11:20:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jkjgt 2004-12-03 00:04:40 EST
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
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!
Comment 1 Dave Jones 2004-12-03 00:41:36 EST
can you paste the output of cat /etc/fstab
and also cat /etc/grub.conf
Comment 2 Jkjgt 2004-12-05 18:48:26 EST
Several additions I made seem to be missing.  Does this one work?
Comment 3 Jkjgt 2004-12-05 19:18:08 EST
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.
Comment 4 Dave Jones 2004-12-06 11:20:47 EST
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

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.
Comment 5 Jkjgt 2004-12-06 20:20:02 EST
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.

Note You need to log in before you can comment on or make changes to this bug.