Bug 26044

Summary: filesystem package fails to install when building chroot
Product: Mageia Reporter: Neal Gompa <ngompa13>
Component: RPM PackagesAssignee: All Packagers <pkg-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: Normal CC: thierry.vignaud
Version: 7   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: filesystem-2.1.9-30.mga7.src.rpm CVE:
Status comment:
Attachments: Example image build run log
Diff of changes to fix filesystem package

Description Neal Gompa 2020-01-09 19:29:10 CET 
Description of problem:
The filesystem package fails to install with the following errors when trying to build a chroot.

Error unpacking rpm package filesystem-2.1.9-30.mga7.armv7hl

  Installing       : grep-3.3-1.mga7.armv7hl                             23/184
error: unpacking of archive failed on file /bin: cpio: File from package already exists as a directory in system
error: filesystem-2.1.9-30.mga7.armv7hl: install failed

It seems like the symlink for /bin -> /usr/bin isn't getting created correctly.

At a glance, I think there's a bug in the %pretrans scriptlet.


Version-Release number of selected component (if applicable):
2.1.9-30.mga7

How reproducible:
Always

Steps to Reproduce:
1. git clone https://git.labolyon.fr/DTux/mageia4arm
2. cd mageia4arm
3. ./create_arm_image.sh --all --size 2 --tainted --nonfree --config bananaPro 2>&1 | tee ./creation.log

This can be reproduced on any distribution with DNF (Fedora, Mageia, OpenMandriva).
Comment 1 Neal Gompa 2020-01-09 19:31:50 CET 
Created attachment 11449 [details]
Example image build run log

I've attached a log of the run of the image creation script...
Comment 2 Lewis Smith 2020-01-09 22:06:14 CET 
Note this is ARM. But exclusively? 

I have seen this error before - ah, found it: bug 25320.
See especially https://bugs.mageia.org/show_bug.cgi?id=25320#c20
Not saying it is the same thing.

No registered maintainer for 'filesystem', so assigning this globally.

Assignee: bugsquad => pkg-bugs

Comment 3 Neal Gompa 2020-01-10 03:37:43 CET 
I've seen it on other architectures too, but I can reliably make it happen repeatedly with this ARM image build process.

You can do this on an x86_64 system by doing two steps beforehand:

1. dnf install qemu-user-static
2. systemctl restart systemd-binfmt.service

After that, the ARM image builder will work on x86_64 hosts.
Comment 4 David Walser 2020-01-10 18:51:12 CET 
It looks like the lua pretrans in filesystem doesn't take into account that /bin, /sbin, /lib, and /lib64 could already exist.  It should check for that and if they exist, move their contents under /usr.
Comment 5 Neal Gompa 2020-01-11 21:41:34 CET 
Created attachment 11452 [details]
Diff of changes to fix filesystem package

(In reply to David Walser from comment #4)
> It looks like the lua pretrans in filesystem doesn't take into account that
> /bin, /sbin, /lib, and /lib64 could already exist.  It should check for that
> and if they exist, move their contents under /usr.

That might be one way to solve it, though my ability to write Lua to solve it that way is a bit weak...

However, it might not be necessary, since we've had UsrMove in place since Mageia 3.

I looked at the history of the scriptlet in filesystem, and it looks like it came straight from Fedora from this commit: https://src.fedoraproject.org/rpms/filesystem/c/4dd7fd5d27c96abd3fe51f64ba7b7d5df8e1d898

It appears that the scriptlet was reworked a year later in this commit: https://src.fedoraproject.org/rpms/filesystem/c/5a403cd70564264b9bb7a5e2b3f1a6351c2f4ad8

I made the same change to our filesystem package locally (diff attached) and was able to get a functioning image build reliably.

If this is acceptable, I can commit this into Cauldron and also backport it to Mageia 7's filesystem package.
Comment 6 Thierry Vignaud 2020-11-23 13:46:52 CET 
This one was fixed months ago

Resolution: (none) => FIXED
CC: (none) => thierry.vignaud
Status: NEW => RESOLVED