Bug 1837787

Summary:	failed upgrade of 'filesystem' in containers
Product:	[Fedora] Fedora	Reporter:	Hany Badawy <support>
Component:	filesystem	Assignee:	Ondrej Vasik <ovasik>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	32	CC:	kxra, ovasik, pknirsch, praiskup
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-23 13:34:38 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 Hany Badawy 2020-05-20 01:50:04 UTC

Description of problem:
filesystem package fails on upgrades on LXC containers running F32 and F31 with possible error referring to /proc.

Version-Release number of selected component (if applicable): filesystem-3.14-2.fc32.x86_64


How reproducible: 
Create a Fedora 31 LXD container using snap then go through the process of upgrading the container to F32.


Steps to Reproduce:
1. lxc launch images:fedora/31/amd64
2. dnf install dnf-plugin-system-upgrade
3. dnf upgrade --refresh
4. dnf system-upgrade download --releasever=32
5. Launch the newly upgraded container and try to upgrade, filesystem package will fail.

Actual results:
filesystem package doesn't upgrade as expected.

Expected results:
filesystem package installation should complete successfully. Installation procedures should determine if this is a container and bypass setting permissions on /proc and /sys sicce they are owned by nobody in default installations.

Additional info:

Comment 1 Hany Badawy 2020-05-26 23:58:22 UTC

I have took a stap at fixing this myself ... Hopefully someone can "polish" this up a bit to include other container platforms not just LXC.

In the SPEC file I did the following ...

In the $build section I added :

%build
%define is_container %( if ! [ $(systemd-detect-virt) == "lxc" ]; then echo "1" ; else echo "0"; fi )

and in the %files section at line 221 where it reads "%attr(555,root,root) /sys" I moved that under line 216 where it reads "%attr(555,root,root) /proc" and called the defined macro to in an %if statement so the end result would be :

%files
......
%dir /mnt
%dir /opt
%if %is_container
%attr(555,root,root) /proc
%attr(555,root,root) /sys
%endif
%attr(550,root,root) /root
/run
......

Then compiled and upgraded using these methods:
rpm -Uvh <Path_to_Compiled_filesystem_RPM>  ----> Success (old Package upgraded and new package installed)
rpm -ivh <Path_to_Compiled_filesystem_RPM>  ----> Success (new package installed alongside old package)
dnf upgrade <Path_to_Compiled_filesystem_RPM>  ----> Success (old Packages upgraded and new package installed)
dnf install <Path_to_Compiled_filesystem_RPM>  ----> Success (old Packages upgraded and new package installed)

Warnings during the upgrade/installation were :
warning: directory /sys: remove failed: Device or resource busy
warning: directory /proc: remove failed: Device or resource busy


Perhaps relying on systemd to determine if container or not is not the preferred approach, perhaps querying rpm DB for "fedora-release-container" Package is better ? Or perhaps a more generic/general approach to checking if container to accommodate the different container platforms is best ?

Comment 2 Ondrej Vasik 2020-06-05 13:40:58 UTC

With this change, you will get /proc and /sys directories in container-compiled filesystem unowned. I'm thiking more about some %ghost macro or some %post lua magic which would ensure directories have expected permissions and ownership. I understand this workaround works, but it just hides the issue with different ownership/permissions of /proc /sys (that are managed by underlying kernel anyway) in containerized systems.

Comment 3 Pavel Raiskup 2020-06-23 13:34:38 UTC

I'm closing this as it duplicates quite an old bug 1548403.

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