New: rootflags=noatime causes kernel panic when booting without initrd.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

            Bug ID: 61601
           Summary: rootflags=noatime causes kernel panic when booting
                    without initrd.
           Product: File System
           Version: 2.5
    Kernel Version: 3.11, 3.10
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

I have create kernel with built in SATA drivers and ext4 filesystem. Everything boots fine when I launch the kernel without rootflags=noatime. When I add to the kernel parameters rootflags=noatime I got kernel panic direct after the kernel launch and try to mount the root partition. This could affect other filesystem too, but I didn't test it. My kernel cmdline is be default:

root=/dev/sda4 rw acpi=noirq vga=773 logo.nologo loglevel=0 libata.force=noncq quiet libahci.ignore_sss=1 rootfstype=ext4.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Alan <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |NEEDINFO
                 CC|                            |[email protected]

--- Comment #1 from Alan <[email protected]> --- Can you attach the errors when it fails

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #2 from Mateusz <[email protected]> ---
Sure. Here is a screen shot
https://dl.dropboxusercontent.com/u/1664131/IMG_20131113_171340.jpg I am not sure - but maybe it could conflict with the relatime flag (as far I see the kernel add this flags by default when mounting a partition.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Conrad Meyer <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #3 from Conrad Meyer <[email protected]> --- Attempt to repro (3.14-rc8-next-20140328), root fs is ext4.

Added rootflags=noatime to my 'append' line in extlinux.conf.

Could not repro. System boots fine.

Looking at relatime flag, kernel only adds this when NOATIME is not already specified. So that doesn't seem likely to be the issue.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Johannes Hirte <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |e

--- Comment #4 from Johannes Hirte <[email protected]> --- This isn't ext4 specific, I have the same problem with btrfs. And from a short search, this problem isn't new at all:
http://forums.gentoo.org/viewtopic-p-7238926.html?sid=6e8180da852b6b71dea57abf4bf58bce#6894398

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #5 from Mateusz <[email protected]> ---
Conrad Meyer but did you boot without initrd? With initrd it boots fine because the root fs is mounted by a busybox script but without it the kernel mounts the root fs with relatime with conflicts with noatime. Johannes Hirte so it looks like all file system are affected, with category should I set now?

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #6 from [email protected] ---
Would you fine giving me a trace back on a release from the last year as it may be fixed. If not I would be glad to fix it.
Cheers Nick

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

James Campbell <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #7 from James Campbell <[email protected]> --- Created attachment 146181
--> https://bugzilla.kernel.org/attachment.cgi?id=146181&action=edit
call trace screen print - kernel 3.16

