Hide Forgot
On fedorapeople.org, we have the following in /etc/fstab: tmpfs /dev/shm tmpfs noexec,nosuid,nodev 0 0 However, on a reboot, /proc/mounts shows that /dev/shm is not mounted with these options. The cause seems to be that /dev/shm is initially mounted in the initramfs, and then line 490 of /etc/rc.d/rc.sysinit performs a "fake" mount of /dev/shm before mounting the rest of the filesystems. This causes /etc/mtab and the mount command to show that /dev/shm has the proper mount options when that isn't actually the case.
-> dracut.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
rc.sysinit should do: mount /dev -oremount mount /dev/shm -oremount mount /dev/pts -oremount mount /proc -oremount mount /sys -oremount or fix mount and do: mount -a -oremount after /etc/mtab is rw
Why should initscripts do that instead of dracut using the specified options to begin with? (Among other reasons, it is racy...)
because these are mounted before dracut can even access /etc/fstab... Btw, systemd does "mount -a -oremount" on boot time.
(In reply to comment #7) > Why should initscripts do that instead of dracut using the specified options to > begin with? (Among other reasons, it is racy...) what is racy?
(In reply to comment #8) > because these are mounted before dracut can even access /etc/fstab... When creating the initramfs, it can use the options from the existing fstab. (Yes, it requires remaking the initramfs if you change the options.) (In reply to comment #9) > what is racy? Requiring remount in initscripts means there's always a window where the fs has the 'wrong' options. Admittedly, in this case it's unlikely to ever amount to much.
Created attachment 567602 [details] Proposed patch
I could see doing this... on the other hand, if you're trying to specify alternate options for /proc and /sys, you're trying to break your system. Also, the patch assumes all those filesystems are mounted, which they may not be.
I'd like to add that the "size=xxxx" option for /dev/shm is ignored by the current system, and a hacky: mount -o remount /dev/shm in rc.local is required to fix. I have regenerated the initramfs after changing fstab to prove to myself it's ignored. In comment#10, Bill recommended reading fstab, but I think it's counter-intuitive that a change in /etc/fstab would require regenerating the initramfs to take effect, especially if a one-line fix in rc.sysinit will do the trick (referring only to my specific /dev/shm size problem here).
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
We went through possibilities of how to cover notes from Bill's comment. The window mentioned in comment #10 should do no harm, because the same behaviour (remount everything in fstab) can be found in systemd (systemd-remount-fs.service) and Upstart. With this in mind, patch attached to this bug should be ok. We would just hide error messages from /dev, /dev/shm and /dev/pts remounts - if these are not mounted, error message is emitted, but nothing else happens.
(In reply to comment #13) > I'd like to add that the "size=xxxx" option for /dev/shm is ignored by the > current system, and a hacky: > > mount -o remount /dev/shm > > in rc.local is required to fix. rc.local is run last. What would be a suitable workaround if the remount is needed earlier? I have an Oracle system which needs /dev/shm to be a certain size. The fstab values being ignored means that Oracle does not start up and in turn all the things that depend on Oracle fall over.
Easiest but probably not so nice solution is to create initscript with low start number which will do the job.
mount -o remount /dev/shm does not honour the mode= mount option in tmpfs.
(In reply to comment #22) > mount -o remount /dev/shm > > does not honour the mode= mount option in tmpfs. probably mount needs a patch, then
(In reply to comment #22) > mount -o remount /dev/shm > > does not honour the mode= mount option in tmpfs. Can you post some reproducer to this? Because on my rhel6 [root@rhel6 ~]# grep shm /etc/fstab tmpfs /dev/shm tmpfs defaults 0 0 [root@rhel6 ~]# mount | grep shm tmpfs on /dev/shm type tmpfs (rw) [root@rhel6 ~]# vim /etc/fstab [root@rhel6 ~]# grep shm /etc/fstab tmpfs /dev/shm tmpfs mode=777 0 0 [root@rhel6 ~]# mount -o remount /dev/shm [root@rhel6 ~]# mount | grep shm tmpfs on /dev/shm type tmpfs (rw,mode=777)
Certainly, examine the filesystem instead of relying on mtab (note mode=777 is the default and therefore is not a good test case): $ grep shm /etc/fstab tmpfs /dev/shm tmpfs defaults 0 0 $ ls -ld /dev/shm drwxrwxrwt 2 root root 40 May 24 21:59 /dev/shm $ vi /etc/fstab tmpfs /dev/shm tmpfs mode=770 0 0 $ mount -oremount /dev/shm $ ls -ld /dev/shm drwxrwxrwt 2 root root 40 May 24 21:59 /dev/shm $ mount | grep shm tmpfs on /dev/shm type tmpfs (rw,mode=770)
We are remounting /dev/shm since rhel-6.4 a it seems to work on my machine, maybe if there are some options which are not applied than this could be a bug in mount.
Some notes: - always check /proc/mounts or /proc/self/mountinfo on old systems with classic mtab. Never rely on "mount | grep"... - mount(8) parses only mount flags (e.g. nosuid), but the rest is send to kernel as string and all depends on kernel. - it's naive to assume that you can change arbitrary mount option by remount - kernel (VFS) supports remount for basic mount flags like nosuid,noexec,... - the another options depends on FS driver and it's pretty common that you cannot change many FS mount options on the fly (for example kernel tmpfs (mm/shmem.c: shmem_remount_fs()) cares about size=, mpol=.. but no about mode=) - it's pretty simple to debug mount(8), just use strace to see mount(2) syscall: # strace -e mount mount -o remount,mode=777 /dev/shm mount("tmpfs", "/dev/shm", 0x7f3af256c250, MS_MGC_VAL|MS_NOSUID|MS_NODEV|MS_REMOUNT, "seclabel,mode=777") = 0 +++ exited with 0 +++
Bug as described still exists, not all /etc/fstab mount options are honoured after boot, and those that are are applied in a racy manner and cannot be relied on to be present. This as I understand it is an architectural problem with dracut, which expects remount to work for all options, rather than intended behaviour. At the very least mark this WONTFIX, or document that you have deprecated /etc/fstab?
(In reply to David Zambonini from comment #34) > Bug as described still exists, not all /etc/fstab mount options are honoured > after boot, and those that are are applied in a racy manner and cannot be > relied on to be present. This as I understand it is an architectural problem > with dracut, which expects remount to work for all options, rather than > intended behaviour. OK. > At the very least mark this WONTFIX, or document that you have deprecated > /etc/fstab? fstab is not deprecated... re-assigning back to initscripts, from mount(8) point of view there is no bug.
> - it's naive to assume that you can change arbitrary mount option by remount > - kernel (VFS) supports remount for basic mount flags like > nosuid,noexec,... > - the another options depends on FS driver and it's pretty common that you > cannot change many FS mount options on the fly > > (for example kernel tmpfs (mm/shmem.c: shmem_remount_fs()) cares about > size=, mpol=.. but no about mode=) > According to this we can't do anything better in initscripts. So closing as can't fix.