Bug 807278

Summary:	Revert workaround which manually mounts fstab entries.
Product:	[Retired] oVirt	Reporter:	Fabian Deutsch <fdeutsch>
Component:	ovirt-node	Assignee:	Fabian Deutsch <fdeutsch>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, jboggs, mburns, ovirt-bugs, ovirt-maint, ramon.rnm
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:	2013-11-28 13:38:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	807203
Bug Blocks:

Description Fabian Deutsch 2012-03-27 12:20:53 UTC

This is a reminder to revert the hack, introduced with 
http://gerrit.ovirt.org/#change,3117
to solve bug #806349

Comment 1 Mike Burns 2013-02-05 14:12:18 UTC

Defer to 2.7.0 -- dependent bug not fixed

Comment 2 Ramon Medeiros 2013-09-03 15:49:17 UTC

The system mounts the fstab entries at rc.sysinit, but, at this time, the root partitions is not mounted. Which way we can use to mount fstab entries without this workaround? Maybe run ovirt service before the rc.sysinit? Is it possible?

Comment 3 Fabian Deutsch 2013-09-03 15:59:39 UTC

(In reply to Ramon Medeiros from comment #2)
> The system mounts the fstab entries at rc.sysinit, but, at this time, the
> root partitions is not mounted. Which way we can use to mount fstab entries
> without this workaround? Maybe run ovirt service before the rc.sysinit? Is
> it possible?

On Fedora it's systemd which is handling the mounts.
And I wonder if we can ever solve this.
What I can imagine is that - once union mounts landed - systemd can detect if there is a modified fstab in a layered mount an will re run the mount process as soon as the new fstab appears.

Comment 4 Fabian Deutsch 2013-11-28 13:38:21 UTC

Closing this for now as this is not solvable right now.