You are not logged in.
Pages: 1
After a fresh install on a brandnew laptop, my root partition is being mounted read only, and I see that systemd-remount-fs.service fails:
[root@anton ~]# systemctl status systemd-remount-fs.service
systemd-remount-fs.service - Remount Root and Kernel File Systems
Loaded: loaded (/usr/lib/systemd/system/systemd-remount-fs.service; static)
Active: failed (Result: exit-code) since Sat, 2012-12-01 21:00:05 MST; 18min ago
Docs: man:systemd-remount-fs.service(8)
Process: 186 ExecStart=/usr/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/systemd-remount-fs.service
Dec 01 21:00:05 anton systemd-remount-fs[186]: mount: / not mounted or bad option
Dec 01 21:00:05 anton systemd-remount-fs[186]: In some cases useful info is found in syslog - try
Dec 01 21:00:05 anton systemd-remount-fs[186]: dmesg | tail or so
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
I have no idea why this is happening, or what to do to try and fix it - any help/advice would be greatly appreciated. Following is the information I think is necessary for assistance:
Note that I have /usr on a separate partition, which I suspect is possibly involved in the issue somehow.
Here's my fstab:
[root@anton ~]# cat /etc/fstab
# /dev/sda5
#UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 / ext4 defaults,rw,noatime,discard,data=writeback 0 1
# /dev/sda6
UUID=f4ab3551-c4f8-4e77-97bb-cc754c81af24 /usr ext4 defaults,noatime,discard,data=writeback 0 0
# /dev/sda7
UUID=c8d2776b-faaa-4a9d-ad49-4b09489faaaa /var ext4 defaults,rw,noatime,discard 0 2
# /dev/sda8
UUID=3dff3fa5-3291-4227-907a-258f12e1b3cf /home ext4 defaults,rw,relatime,discard 0 2
Here's the relevant output from mount (note that my root (sda5) partition is not being mount with the options I specified in fstab):
[root@anton ~]# mount | grep sda
/dev/sda5 on / type ext4 (ro,relatime,data=ordered)
/dev/sda6 on /usr type ext4 (rw,noatime,discard,data=writeback)
/dev/sda7 on /var type ext4 (rw,noatime,discard,data=ordered)
/dev/sda8 on /home type ext4 (rw,relatime,discard,data=ordered)
Relavant snippet from /boot/grub/grub.cfg:
menuentry 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-a09ff37e-ce60-4173-b95a-4b71a53c01d3' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 a09ff37e-ce60-4173-b95a-4b71a53c01d3
else
search --no-floppy --fs-uuid --set=root a09ff37e-ce60-4173-b95a-4b71a53c01d3
fi
echo 'Loading Linux core repo kernel ...'
linux /boot/vmlinuz-linux root=UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 ro init=/usr/lib/systemd/systemd
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-linux.img
}
Finally, here's my mkinitcpio.cfg:
[root@anton ~]# cat /etc/mkinitcpio.conf
MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect sata filesystems usbinput usr fsck shutdown"
Last edited by corey_s (2012-12-02 08:57:35)
Offline
Out of curiosity, what happens if you either don't include the 'ro' in your bootloader kernel command line or change it to 'rw'. The 'ro' is not needed anymore, as it used to be in place so that your root fs could be fscked. Nowadays, it is fscked by the initramfs before t is even mounted, assuming you are not one of those looking for no initramfs and a separate /usr .
Edit: BTW, s there any information when you check the journal? Systemctl status is a great place to start, but maybe you might be able to dig up more information.
Last edited by WonderWoofy (2012-12-02 05:36:19)
Offline
Thanks for the quick response, WonderWoofy ( by the way, great username! )!
When I removed or modified the the mount options in the bootloader kernel command line, there was no change to the status of the fs after boot-up. I had changed it at one point from 'ro', to 'rw'; but doing so had no affect on the output of the mount command.
However, I did finally identify the cause: turns out if I specify 'data=writeback', in fstab for the root partition, then systemd-remount-fs.service fails, as per my OP - leaving me with a 'ro'-mounted root filesystem. Simply removing that, or changing it to 'data=ordered', solved the issue: when I rebooted, the root partition was mounted as per my fstab config.
So, my fstab now looks like this:
# /dev/sda5
UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 / ext4 rw,noatime,discard 0 1
# /dev/sda6
UUID=f4ab3551-c4f8-4e77-97bb-cc754c81af24 /usr ext4 defaults,ro,noatime,discard,data=writeback 0 0
# /dev/sda7
UUID=c8d2776b-faaa-4a9d-ad49-4b09489faaaa /var ext4 defaults,rw,noatime,discard 0 2
# /dev/sda8
UUID=3dff3fa5-3291-4227-907a-258f12e1b3cf /home ext4 defaults,rw,relatime,discard 0 2
... and all is now well.
I'll mark this as solved, but I'll also ask: why does specifying 'data=writeback' on my root partition cause the systemd-remount-fs.service to fail? Any experts out there know?
Last edited by corey_s (2012-12-02 06:46:32)
Offline
Yeah that makes sense now that you mention it. That option I believe is an ext3 option and not ext4. Ext4 has the default of data=ordered, but there is something different option to specify to make it otherwise.
Edit: See man 8 mount and search for auto_da_alloc|noauto_da_alloc which will be in the section of ext4 specific mount options. In the section above it there is info about data=(journal|ordered|writeback) which might give you an idea of why it is an ext3 option and not ext4.
Last edited by WonderWoofy (2012-12-02 08:57:42)
Offline
Yeah that makes sense now that you mention it. That option I believe is an ext3 option and not ext4. Ext4 has the default of data=ordered, but there is something different option to specify to make it otherwise.
Edit: See man 8 mount and search for auto_da_alloc|noauto_da_alloc which will be in the section of ext4 specific mount options. In the section above it there is info about data=(journal|ordered|writeback) which might give you an idea of why it is an ext3 option and not ext4.
Cool - thanks for the info! Very helpful.
Cheers!
Last edited by corey_s (2012-12-02 08:59:47)
Offline
Pages: 1