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
Created attachment 260131 [details] Photo of the kernel panic message
Can you attach the initrd for the new kernel?
Created attachment 260191 [details] initrd for kernel 2.6.23.1-49
Hi Chuck, thks for the quick reply. I just attached the file you requested, let me know if you need anything else.
From the initrd script: mkrootdev -t ext3 -o defaults,noatime,nodiratime,relatime,ro /dev/Fedora/Root Was relatime ever in the fstab?
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?
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
(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.
(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 =)