Bug #2648
libremakepkg failing on i686 with Operation not permitted on '/tmp/*/db/sync/*.db
0%
History
Updated by GNUtoo about 3 years ago
I can't reproduce anymore because of some other bug but Megver83 pastebined the log on IRC which I added below.
==> Starting to build the package... | ==> Cleaning chroot... | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/libre.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/core.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/extra.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/community.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/pcr.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync/repo.db': Operation not permitted | cp: preserving times for '/tmp/chcleanup.UN9SLawrs1/db/sync': Operation not permitted ==> ERROR: Failure(s) in pre_build: clean_chroot ==> Copying log and package files out of the chroot...I did some tests:
- If the host (your laptop, an kvm vm etc) runs parabola i686, you could produce a chroot that works fine with the usual commands (libremakepkg -A i686 -n parabola-i686) and build packages this way.
If the host runs an i686 rootfs,
Updated by GNUtoo about 3 years ago
At the time of the test I did, both i686 and x86_64 had the same systemd version and systemd-nspawn comes from systemd
Updated by GNUtoo about 3 years ago
Both also had and still have the same libretools and librelibs version (20181004-6.1)
Updated by Megver83 about 3 years ago
This issue happened in beefcake, but I didn't know it was due to systemd-nspawn (I use OpenRC). Just installed the [nonsystemd] version, which uses chroot-nspawn, and it worked (I did 'pacman -U https://www.parabola.nu/packages/nonsystemd/x86_64/libretools/download/`)
Updated by Megver83 about 3 years ago
A temporary solution could be adding an option in libretools so the user can configure it to use systemd-nspawn or chroot-nspawn, in this way systemd users/devs would not need to install it from [nonsystemd] or use makechrootpkg from Arch's devtools
Updated by bill-auger about 3 years ago
- Status changed from unconfirmed to confirmed
- Project changed from Packages to libretools
there is a similar problem on beefcake that is not peculiar to i686 - building a package, or any chroot operation, in an x86_64 chroot leaves /tmp re-mounted read-only, making any further operations fail - after rebooting, /tmp will be writable, but only until some librechroot or libremakepkg operation completes, then it will be read-only, again - whatever is happening, is actually before libremakepkg completes fully; because the final clean-up step fails, while trying to clean-up /tmp
Updated by GNUtoo almost 3 years ago
- Status changed from confirmed to info needed
Is that bug still valid? or do we need to close it?
Updated by bill-auger almost 3 years ago
im not sure - the /tmp dir is still troublesome on beefcake -
often a build will fail because at some point during the build,
the /tmp dir becomes re-mounted read-only, and needs to be
re-mounted manually before re-trying
Updated by bill-auger over 2 years ago
ive discovered that `umount /tmp` fixes the problem without rebooting