Bug 151961 - Putting rootflags=data=journal in grub.conf cause kernel panic
Putting rootflags=data=journal in grub.conf cause kernel panic
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
3.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
: 118897 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-23 16:16 EST by Shing-Shong Shei
Modified: 2014-03-16 22:53 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-20 18:34:08 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)

  None (edit)
Description Shing-Shong Shei 2005-03-23 16:16:15 EST
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.
Comment 1 Stephen Tweedie 2005-04-06 11:37:25 EDT
_What_ was the kernel panic, exactly?
Comment 2 Shing-Shong Shei 2005-04-06 12:08:19 EDT
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
Comment 3 Shing-Shong Shei 2005-04-09 14:00:16 EDT
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
Comment 4 Shing-Shong Shei 2005-04-18 13:00:44 EDT
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
Comment 5 Stephen Tweedie 2005-04-18 14:11:09 EDT
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.
Comment 6 Rik van Riel 2005-04-18 14:16:48 EDT
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...
Comment 7 Shing-Shong Shei 2005-04-18 14:38:11 EDT
(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
Comment 8 Shing-Shong Shei 2005-04-18 14:43:51 EDT
(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
Comment 9 Shing-Shong Shei 2005-04-18 15:04:27 EDT
> 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
Comment 10 Shing-Shong Shei 2005-04-18 15:25:04 EDT
(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
Comment 11 Rik van Riel 2005-04-18 17:16:18 EDT
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...
Comment 12 Shing-Shong Shei 2005-04-18 17:31:00 EDT
(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
Comment 13 Rik van Riel 2005-04-18 18:26:23 EDT
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).
Comment 14 Stephen Tweedie 2005-04-21 11:15:45 EDT
ext3 journal flags can _definitely_ not be changed at remount time.
Comment 15 Shing-Shong Shei 2005-04-21 11:45:37 EDT
> 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
Comment 16 Stephen Tweedie 2005-04-21 12:12:11 EDT
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.
Comment 17 Bill Nottingham 2005-04-21 14:56:32 EDT
OK, start over - what issue are you trying to solve here? The panic? Something else?
Comment 18 Shing-Shong Shei 2005-04-21 15:03:47 EDT
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
Comment 19 Bill Nottingham 2005-04-21 15:08:59 EDT
Does it mount correctly in RHEL 4, or just 'not panic'?
Comment 20 Shing-Shong Shei 2005-04-21 15:15:56 EDT
> 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.
Comment 21 Shing-Shong Shei 2005-05-27 11:22:55 EDT
Hi,

What's the status of this call?

Thanks,
Bruce
Comment 22 Bill Nottingham 2005-05-27 12:14:36 EDT
Have not reproduced yet.
Comment 23 Bill Nottingham 2005-09-20 18:34:08 EDT
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.
Comment 24 Bill Nottingham 2005-09-20 18:35:05 EDT
*** Bug 118897 has been marked as a duplicate of this bug. ***
Comment 25 Shing-Shong Shei 2005-09-22 10:47:15 EDT
> 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
Comment 26 Bill Nottingham 2005-09-22 11:59:48 EDT
RHEL4 is using initramfs, not initrd - this changes how the flags are handled at
boot.

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