kernel panic occurs with rootflags=noatime in kernel command line boots ok without rootflags=noatime

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #8 from James Campbell <[email protected]> --- note I am booting without initrd

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #9 from [email protected] ---
I need you to check if your system is running dual initrd/ramload setup, as the lines I am tracing to our ,
520 if (rd_doload==2) {
521 if (rd_load_disk(1)) {
522 ROOT_DEV = Root_RAM1;
523 root_device_name = NULL;
524 }
And you may be loading the wrong ram disk and this needs to be changed from 1 to 0.
Regards Nick

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Theodore Tso <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #10 from Theodore Tso <[email protected]> ---
Here's what's going on. There are some mount flags that are parsed by the
userspace mount program, and translated to an integer field "mountflags" in the
mount(2) system call. See the man page for mount(2) for more details; see the
flags MS_NOATIME, MS_NOEXEC, MS_NOSUID, etc. They are described in the mount(8) system call in the section "FILESYSTEM INDEPENDENT MOUNT OPTIONS".

If you are using an initrd, the rootflags boot line command is handled by the userspace mount program; the initrd is responsible for mounting the root file system, and it does so using mount(8).

However, if you are not using an initrd, then the mount flags are handled by /usr/src/linux/init/do_mounts.c, and the kernel code simply doesn't handle converting "noatime" into MS_NOATIME and then or'ing it into root_mountflags.

The simplest workaround is to add in your init scripts the command:

mount -o remount,noatime /

you could combine this with the init script command which remounts the root
file system read-only, i.e.: mount -o remount,rw,noatime /

P.S. Ignore Nick's comment in #9. He's guessing, and he doesn't know what he's doing. He's been banned from LKML, but unfortunately he hasn't been banned from the kernel bugzilla yet. It's one thing when he's wasting maintainers' time, but when he's confusing and adding negative value to users
who are asking for help, it's definitely not ok. We'll have to remedy
that....

See https://plus.google.com/+TheodoreTso/posts/ELVf6FmuY2N for more details.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #11 from [email protected] ---
Thanks Ted,
I was guessing, seems your right. The only choice I have with bugs and other work now is to guess or known what I am doing. Due to the maintainers not wanting to help me any more I have no choice but to guess or just leave. Seems better now to just leave it.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #12 from Jacob Lane <[email protected]> ---
the maintaners should be open to helping people solver other problems. thats a big issue for me. the mailing lists arent very open to new people. its either your a pro or gtfo. and i feel that slows the amount of people getting involved in the community. why not teach outside people how to solve bugs/fix problems? Its like free volunteers for helping people out. they just need training.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #13 from Theodore Tso <[email protected]> ---
Jacob, there are very good programs to help people learn how to get involved with kernel development. See the kernelnewbies.org web site and mailing list,
for example. But you need to have some amount of basic competence; being able
to use Google well, for example, and doing silly things like making sure the patches compile before you submit patches for review.

Also, if you have clueless people asking users completely random questions that are completely useless in terms of fixing the problem, it wastes the user's
time and causes them to get very frustrated. So having newbies trying to help
users who are reporting kernel bugs is not a good idea. If they want to help users install Linux distributions, that's fine --- so long as you are minimally competent in doing installation. Similarly, if you are completely incompetent in doing kernel development, you should not be offering to help users.

There are ways for newbies to get involved. The problem is Nick has consistently ignored advice of people who have wasted a huge amount of time trying to get him on the right path. Which is why he has gotten banned.

If you are someone who wants to get started, there is the Eudyptula Challenge
(http://eudyptula-challenge.org). Nick finally got involved with this, and
then violated the very simple rules, which caused him to get ejected from the Challenge within hours, thus setting a new record for the Eudyuptula Challenge.
Anyway, this is off topic for the bug. So please stop discussing this here,
please.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #14 from Jacob Lane <[email protected]> --- damn, i see now. im definitely gonna go after that challenge. thanks

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Karol Herbst <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #15 from Karol Herbst <[email protected]> --- Hi,

I have the same problem, which is causing me to remount / later in the boot process, which increases my boot time by about 12%.

linux-4.0.5
fstype=btrfs

Is there any good workaround on kernel level to mount / directly as noatime before init gets started?

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Christian Kujau <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #16 from Christian Kujau <[email protected]> --- Try rootflags=noatime as a kernel boot option?

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

--- Comment #17 from Karol Herbst <[email protected]> ---
for obvious reasons "rootflags=noatime" does result in a kernel error as shown in the above comments

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

János Tóth F. <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #18 from János Tóth F. <[email protected]> ---
I ran into this problem recently with kernel 4.5.5 when I tried copy-pasting all my mount options of / from fstab to the kernel cmdline as rootflags after I learned the space_cache=V2 mount option of Btrfs does not activate the new cache properly during the fstab-based RW remount of / when the kernel mounted it RO with default options including space_cache V1 (at least based on the kernel log messages but this should probably be investigated further if RO/RW has anything to do with this, or if it's enough to do the initial mount with this cache V2 option for a single time when the old space cache v1 should be invalidated and a new v2 type cache must be created or these have to stay for consecutive reboots).

This might be Gentoo-specific but I also noticed localmount won't re-mount my / with the fstab options when I have this cache rootflag in my kernel cmdline. Thus, I have to manually re-mount / with noatime if I wish to have that option together with cache V2.

I also realized this bug would pretty much be the only reason for me to keep a / entry in my fstab (to apply noatime). But more precisely, my current fstab entry is useless anyway (noatime isn't applied anyway when I specify RW and rootflags in the kernel cmdline).

You are receiving this mail because:
You are watching the assignee of the bug.--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

https://bugzilla.kernel.org/show_bug.cgi?id=61601

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #19 from [email protected] ---
Is there no workaround yet such as another paramater? It still exists in kernel 6.14.0.
I noticed that cost to remount / with noatime is larger than mount / with module less https://github.com/anatol/booster directly .

So I made a hardcoted workaround
(https://github.com/oech3/initramfs-none/blob/main/README.md). The pseudo initrd less boot have 0.1~0.5 sec advantage.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=61601

Disce1971 ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #20 from Disce1971 ([email protected]) --- I encounter a similar bug. Thanks for useful sharing
(https://blockblastadventure.com) linux-4.0.5 fstype=btrfs

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.