Bug 1098611

Summary:	/var to mount over is not empty
Product:	[Fedora] Fedora	Reporter:	Chris Murphy <bugzilla>
Component:	initscripts	Assignee:	Lukáš Nykrýn <lnykryn>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	aschorr, bugzilla-redhat, dwinter_nospam, gary.buhrmaster, harald, jonathan, lnykryn, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-19 11:31:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Murphy 2014-05-16 16:43:40 UTC

Description of problem: On each boot, even when the underlying /var on rootfs is empty, the journal contains the message systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. Turns out 


Version-Release number of selected component (if applicable):
initscripts-9.54-2.fc21.x86_64
However this also affects Fedora 20 without updates, so the problem goes back to at least Fedora 20.

How reproducible:
Always if a separate var volume is mounted at /var

Steps to Reproduce:
1. Separate var mounting at /var
2. Boot and check the journal.


Additional info:

By setting xattr +i on the rootfs /var/lib I get the following in the journal:

[   14.653169] rawhide.localdomain fedora-import-state[277]: cp: cannot create directory ‘/./var/lib/dhclient’: Permission denied
[   14.653474] rawhide.localdomain fedora-import-state[277]: cp: preserving times for ‘/./var/lib’: Operation not permitted


#  rpm -q --whatprovides /lib/systemd/fedora-import-state
initscripts-9.54-2.fc21.x86_64

# cat /usr/lib/systemd/system/fedora-import-state.service
[Unit]
Description=Import network configuration from initramfs
DefaultDependencies=no
ConditionPathIsReadWrite=/
ConditionDirectoryNotEmpty=/run/initramfs/state
Conflicts=shutdown.target
Before=shutdown.target emergency.service emergency.target systemd-tmpfiles-setup.service
After=systemd-remount-fs.service

[Service]
ExecStart=/lib/systemd/fedora-import-state
Type=oneshot
TimeoutSec=0
RemainAfterExit=yes

Comment 1 Lennart Poettering 2014-05-16 17:44:54 UTC

I figure the service should use After=local-fs.target and Before=basic.target or so, to make sure /var is mounted.

But honestyl, do we still need this? Why copy this stuff? Can't the tools in question just read their stuff directly from /run? Why does this even write to /var? Sounds really wrong...

Comment 2 Lukáš Nykrýn 2014-05-17 17:58:16 UTC

> But honestyl, do we still need this? Why copy this stuff? Can't the tools in
> question just read their stuff directly from /run? Why does this even write
> to /var? Sounds really wrong...

For example there could be ifcfg files.

Harald, what do you think?

Comment 3 Lennart Poettering 2014-05-20 15:40:13 UTC

Lukas, why would there be ifcfg files that wouldn't be in the host fs anyway? Or ifcfg files that initscripts couldn't rebuild from /proc/cmdline on its own?

Comment 4 Lukáš Nykrýn 2014-05-21 08:57:37 UTC

Simply we use that to pass network state from dracut to real system (ifcfgs and lease files). Sure that could be done in other way. Initscripts, NM, dhclient could read those files directly from /run/initramfs/. But I am not sure if it is worthy to do such changes, at least until we get networkd to dracut.

Also there could be users that are using this feature for other purposes.

Comment 5 Jaroslav Reznik 2015-03-03 15:49:04 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 6 Fedora End Of Life 2016-07-19 11:31:58 UTC

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.