Description of problem: Was looking into why fsck seems to be run by systemd on every boot and EXT4-fs ($FOO): mounted/remounted Opts: (null) might be harmless msg or it might be not but atleast it's confusing grep EXT4 /shutdown-log.txt [ 1.273126] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) [ 1.669227] EXT4-fs (sda4): re-mounted. Opts: (null) [ 1.771575] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) [ 1.774217] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [ 51.968922] EXT4-fs (sda4): re-mounted. Opts: (null) [ 51.978952] EXT4-fs (sda4): re-mounted. Opts: (null) [ 51.979003] EXT4-fs (sda4): re-mounted. Opts: (null) [ 51.991814] EXT4-fs (sda4): re-mounted. Opts: (null) sda4 = / sda2 = /boot sda5 = /home From /proc/mounts / ext4 rw,relatime,data=ordered 0 0 /boot ext4 rw,relatime,data=ordered 0 0 /home ext4 rw,relatime,data=ordered 0 0 I would expect to see one of the following. 1) (Re)mounted filesystem without Opts: as in mounted filesystem with ordered data mode. re-mounted. 2) mounted filesystem with ordered data mode. Opts: ( rw,relatime,data=ordered 0 0 ) re-mounted. Opts: ( rw,relatime,data=ordered 0 0 ) 3) Basically anything but "null" filled in there Version-Release number of selected component (if applicable): All the kernel version after someone decided to change or break this How reproducible: Always Steps to Reproduce: 1. boot/shutdown 2. examine dmesg output/logs 3. Actual results: Null Expected results: Actually the mounted options Additional info:
I believe the Opts: here is in reference to options stored in ASCII format in the superblock on-disk. If the filesystem is created without specifying options then there won't be any stored there as far as I under stand things. Eric, does that sound right?
Josh, yes that's right: ext4_msg(sb, KERN_INFO, "mounted filesystem with%s. " "Opts: %s%s%s", descr, sbi->s_es->s_mount_opts, *sbi->s_es->s_mount_opts ? "; " : "", orig_data); We could swap "null" for "none" but that doesn't really sound like a pressing issue to me. It might be better to change the dmesg printk to say "with default mount options" or something, because it's odd to specify a mount option on the mount cmdline & get "Opts: (null)" Johann, want to send that trivial patch to the linux-ext4 list? :) As for whether this is related to your fsck behavior: I really don't think so. Thanks, -Eric
(In reply to Eric Sandeen from comment #2) > Josh, yes that's right: > > ext4_msg(sb, KERN_INFO, "mounted filesystem with%s. " > "Opts: %s%s%s", descr, sbi->s_es->s_mount_opts, > *sbi->s_es->s_mount_opts ? "; " : "", orig_data); > > > Johann, want to send that trivial patch to the linux-ext4 list? :) > Challenge accepted! ;)
Excellent. And I collect the +1 delegation powerup. ;)
Well first attempt upstreamed.. http://www.spinics.net/lists/linux-ext4/msg39137.html
Gah. Actually the more I look at this the more I think this (default mount options stuff) is a half-assed ext4 bell & whistle that doesn't work right.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
Eric ping any conclusion on this?
Sorry Jóhann, I guess it got lost upstream, and TBH I forgot about it. You could re-send it upstream; a more descriptive changelog, stating the problem and demonstrating the new output, might be helpful. If you don't want to, I could try to find time to pick it up & try to get it changed. -Eric
Based on your comment 6 I would expect you to take it to the next level.
Sigh, delegation fail. :)
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.