Description of problem:Putting rootflags=data=journal in grub.conf cause kernel panic. Version-Release number of selected component (if applicable): RHEL 3 update 4 How reproducible: Steps to Reproduce: 1.add rootflags=data=journal to grub.conf that looks like kernel /boot/vmlinuz-2.4.21-27.0.2.ELsmp ro root=LABEL=/ rootflags=data=journal hdc=ide-scsi 2. Boot to this kernel and the / partition cannot be mounted with illegal (or unrecognizable mounting) flag and the kernel panic'ed. 3. Actual results: Expected results: Additional info: Adding rootflags=data=journal to systems running RHEL 4 works fine.
_What_ was the kernel panic, exactly?
I don't have the exact error message but it complained something like un-recognizable mount flag data=journal and could not mount the / partition and the whole system froze. I had to power-cycle the machine (A Dell OptiPlex 280). Jus by removing the rootflags=data=journal flag from /etc/grub (or at grub prompt), the system boots up fine. Thanks. --Bruce
Okay, more information: Looks like there is no way to mount / with full journal; i.e., 1) add rootflags=data=journal ass boot flag to /etc/grub.conf caused the system not being able to boot with kernel panic since it could not mount the / partition giving something like illegal mount option or something like that. 2) add data=journal to /etc/fstab so that it looks like LABEL=/ / ext3 defaults,data=journal 1 1 and reboot -- it doesn't recognize the mount option data=journal and mount the / as read-only. Had to boot to installation CD to change the fstab. Thanks, Bruce
Hello! Anybody home? Is there anyone working on this case? How can I get full journalling for / on RHEL 3 update 4 with 2.4.21-27.0.2 kernel? It should be possible, right? Thanks, Bruce
I'm not sure how straightforward it will be --- my only RHEL3 test systems right now are installed with lilo, not grub, so I haven't been able to reproduce quickly so far. I'm reinstalling a test box now to try to reproduce this. It's really an initscripts issue, not a kernel one; booting via an initrd means that the initial root filesystem is _not_ the one that eventually gets mounted on "/". Why do you want data journaling, though? In most cases, the default data=ordered mode offers *exactly* the same consistency guarantees, and is faster.
Since the root filesystem is mounted by the script on the initrd, and mkinitrd copies the mount options from /etc/fstab - shouldn't putting the "data=journal" mount option in /etc/fstab and rerunning mkinitrd result in exactly what you want? The trick here is rerunning mkinitrd, with the same flags that the kernel RPM %post script ran it. The rootflags= option really should only be needed on systems that do not use an initrd...
(In reply to comment #6) > Since the root filesystem is mounted by the script on the initrd, and mkinitrd > copies the mount options from /etc/fstab - shouldn't putting the "data=journal" > mount option in /etc/fstab and rerunning mkinitrd result in exactly what you want? No, it doesn't work -- read my second posting: 2) add data=journal to /etc/fstab so that it looks like LABEL=/ / ext3 defaults,data=journal 1 1 and reboot -- it doesn't recognize the mount option data=journal and mount the / as read-only. Had to boot to installation CD to change the fstab. Thanks, Bruce
(In reply to comment #5) > I'm not sure how straightforward it will be --- my only RHEL3 test systems right > now are installed with lilo, not grub, so I haven't been able to reproduce > quickly so far. I'm reinstalling a test box now to try to reproduce this. It's > really an initscripts issue, not a kernel one; booting via an initrd means that > the initial root filesystem is _not_ the one that eventually gets mounted on "/". > Hmm... I thought it's as simple as adding 'append ...' to /etc/lilo.conf and reboot. Not? Also we in this case, I don't think we have even reached initscripts since it wouldn't even be able to mount the /; thus the kernel panic. > Why do you want data journaling, though? In most cases, the default > data=ordered mode offers *exactly* the same consistency guarantees, and is faster. Well, you are an expert in this respect. I will take your word. The only reason I wanted to try is that there are saying that full journalling gives good performance in some cases and I was able to experiment with it I myself. :-) Thanks, Bruce
> Hmm... I thought it's as simple as adding 'append ...' to /etc/lilo.conf > and reboot. Not? Try addindg append = "rootflags=data=journal" to your /etc/lilo.conf and run 'lilo -v' to see if this works or not. If it does, then you are done. Otherwise, all you have to do is to install the grub package and then try to set up grub. No reloading the whole system necessary. Let me know if you need the procedure to install grub. Thanks, Bruce
(In reply to comment #6) > Since the root filesystem is mounted by the script on the initrd, and mkinitrd > copies the mount options from /etc/fstab - shouldn't putting the "data=journal" > mount option in /etc/fstab and rerunning mkinitrd result in exactly what you want? > > The trick here is rerunning mkinitrd, with the same flags that the kernel RPM > %post script ran it. After re-reading your message, I will give it a try this weekend. Currently I don't have a machine that I can play with. Still, why adding the mount option to /etc/fstab caused the kernel to mount / read-only? Puzzled. This one should be easy to verify -- all you need is a test RHEL 3.0 machine and add the flag to /etc/fstab as I said and reboot. See if you can reproduce the problem? > The rootflags= option really should only be needed on systems that do not use an > initrd... Hmm... but then why it works for RHEL 4.0 with kernel 2.6.9-5.0.3? Thanks, Bruce
Did you change /etc/fstab before upgrading to kernel 2.6.9-5.0.3? If so, mkinitrd ran after you had changed /etc/fstab, and the new mount options were propagated to the initrd...
(In reply to comment #11) > Did you change /etc/fstab before upgrading to kernel 2.6.9-5.0.3? > > If so, mkinitrd ran after you had changed /etc/fstab, and the new mount options > were propagated to the initrd... No. This was an afterthought; I recently found the information about the boot kernel flag rootflags=... and would like to give it a try. So 1) I added rootflags=... to grub.conf (without changing /etc/fstab) and rebooted my machine. It looked fine since I saw: kernel: EXT3-fs: mounted filesystem with journal data mode. But later I realized that / was remounted at some stage by initscripts. Thus 'mount' still shows that / did not have full journalling. 2) I added data=journal to /etc/fstab (in additional to step 1). Now I see: /dev/sda2 on / type ext3 (rw,data=journal) This is all on RHEL 4 with 2.6.9-5.0.3.ELsmp kernel. The was installed on March 1st; long before I started to play with data-journal thing. Thanks, Bruce
Note that the flags shown by mount(8) and in /etc/mtab are *NOT* always the canonical ones. Look in /proc/mount to find out for sure ... I don't think the ext3 journal options can be changed on remounting the filesystem (though I could be wrong).
ext3 journal flags can _definitely_ not be changed at remount time.
> ext3 journal flags can _definitely_ not be changed at remount time. Then probably 'mount' does not show the correct information -- it says /dev/sda2 on / type ext3 (rw,data=journal) when I have data=journal in /etc/fstab. But shows only /dev/sda2 on / type ext3 (rw) if the flag is not there. I will use /proc/mount from now on as Rik suggested. Thanks, Bruce
One word of warning about mount output: Some of the mount flags are maintained by the kernel, but not all. In particular, in this case, /proc/mount does not show the ext3 data ordering mode. The remaining flags are maintained in user space by mount, via the /etc/mtab file. But obviously that file is not available to be updated when root is first mounted readonly, so its contents are not authoritative for the root filesystem. Use the kernel dmesg log to be 100% certain of how the kernel mounted ext3 as root; a line like EXT3-fs: mounted filesystem with ordered data mode. indicates the default data=ordered, for example. Reassinging to initscripts, as that's where root flags are maintained.
OK, start over - what issue are you trying to solve here? The panic? Something else?
Bill, > OK, start over - what issue are you trying to solve here? The panic? Something else? They way to mount / with data=ordered mount option: 1) The kernel panic seems to be the result of that this data=ordered flag could not be recognized when you pass it over as boot flag; e.g., by adding rootflags=data=journal to grub.conf. 2) If you put the option in /etc/fstab, the / cannot be remounted by initscript and was left in read-only mode. Of course, you cannot run a system this way. Thanks, Bruce
Does it mount correctly in RHEL 4, or just 'not panic'?
> Does it mount correctly in RHEL 4, or just 'not panic'? Yes, it mounts correctly as far as I can tell; i.e., the system didn't panic and dmesg indicates: EXT3-fs: mounted filesystem with journal data mode.
Hi, What's the status of this call? Thanks, Bruce
Have not reproduced yet.
So... The reason that passing data=journal to rootflags doesn't work is because the initrd is ext2, and it (predictably) doesn't support that flag, and then panics. The reason you can't put it in fstab, generally, is that it's already mounted with the 'normal' flags by the initrd, and therefore can't be remounted with different journalling flags. To fix this, you'd have to edit fstab, and then *rebuild the initrd*. Then it should work fine.
*** Bug 118897 has been marked as a duplicate of this bug. ***
> The reason that passing data=journal to rootflags doesn't work is because the > initrd is ext2, and it (predictably) doesn't support that flag, and then panics. But then why it works on RHEL 4? > To fix this, you'd have to edit fstab, and then *rebuild the initrd*. Again, I didn't have to do this step on RHEL 4 and it worked. Thanks, Bruce
RHEL4 is using initramfs, not initrd - this changes how the flags are handled at boot.