Red Hat Bugzilla – Bug 1249513
filesystems with the x-initrd.mount option and passno=2 in /etc/fstab do not get mounted after boot
Last modified: 2015-11-19 10:07:53 EST
Created attachment 1058667 [details]
journalctl -a with debug on the kernel cmdline
Description of problem:
If a mount defined in /etc/fstab has the x-initrd.mount option defined and passno=2, the filesystem does not get mounted after boot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. define a mount in /etc/fstab like this:
UUID=d73c79a6-6303-4aa3-842a-4b8756041935 /boot xfs x-initrd.mount 1 2
/boot is not mounted.
/boot is mounted.
systemd logs the following message after switching root:
systemd: Unmounting /boot...
journalctl -a with debug on the kernel cmdline attached.
The issue does not occur with systemd-219-9.el7.centos.x86_64 from https://copr.fedoraproject.org/coprs/lnykryn/systemd/, which means that it has been fixed upstream already.
(In reply to Marcel Kolaja from comment #2)
> The issue does not occur with systemd-219-9.el7.centos.x86_64 from
> https://copr.fedoraproject.org/coprs/lnykryn/systemd/, which means that it
> has been fixed upstream already.
Also it means that it will be fixed in 7.2.
Fails with RHEL7.1:
# rpm -qa |grep systemd
Works with 7.2 dev release:
# rpm -qa |grep systemd
# cat /etc/fstab
# Created by anaconda on Mon Aug 3 08:56:57 2015
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
/dev/mapper/rhel_cisco--c240m3--1-root / xfs defaults 0 0
#UUID=c1ec61cd-8651-4118-b61f-190595863058 /boot xfs defaults 0 0
UUID=c1ec61cd-8651-4118-b61f-190595863058 /boot xfs x-initrd.mount 1 2
/dev/mapper/rhel_cisco--c240m3--1-home /home xfs defaults 0 0
/dev/mapper/rhel_cisco--c240m3--1-swap swap swap defaults 0 0
05:29:14 up 3 min, 1 user, load average: 0.22, 0.38, 0.19
# mount | grep boot
/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
If I understand it properly, it's already fixed, so qa_acking to get this to erratum.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.