Bug #1938
Unable to create a librechroot for armv7h in latest (20180804-2) libretools and other issues
0%
Description
Followed all the steps on the wiki several times over
Only step on the wiki That I was unable to reproduce was starting the systemd-binfmt.service (says it doesnt exist)
Yet:
/usr/lib/systemd/systemd-binfmt exists so where is the .service file
and /usr/lib/systemd/system/sysinit.target.wants/systemd-binfmt.service so that should mean a running binfmt correct?
and all the qemu static bits are in /proc/sys/fs/binfmt_misc/
Have imported and done lsigning for The archlinuxarm keyring
x86_64 and i686 chroots work nicely
I did a fresh install of my system today to get back to a pure systemd system and make sure there were not any remaining systemd/operc conflicts
I've spent the whole day on this and can not figure out what the underlying issue is. Had armv7h working nicely under previous libretools/openrc.
Files
History
Updated by freemor over 5 years ago
- Subject changed from Unable to create a librechroot for armv7h in latest (20180804-2) libretools to Unable to create a librechroot for armv7h in latest (20180804-2) libretools and other issues
Expanding this to cover other issues.
most recent one:
( 9/11) Arming ConditionNeedsUpdate... (10/11) Updating the info directory file... (11/11) Rebuilding certificate stores... Failed to attach 16345 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory Failed to attach 14180 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/supervisor: No such file or directory Failed to chown() cgroup /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory
when trying to make a standard x86_64 chroot
Other Observed weirdness:
Build in default x86_64 chroot -> fine -> saves X86_64.pkg.
Build again in i686 chroot -> builds fine -> saves to x86_64.pkg erasing the properly made one with a 32bit binary in a x86_64 package
I'll see if a reboot clears the cgroup errors and report back
Rebooting did indeed clear the cgroup issue.
Did a build with the only existing librechroot being one created with:
sudo librechroot -A i686 -M /etc/makepkg.conf -n i686 make
and it ended with:
==> Starting post-build activities... | ==> Extracting database to a temporary location... | ==> Adding package 'hexchat-1:2.14.1-5.parabola1-x86_64.pkg.tar.xz' | -> Computing checksums... | -> Creating 'desc' db entry... | -> Creating 'files' db entry... | ==> Creating updated database file 'repo.db.tar.gz' | ==> Extracting database to a temporary location... | ==> Extracting database to a temporary location... | ==> Adding package 'hexchat-debug-1:2.14.1-5.parabola1-x86_64.pkg.tar.xz' | -> Computing checksums... | -> Creating 'desc' db entry... | -> Creating 'files' db entry... | ==> Creating updated database file 'repo.db.tar.gz' ==> Copying log and package files out of the chroot...
scp'ing the above: hexchat-1:2.14.1-5.parabola1-x86_64.pkg.tar.xz over to my i686 machine and installing with:
pacman --arch x86_64 -U hexchat-1:2.14.1-5.parabola1-x86_64.pkg.tar.xz
Results in a working install of 32bit binaries. So binaries are indeed cross compiled just identified incorrectly.
Updated by lukeshu over 5 years ago
I think the ARM chroot Failure.txt is fine--I think it exited with 0 and created a functioning chroot. I think it's just a variant of https://bugs.archlinux.org/task/49347 . Have you verified that the chroot it makes is non-functioning?
Is this:
Failed to attach 16345 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory Failed to attach 14180 to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/supervisor: No such file or directory Failed to chown() cgroup /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory
with systemd or notsystemd?
Updated by lukeshu over 5 years ago
sudo librechroot -A i686 -M /etc/makepkg.conf -n i686 make
I assume that your /etc/makepkg.conf says CARCH=x86_64, which overrides the -A i686, at least as far as the inner makepkg is concerned.
I should probably make it an error to set -M or -C twice (-A sets -M and -C internally).
Updated by freemor over 5 years ago
Cgroup stuff is with systemd. As noted way way up at the top I'm on a clean systemd install.
You are correct about the CARCH=x86_64 in the makepkg.conf. It the same makepkg.conf that I was using before without issue. Should I comment the out or make separate makepkg.conf's for each ARCH?
I'm pretty sure that the armv7h chroot dies miserably if I try to build in it. I'll double check and post the results.
Updated by lukeshu over 5 years ago
You should make a separate makepkg.conf for each arch. Why are the /usr/share/pacman/defaults/makepkg.conf.* files not satisfactory? (they are what -A use)
Updated by freemor over 5 years ago
Looks like you may have spotted the entire cause of the weirdness with the -A vs CARCH issue.
I made a makepkg.conf with CARCH commented out and tried to create a chroot with:
sudo librechroot -A armv7h -M makepkg_noArch.conf -n arm make
It instantly bitched about no CARCH being set (Is -A being totally ignored?)
Then I made the makepkg.conf with an armv7h CARCH and everything is going smooth as silk.
Will try the same with i686 but an expecting good things.
Updated by lukeshu over 5 years ago
$ librechroot help
…
The `-A CARCH` flag is *almost* simply an alias for
-C "/usr/share/pacman/defaults/pacman.conf.$CARCH" \
-M "/usr/share/pacman/defaults/makepkg.conf.$CARCH"
However, before doing that, it actually makes a temporary copy of
`pacman.conf`, and sets the `Architecture` line to match the `CARCH`
line in `makepkg.conf`.
…
If you set -M after -A, it totally ignores -A with regard to makepkg.conf.
Put another way, with regard to makepkg.conf, -A i686 is exactly -M /usr/share/pacman/defaults/makepkg.conf.i686, so -A i686 -M /etc/makepkg.conf is exactly -M /usr/share/pacman/defaults/makepkg.conf.i686 -M /etc/makepkg.conf, and the latter -M takes precedence, so it's just -M /etc/makepkg.conf.
Now, I said "with regard to makepkg.conf. The -A i686 will still effectively set -C <(sed -r "s|^#?\\s*Architecture.+|Architecture = i686|g" < /usr/share/pacman/defaults/pacman.conf.i686) (in real use -C would not correctly handle being passed a pipe instead of a plain file, but it gets the point across here).
Updated by lukeshu over 5 years ago
- Status changed from open to not-a-bug
I think everything works?
Closing, reopen if I'm wrong.