On my old i586 system, if I use run level 3, and startx, mount options change as follows ... [dave@hodgins ~]$ diff mount.b4startx.sorted mount.afstartx.sorted 14c14 < /dev/mapper/bk-usr on /usr type ext4 (rw,relatime,data=ordered) --- > /dev/mapper/bk-usr on /usr type ext4 (ro,relatime,data=ordered) 19c19 < /dev/mapper/luks91 on /var/mnt/data type ext4 (rw,relatime,nodelalloc,user) --- > /dev/mapper/luks91 on /var/mnt/data type ext4 (rw,nosuid,nodev,noexec,relatime,nodelalloc,user) No changes are made to the mount options, if I use run level 5. I'm guessing about which rpm package to report this against, as I have no idea what is causing the difference, or where the actual remounting occurs. The fstab for /usr is /dev/mapper/bk-usr /usr ext4 acl,commit=0,user_xattr,rw 1 2 (I added the rw, explicitly, when I thought it was dracut mounting it ro, before I realized it only gets remounted ro when I run startx). /var/mnt/data is mounted by a script, before running startx with sudo /bin/mount -v -t ext4 -o defaults,user,exec,dev,suid,relatime,user_xattr /dev/mapper/$MapperName $MountPoint /usr is dm-0, luks91 is dm-9 # journalctl -ab|grep -e dm-0 -e dm-9 Dec 14 16:13:33 hodgins.homeip.net kernel: EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: acl,commit=0,user_xattr Dec 14 16:13:33 hodgins.homeip.net kernel: EXT4-fs (dm-0): re-mounted. Opts: acl,commit=0,user_xattr Dec 14 16:14:00 hodgins.homeip.net kernel: EXT4-fs (dm-0): re-mounted. Opts: acl,commit=0,user_xattr,acl,user_xattr,commit=0 Dec 14 16:14:23 hodgins.homeip.net kernel: EXT4-fs (dm-9): mounted filesystem with journalled data mode. Opts: user_xattr Dec 14 16:14:59 hodgins.homeip.net kernel: EXT4-fs (dm-0): re-mounted. Opts: acl,commit=0,user_xattr,commit=0 Dec 14 16:15:00 hodgins.homeip.net kernel: EXT4-fs (dm-0): re-mounted. Opts: data=ordered,commit=0 Dec 14 16:15:01 hodgins.homeip.net kernel: EXT4-fs (dm-0): re-mounted. Opts: data=ordered,commit=0 Dec 14 16:15:01 hodgins.homeip.net kernel: EXT4-fs (dm-9): re-mounted. Opts: nodelalloc,commit=0 dmesg is not showing any filesystem errors. This happens every time I use startx with run level 3, and does not happen at all, with run level 5. Reproducible: Steps to Reproduce:
One possibly interesting thing, changes in /proc/self/mountinfo after running startx ... diff mountinfo.b4startx mountinfo.afstartx 8c8 < 22 21 252:0 / /usr rw,relatime shared:2 - ext4 /dev/mapper/bk-usr rw,data=ordered --- > 22 21 252:0 / /usr rw,relatime shared:2 - ext4 /dev/mapper/bk-usr ro,data=ordered 33,34c33,34 < 47 39 252:0 /lib/bind /var/lib/named/usr/lib/bind ro,relatime shared:2 - ext4 /dev/mapper/bk-usr rw,data=ordered < 48 39 252:0 /lib/openssl /var/lib/named/usr/lib/openssl ro,relatime shared:2 - ext4 /dev/mapper/bk-usr rw,data=ordered --- > 47 39 252:0 /lib/bind /var/lib/named/usr/lib/bind ro,relatime shared:2 - ext4 /dev/mapper/bk-usr ro,data=ordered > 48 39 252:0 /lib/openssl /var/lib/named/usr/lib/openssl ro,relatime shared:2 - ext4 /dev/mapper/bk-usr ro,data=ordered 36c36 < 88 41 252:9 / /var/mnt/data rw,relatime shared:66 - ext4 /dev/mapper/luks91 rw,nodelalloc --- > 88 41 252:9 / /var/mnt/data rw,nosuid,nodev,noexec,relatime shared:66 - ext4 /dev/mapper/luks91 rw,nodelalloc
Another clue. This does not happen with "startx Openbox", but does with either startx KDE4 or startx GNOME.
Just fyi, create a new user, and confirmed it also happens with that user.
typo. Created a new user, and confirmed it also happens with that user.
Keywords: (none) => TriagedCC: (none) => mageiaAssignee: bugsquad => dirteat
ok, I'll have a look. I see Colin is in cc, I may call for help at some point... :) cheers.
Hi there, I cannot reproduce with my mga3, my partitions remain mounted as they are under runlevel 3, even after startx GNOME or KDE (rw, relative, data=ordered). But I see in your messages that the concernes partitions are under /dev/mapper/; are they encrypted? cheers, chris.
I have no chance to help for this bug is noone can confirm or reproduced this bug. I switched to unconfirmed. cheers, chris.
Status: NEW => UNCONFIRMEDEver confirmed: 1 => 0
I've switched that i586 system to Mageia 4, where this doesn't happen. Closing the bug as old.
Status: UNCONFIRMED => RESOLVEDResolution: (none) => OLD