Bug 1249513 - filesystems with the x-initrd.mount option and passno=2 in /etc/fstab do not get mounted after boot
filesystems with the x-initrd.mount option and passno=2 in /etc/fstab do not ...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
7.1
Unspecified Linux
unspecified Severity medium
: rc
: ---
Assigned To: systemd-maint
Branislav Blaškovič
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 04:31 EDT by Marcel Kolaja
Modified: 2015-11-19 10:07 EST (History)
4 users (show)

See Also:
Fixed In Version: systemd-219-1.el7
Doc Type: Bug Fix
Doc Text:
Consequence: Mount points in fstab which should be checked and also should be mounted in initramfs were not mounted at all. Fix: Fixed by rebase. Result: This should work now.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-19 10:07:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
journalctl -a with debug on the kernel cmdline (291.42 KB, text/x-vhdl)
2015-08-03 04:31 EDT, Marcel Kolaja
no flags Details

  None (edit)
Description Marcel Kolaja 2015-08-03 04:31:42 EDT
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):
systemd-208-20.el7_1.5

How reproducible:
always

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

2. reboot

Actual results:
/boot is not mounted.

Expected results:
/boot is mounted.

Additional info:
systemd logs the following message after switching root:

systemd[1]: Unmounting /boot...

journalctl -a with debug on the kernel cmdline attached.
Comment 2 Marcel Kolaja 2015-08-03 04:50:22 EDT
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.
Comment 3 Lukáš Nykrýn 2015-08-03 07:44:50 EDT
(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.
Comment 4 Martin Schuppert 2015-08-04 06:09:58 EDT
Fails with RHEL7.1:
# rpm -qa |grep systemd
systemd-python-208-20.el7_1.5.x86_64
systemd-libs-208-20.el7_1.5.x86_64
systemd-208-20.el7_1.5.x86_64
systemd-sysv-208-20.el7_1.5.x86_64

Works with 7.2 dev release:
# rpm -qa |grep systemd
systemd-python-219-9.el7.x86_64
systemd-sysv-219-9.el7.x86_64
systemd-libs-219-9.el7.x86_64
systemd-219-9.el7.x86_64

# cat /etc/fstab 

#
# /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

after reboot:
# uptime
 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)
Comment 5 Branislav Blaškovič 2015-08-05 04:08:48 EDT
If I understand it properly, it's already fixed, so qa_acking to get this to erratum.
Comment 7 errata-xmlrpc 2015-11-19 10:07:53 EST
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.

https://rhn.redhat.com/errata/RHBA-2015-2092.html

Note You need to log in before you can comment on or make changes to this bug.