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.
Can you attach the errors when it fails
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.
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.
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
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?
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
Created attachment 146181 [details] call trace screen print - kernel 3.16 kernel panic occurs with rootflags=noatime in kernel command line boots ok without rootflags=noatime
note I am booting without initrd
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
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.
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.
Created attachment 146201 [details] attachment-27498-0.html 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. On Mon, Aug 11, 2014 at 12:32 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=61601 > > --- Comment #11 from xerofoify@gmail.com --- > 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. > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
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.
Created attachment 146281 [details] attachment-7823-0.html damn, i see now. im definitely gonna go after that challenge. thanks On Mon, Aug 11, 2014 at 9:24 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=61601 > > --- Comment #13 from Theodore Tso <tytso@mit.edu> --- > 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. > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
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?
Try rootflags=noatime as a kernel boot option?
for obvious reasons "rootflags=noatime" does result in a kernel error as shown in the above comments
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).