10

I have an embedded system using jffs2 and want to pass rootflags=noatime in the kernel bootargs parameter.

This results in a kernel panic:

jffs2: Error: unrecognized mount option 'noatime' or missing value
[...]
No filesystem could mount root, tried:  jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)

However, if I boot normally and then remount the jffs2 filesystem with noatime, it works fine:

$ mount -o remount,noatime /

I am puzzled by this as according to the documentation, the rootflags argument "allows you to give options pertaining to the mounting of the root filesystem just as you would to the mount program".

Looks like a kernel bug to me, but on the other hand it seems so obvious that perhaps I am overlooking something.

I have tested this with kernel versions 3.7 and 3.14.

Can someone shed some light?

Improve this question
2
  • why you don't you the fstab for setting noatime in your /? Commented May 24, 2014 at 19:07
  • I can do that of course but that does not answer my question (why rootflags=noatime doesn't work) Commented May 25, 2014 at 19:17

1 Answer 1

Reset to default
10
+150

Googling rootflags noatime brings up this post from 2003 by Andrew Morton, perhaps it still applies.

http://lkml.org/lkml/2003/8/12/236

While testing something, I tried to boot with 'rootflags=noatime', and found the system wouldn't boot, as ext3, ext2, and reiserfs all failed to recognize the option. Looking at the code in fs/ext3/super.c:parse_options() and init/do_mounts.c:root_data_setup(), it appears to be impossible to set any of the filesystem-independent flags via rootflags, which explains the special-case code for the 'ro' and 'rw' flags. However, there doesn't seem to be any way to pass nodev, noatime, nodiratime, or any of the other flags. (And yes, all 3 of those make sense in my environment - it's a laptop and I don't need atime, and I use devfs so nodev on the root makes sense too).

The fs-independent options are parsed in user space by mount(8), and are passed into the kernel as individual bits in a `flags' argument.

Improve this answer
3
  • Would this be a documentation bug then ? Commented May 22, 2014 at 8:12
  • I see the documentation you linked is also dated 2003. So you could make that argument. If this was a common problem I'd blame the kernel for being inconsistent instead. In practice... if you keep reading the thread it suggests that using an initrd/initramfs to mount the rootfs instead could work around it, and initramfs is the common case nowadays (at least for non-embedded). My search also brought up specific complaints that this problem happened when booting without an initramfs. Which I should have mentioned if I wasn't being lazy. Eg bugzilla.kernel.org/show_bug.cgi?id=61601 Commented May 22, 2014 at 10:31
  • This still seems to be an issue, just ran into this with a 5.4 kernel (only works with an initramfs). Commented Jan 11, 2024 at 22:38

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.