Bug 665437

Summary:	yast removes /etc/mtab during installation
Product:	[openSUSE] openSUSE 11.4	Reporter:	Stephan Kulow <coolo>
Component:	Installation	Assignee:	Lukas Ocilka <locilka>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Critical
Priority:	P5 - None	CC:	bwiedemann, jsrain
Version:	Factory	Flags:	coolo: SHIP_STOPPER+
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Stephan Kulow 2011-01-19 09:13:46 UTC

/etc/mtab is now a symlink to /proc and touching it at all should be forbidden in factory. Please add code to handle it - there is a 30% chance we will revert back to a file, so leave it untouched if it's a symlink.

From my greping this is mostly about clients/umount_finish.ycp, but there is also code in inst_kickoff, but I'm not so sure how relevant it is for the bug we see (non existant mtab after boot)

Comment 1 Jiri Srain 2011-01-19 14:44:06 UTC

I have added checking to umount_finish.ycp, in case it is a symling, it is not removed.

reated request id 58756

There are, however, two questions which need to be answered:

- who (and when) creates the symlink at all?

- mtab created by inst_kickoff is a fake - because packages are run in chroot environment; will real post-install scripts handle it correctly if it is not the fake, but real mtab? That's what comment to the code refers to. (well, we will not find out until we try)

Comment 2 Bernhard Wiedemann 2011-01-19 17:56:39 UTC

1. currently, util-linux creates this symlink in its %post script
   but maybe bug 665494 will change that

2. maybe the fake mtab was just there to make things working that would not work without mtab. So there is a good chance, they will just work with the symlink.

Will test on openqa and maybe even re-install one of my laptops with it.

Comment 3 Jiri Srain 2011-01-20 08:53:28 UTC

OK, then:

1. Just make sure that util-linux overwrites the file in case it exists (I assume that this is already done)

2. What I'm worried about is that there will be problem with the symlink having different data than the fake, which may make some packages fail. On the other hand, then it is a bug of the package itself and should be fixed there.

Therefore I suggest testing next build and if it works fine, let's keep the status as it is now (resp. will be once my SR is approved)

Comment 4 Stephan Kulow 2011-01-20 09:26:33 UTC

so let's pretend, happy end