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: 2022-09-06 01:20 UTC (History)
4 users (show)

Fixed In Version:
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.