Bug 385101 - Kernel 2.6.23.1-49 fails to boot on LVM-based system
Kernel 2.6.23.1-49 fails to boot on LVM-based system
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
8
All Linux
low Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-15 12:44 EST by Andre Costa
Modified: 2008-07-14 16:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-14 16:57:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Photo of the kernel panic message (258.97 KB, image/jpeg)
2007-11-15 12:44 EST, Andre Costa
no flags Details
initrd for kernel 2.6.23.1-49 (3.76 MB, application/octet-stream)
2007-11-15 13:30 EST, Andre Costa
no flags Details

  None (edit)
Description Andre Costa 2007-11-15 12:44:20 EST
Description of problem:
Latest F8 kernel panics on LVM system during initial boot phase.

Version-Release number of selected component (if applicable):
2.6.23.1-49

How reproducible:
Always.

Steps to Reproduce:
1. boot the machine on a system with LVM partitions
2.
3.
  
Actual results:
Kernel panic with "EXT3-fs: Unrecognized mount option "relatime" or missing
value (there's no "relatime" on /etc/fstab). Please see screenshot attached.

Expected results:
System boot.

Additional info:
Kernel 2.6.23.1-42 boots just fine on the same system. /etc/fstab contents:

/dev/Fedora/Root        /                       ext3   
defaults,noatime,nodiratime 1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/Fedora/Swap        swap                    swap    defaults        0 0
/dev/sda1               /win                    ntfs-3g
defaults,user,auto,uid=500,gid=100      0 0
Comment 1 Andre Costa 2007-11-15 12:44:20 EST
Created attachment 260131 [details]
Photo of the kernel panic message
Comment 2 Chuck Ebbert 2007-11-15 13:15:58 EST
Can you attach the initrd for the new kernel?
Comment 3 Andre Costa 2007-11-15 13:30:44 EST
Created attachment 260191 [details]
initrd for kernel 2.6.23.1-49
Comment 4 Andre Costa 2007-11-15 13:31:55 EST
Hi Chuck, thks for the quick reply.

I just attached the file you requested, let me know if you need anything else.
Comment 5 Chuck Ebbert 2007-11-15 16:26:51 EST
From the initrd script:

mkrootdev -t ext3 -o defaults,noatime,nodiratime,relatime,ro /dev/Fedora/Root

Was relatime ever in the fstab?
Comment 6 Andre Costa 2007-11-15 19:48:51 EST
Yes, here's what happened: I decided to try it out along with
noatime,nodiratime. I edited /etc/fstab while I was still running .42 but had
already installed .49 . When I rebooted, kernel panic.

I then rebooted with the rescue cd and edited /mnt/sysimage/etc/fstab to remove
the relatime entry. Still, .49 keeps panicking.

Is it possible that reinstalling kernel .49 will fix this? Doesn't it work with
relatime? What exactly did I do wrong?
Comment 7 Andre Costa 2007-11-16 08:09:11 EST
I reinstalled .49 kernel packages and now all is fine:

~ uname -r
2.6.23.1-49.fc8

Still, I am puzzled:

- can I use 'relatime' with kernel .49 after all?
- would there be any other recovery path? If had removed .42 kernel (which I
usually do after a couple of days testing a new kernel) and decided to try
'relatime', would I be stuck?
- why didn't editing fstab with the rescue cd fix the boot problem?

Regards,

Andre
Comment 8 Chuck Ebbert 2007-11-16 12:49:46 EST
(In reply to comment #7)
> - can I use 'relatime' with kernel .49 after all?

The built-in mount code in the nash shell on the initrd does not know how to
handle the relatime option. And it is the default anyway, unless the kernel is
booted with "default_relatime=0" on the command line. The only way to disable
relatime otherwise is by doing "mount /filesystem -o remount,norelatime".

> - would there be any other recovery path? If had removed .42 kernel (which I
> usually do after a couple of days testing a new kernel) and decided to try
> 'relatime', would I be stuck?

you can always use the rescue CD.

# chroot /mnt/sysimage
# yum install kernel

> - why didn't editing fstab with the rescue cd fix the boot problem?
> 

Because the initrd wasn't updated. Either mkinitrd needs to be run or the kernel
would need to be reinstalled, which would automatically build a new initrd.
Comment 9 Andre Costa 2007-11-16 13:01:39 EST
(In reply to comment #8)
> (In reply to comment #7)
> > - can I use 'relatime' with kernel .49 after all?
> 
> The built-in mount code in the nash shell on the initrd does not know how to
> handle the relatime option. And it is the default anyway, unless the kernel is
> booted with "default_relatime=0" on the command line. The only way to disable
> relatime otherwise is by doing "mount /filesystem -o remount,norelatime".

Mmmh... ok. In other words, don't use relatime at all, right?

> > - would there be any other recovery path? If had removed .42 kernel (which I
> > usually do after a couple of days testing a new kernel) and decided to try
> > 'relatime', would I be stuck?
> 
> you can always use the rescue CD.
> 
> # chroot /mnt/sysimage
> # yum install kernel

Sure, thks.

> > - why didn't editing fstab with the rescue cd fix the boot problem?
> > 
> 
> Because the initrd wasn't updated. Either mkinitrd needs to be run or the kernel
> would need to be reinstalled, which would automatically build a new initrd.

Ok, got it. But IMHO there should be a more elegant way of dealing with bad
mount options (and I believe you agree since you haven't closed this as
"NOTABUG" or "WONTFIX" ;-))

Thks for the explanations =)

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