Bug 385101 - Kernel 2.6.23.1-49 fails to boot on LVM-based system
Summary: Kernel 2.6.23.1-49 fails to boot on LVM-based system
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: 8
Hardware: All Linux
low
urgent
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-15 17:44 UTC by Andre Costa
Modified: 2008-07-14 20:57 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-14 20:57:59 UTC
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 17:44 UTC, Andre Costa
no flags Details
initrd for kernel 2.6.23.1-49 (3.76 MB, application/octet-stream)
2007-11-15 18:30 UTC, Andre Costa
no flags Details

Description Andre Costa 2007-11-15 17:44:20 UTC
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 17:44:20 UTC
Created attachment 260131 [details]
Photo of the kernel panic message

Comment 2 Chuck Ebbert 2007-11-15 18:15:58 UTC
Can you attach the initrd for the new kernel?


Comment 3 Andre Costa 2007-11-15 18:30:44 UTC
Created attachment 260191 [details]
initrd for kernel 2.6.23.1-49

Comment 4 Andre Costa 2007-11-15 18:31:55 UTC
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 21:26:51 UTC
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-16 00:48:51 UTC
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 13:09:11 UTC
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 17:49:46 UTC
(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 18:01:39 UTC
(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.