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.)
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
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.
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.
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.
*** This bug has been marked as a duplicate of bug 1306452 ***