Booting kernel 3.18.5 with the journal_async_commit option for / in /etc/fstab causes the root file system to be read-only. kernel 3.18.3 also has this problem. entry in /etc/fstab: UUID=... / ext4 defaults,nodiratime,noatime,journal_async_commit 1 1 Relevant log from dmesg: EXT4-fs (sdb1): changing journal_checksum during remount not supported Adding journal_checksum to /etc/fstab doesn't help. Trying to manually remount root to enable or disable journal_async_commit also doesn't work. kernel 3.17.x works without problems.
If you really want that option (which, btw, had been simply ignored on a remount, prior to this change) you can add it to the rootflags= kernel parameter. But also: http://marc.info/?l=linux-ext4&m=142358693108213&w=2 [PATCH 2/2, RFC] ext4: ignore journal checksum on remount; don't fail As of v3.18, ext4 started rejecting a remount which changes the journal_checksum option. Prior to that, it was simply ignored; the problem here is that if someone has this in their fstab for the root fs, now the box fails to boot properly, because remount of root with the new options will fail, and the box proceeds with a readonly root. I think it is a little nicer behavior to accept the option, but warn that it's being ignored, rather than failing the mount, but that might be a subjective matter... Reported-by: Cónräd <conradsand.arma@gmail.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> ---
I am using kernel 3.16.7 from Opensuse. If I mistype noatime to noatiem the root filesystem mounts read-only.
I also experience same behaviour. The system is unbootable. Please note, that i do NOT have journal_checksum in fstab. On a kernel that works I have the following: /etc/fstab: /dev/mapper/root_crypt / ext4 errors=remount-ro,data=writeback,noatime,nobarrier,journal_async_commit,commit=120,dioread_nolock /proc/mounts: /dev/disk/by-uuid/a3dc1a73-42b9-4295-b0b0-93934b57d317 / ext4 rw,noatime,dioread_nolock,journal_checksum,journal_async_commit,nobarrier,errors=remount-ro,commit=120,data=writeback On 3.18 (ubuntu trusty) I can't boot any way - regular boot fails to mount, mount -o remount doesn't work with any options - with or without journal_async_commit and/or journal_checksum. Note that on 3.13 everything works, all flags are properly applied and they are NOT silently ignored. So this is a bug, but it is yet in denial stage. "remove journal_checksum from fstab, or add it to rootflags, everything works, la-la-la". Pedantic idiots.
It works if you don't have journal_async_commit in /etc/fstab and you also use journal_async_commit in rootflags: % kvm-xfstests -o rootflags=journal_async_commit shell Networking disabled. (process:13728): GLib-WARNING **: /build/glib2.0-l3js1a/glib2.0-2.46.1/./glib/gmem.c:482: custom memory allocation vtable not supported [ 2.405408] systemd-fsck[1392]: /dev/vda: clean, 10240/65536 files, 66092/262144 blocks [ 2.720772] systemd-fsck[2455]: /dev/vdg: recovering journal [ 2.732840] systemd-fsck[2455]: /dev/vdg: clean, 86/327680 files, 58658/1310720 blocks Debian GNU/Linux 8 kvm-xfstests ttyS0 kvm-xfstests login: root (automatic login) Linux kvm-xfstests 4.3.0-rc2ext4-00025-g1a70ea8 #223 SMP Mon Oct 19 00:01:49 EDT 2015 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@kvm-xfstests:~# grep root /etc/fstab /dev/rootfs / ext4 noatime 0 1 root@kvm-xfstests:~# grep root /proc/mounts /dev/root / ext4 rw,noatime,journal_checksum,journal_async_commit,data=ordered 0 0 root@kvm-xfstests:~# cat /proc/cmdline quiet loglevel=0 root=/dev/vda console=ttyS0,115200 cmd=maint fstesttz=America/New_York fstesttyp=ext4 fstestapi=1.2 rootflags=journal_async_commit The changes that were made between 3.13 and 3.18 were intentional and made for good reasons. Changing journalling modes while the file system is mounted is dangerous. In the specific case of changing a read-only to read-write mode it could be made safe, but it's not a priority, because (a) there _is_ a workaround that works, (b) journal_async_commit is not something that to be honest, is not safe unless you are using a pre-release 1.43 version of e2fsprogs, and I'm not super eager to encourage more people to use it unless they really, really know what they are doing. One way you can prove that you know what you are doing is to submit a patch. Using terms like "pedantic idiots" isn't calculated to encourage people to go out of their way to help you or to think that you indeed know what you are doing.