Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1837787 - failed upgrade of 'filesystem' in containers
Summary: failed upgrade of 'filesystem' in containers
Keywords:
Status: CLOSED DUPLICATE of bug 1548403
Alias: None
Product: Fedora
Classification: Fedora
Component: filesystem
Version: 32
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-20 01:50 UTC by Hany Badawy
Modified: 2020-06-23 13:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-23 13:34:38 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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 ***
Note You need to log in before you can comment on or make changes to this bug.