Bug 1690368

Summary:	anaconda leaves files on the root fs in /tmp after installation
Product:	[Fedora] Fedora	Reporter:	Zbigniew Jędrzejewski-Szmek <zbyszek>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	31	CC:	anaconda-maint-list, jkonecny, jonathan, kellin, vanmeeuwen+fedora, vponcova, wwoods, y9t7sypezp
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-26 09:43:24 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 Zbigniew Jędrzejewski-Szmek 2019-03-19 10:48:55 UTC

Description of problem:
After installing from Fedora-Workstation-Live-x86_64-30-2019316.n.1.iso,
I get a warning after reboot:
Mar 19 11:31:57 workstation2 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Mar 19 11:31:57 workstation2 systemd[1]: Mounting Temporary Directory (/tmp)...
Mar 19 11:31:57 workstation2 systemd[1]: Mounted Temporary Directory (/tmp).

$ sudo mount --bind / /tmp/bind -o x-mount.mkdir
$ find /tmp/bind/tmp/
/tmp/bind/tmp/
/tmp/bind/tmp/.local
/tmp/bind/tmp/.local/share
/tmp/bind/tmp/.local/share/ibus-typing-booster
/tmp/bind/tmp/.local/share/ibus-typing-booster/data
/tmp/bind/tmp/ks-script-7pn2ydnk
/tmp/bind/tmp/ks-script-vcd2xle9
/tmp/bind/tmp/ks-script-rjzl0gme
/tmp/bind/tmp/.cache
find: ‘/tmp/bind/tmp/.cache’: Permission denied
/tmp/bind/tmp/ks-script-2yqsxxz2
/tmp/bind/tmp/hsperfdata_root
/tmp/bind/tmp/hsperfdata_root/785

I looks like part of the installation was running without a tmpfs mounted on tmp in the installation root.

This doesn't generate big problems, but users will get a warning on every boot, and for most people it'll be pretty confusing.

Version-Release number of selected component (if applicable):
anaconda-30.25.3-3.fc30.x86_64 (in the installed system, not sure it the same one was on the installation image.)

Comment 1 Ben Cotton 2019-08-13 19:30:51 UTC

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

Comment 2 Steve 2020-03-25 17:18:24 UTC

Still present with Fedora-Workstation-Live-x86_64-32_Beta-1.2.iso.

# rpm -q anaconda
anaconda-32.24.2-3.fc32.x86_64

From the installed system:

$ journalctl -b --no-hostname | grep 'tmp.mount'
Mar 25 09:57:31 systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.

Reboot from the Live image and mount the root partition somewhere convenient:

# mount | grep vda3
/dev/vda3 on /mnt/foo type ext4 (ro,relatime,seclabel)

# ls -l /mnt/foo/tmp/
total 4
-rwx------. 1 root root 1379 Mar 24 01:17 ks-script-fs0xonzf

Tested in a VM.

Comment 3 Jiri Konecny 2020-03-26 08:25:45 UTC

Hmm interesting.


I knew about this issue in netinst but in the Live media it's different story. I wonder when this files are getting in. If it is in the stage 2 image during build or during the boot-up process. So or so, it is not an Anaconda issue in the Live media. We don't have any specific initrd scripts in Live which could cause this.

Comment 4 Jiri Konecny 2020-03-26 08:41:38 UTC

So yes, this is already part of the stage 2 image of Live Media. It is also in the every installed system from netinst installation. Reason why this is in stage2 image created by LiveMedia-Creator is because the image build process is using Anaconda to install the system.

We should extend our cleanup scripts from the /tmp in the chroot environment. That should solve both problems.

Comment 5 Jiri Konecny 2020-03-26 09:43:24 UTC


*** This bug has been marked as a duplicate of bug 1306452 ***