*** This bug is a duplicate of bug 1749393 ***
https://bugs.launchpad.net/bugs/1749393
is there any update? ubuntu itself gives me still
qemu-user-static (1:4.2-3ubuntu6.18)
which is reported as broken, but you've said ppas no more needed
and tried it, and crashes again
--
You received th
*** This bug is a duplicate of bug 1749393 ***
https://bugs.launchpad.net/bugs/1749393
Bisect completed.
I deleted the PPAs as they are no more needed.
$ grep -e '^DEBUG' -e '^Com' bisect.log
DEBUG: saved as
'/home/ubuntu/qemu-aarch64-static.bisect.v4.2.0-1511-g381063d778'
DEBUG: latest res
After being set up in the broken way we can run the test more quickly
$ sudo chroot /home/ubuntu/bullseye-arm64 /bin/sh /debootstrap/debootstrap
--second-stage
$ tail -n 1 /home/ubuntu/bullseye-arm64/debootstrap/debootstrap.log
This is repeatable and will as last line contain:
good case:
duplic
To complete the former tests:
fail - 1:4.2-3ubuntu6.19~focalppa2 = lp-1928075-qemu-static-builds-f-plusfix
Which confirms the former thought that it isn't about the binfmt changes
in debian/* but an upstream change.
I'll need some builds for that ...
P.S. somewhere in the back of my mind forms a
Works - 1:5.0-5ubuntu9.10~focalppa2 = lp-1928075-qemu-static-builds-g-
minusfix
Since the debian/* is the same in regard to binfmt this might indicate a
fix in qemu git 4.2 .. 5.0
The other PPA still builds
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
already in 1:4.2-3ubuntu5:
commit 8075687f92b6e177f646a9a7db8cfd63262d033aswitch binfmt registration
to use update-binfmts --[un]import (#866756)
Remaining fixes
commit 2a3a3f66c07e3ccae80115d994c627fe9df19880more binfmt-install updates
commit 9ce886cd819b1f9900b84c55f416977e8f418d27f
Using PPAs:
https://launchpad.net/~paelzer/+archive/ubuntu/lp-1928075-qemu-static-builds-h
https://launchpad.net/~paelzer/+archive/ubuntu/lp-1928075-qemu-static-builds-g
Test results:
works 1:6.0+dfsg-2expubuntu1.1~backport20.04-202111060014~ubuntu20.04.1
works 1:5.2+dfsg-9ubuntu3.3~focalppa1
w
Hi Frank,
I was trying to grasp the exact details that you are describing and giving this
another repro run. You are saying
bullseye armhf chroot @ focal on an x86 host
is failing for you, correct?
Note: We have just fixed a similar (only on the surface of it) issue in
Impish (bug 1947860).
Re
tested bullseye armhf/aarch64 debootstrap on ubuntu 21.10, and both
works, but on 20.4 i can only get 1 working (aarch with ppa and armhf
with ubuntus package), the other crashes. very annoying.
any other backport possible (e.g. installing 21.10 package in 20.4)?
or does this depend on linux kern
In my test,arm64 works with ppa qemu-user-static,but it breaks armhf in
similar manner as arm64 with ubuntu 20.4 version. Seems to affect only
bullseye chroot for me. Buster can be created without problems.
Imho this confirms problem with linkage type of ldconfig (dynamically
vs. Static) like tj m
That is an interesting data point that the newer qemu version from a PPA seems
to resolve it.
TJ, can you confirm this is true for you as well?
Randy, do you have any insights on which fix from the newer qemu might
be worth looking at for SRU?
** Changed in: qemu (Ubuntu Focal)
Status: Ne
[Groovy is past its end of support period]
** Changed in: qemu (Ubuntu Groovy)
Status: Incomplete => Won't Fix
** Changed in: qemu (Ubuntu Focal)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I was able to solve this on Ubuntu 20.04 by moving to latest qemu 5 using
```
sudo add-apt-repository ppa:jacob/virtualisation (for Ubuntu 20.04)
sudo apt-get update && sudo apt-get install qemu qemu-user qemu-user-static
```
--
You received this bug notification because you are a member of Ubun
Thanks TJ!
I agree to "I am extremely confused" - /e as well :-)
I mean I'm glad it was resolved by kernel upgrades, but there isn't much
attack surface left to solve anything on the distro-packaging level.
Let me know if you find the underlying root cause so we can have a look
at it.
--
You r
We've installed 5.12.0 on Callum's PC and the latest qemu-user-static
(5.2+dfsg-9ubuntu3) from 21.04 and so far it also appears to be working.
We're not sure what has been happening but we'll chalk this one down to
user-error for now unless it re-occurs!
--
You received this bug notification beca
Before I forget and in case others find it useful I wrote a simple
Python tool to check binfmt magic bytes registered with the kernel with
particular files.
It can be found here:
https://iam.tj/projects/misc/binfmt-check
--
You received this bug notification because you are a member of Ubuntu
B
Testing by trying to execute /sbin/ldconfig within the aarch64 Debian
bullseye chroot on 20.04 amd64 host for all installed kernels is
working, including 5.12.0, the version booted to by default !
That is: 5.4.0-73-lowlatency 5.8.0-41-lowlatency 5.10.2 5.11.0+
5.12.0-elloe+
This is extremely diff
All tests using chroot's on my host are with kernel v5.12.0 with the
ubuntu kernel .config as base + 'make olddefconfig'.
I'll try the standard Ubuntu 20.04 kernel, and HWE, just in case.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
...
> And with that installation runs to completion. This is inside a 21.04
> amd64 desktop KVM virtual machine.
#1 The 21.04 environment fully works
#2 The 20.04 environment fails
#3 The qemu-of-21.04 in 20.04 environment fails
I'm not sure, but this makes me think of the kernel maybe bein
I stepped back to the chroot and tried qemu-aarch64-static from 21.04's
qemu-user-static (5.2+dfsg-9ubuntu2) but *debootstrap* fails in the same
way as previously reported.
HOWEVER, this works:
$ sudo chroot bullseye-arm64 /usr/bin/qemu-aarch64-static /sbin/ldconfig -v
/sbin/ldconfig: Can't stat
Ok, that was an easy solve:
$ sudo chown 0:0 bullseye-arm64
And with that installation runs to completion. This is inside a 21.04
amd64 desktop KVM virtual machine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
In a 21.04 amd64 desktop virtual machine it fails but with a different
error apparently related to bullseye systemd package, not sure if I can
untangle this mix of problems:
$ sudo apt install qemu-user-static debootstrap
$ sudo qemu-debootstrap --arch=arm64 bullseye bullseye-arm64/
http://ftp.d
First simple test with 21.04 amd64 LXD host with kernel 5.12.0 results
in the same issue.
I'll need to repeat in a virtual machine next.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928075
Title:
Another data point.
We tried installing qemu-aarch64-static from Debian's qemu-user-static
amd64 packages from testing (1:5.2+dfsg-10) (bullseye) and experimental
(6.0+dfsg-1~exp0) into the chroot. Both result in the same error.
On my PC I have kernel 5.12.0-elloe+ and Callum has 5.10.0. We both
Looking closer we've just noticed the bullseye's ldconfig claims to be
dynamically linked but buster's is statically linked.
This reminds of bug #1908331 we solved earlier this year in qemu itself
due to the build flag -static-pie
$ file bullseye-arm64/sbin/ldconfig
bullseye-arm64/sbin/ldconfig:
Will do - I run builds of the mainline kernel tracking upstream so that
part isn't a problem. We are operating on bare-metal on the host.
I suspect it is glibc and/or compilation options since trying to
manually call, for example, /bin/dash or other executables hits the same
issue.
--
You receiv
I've seen similar issues due to e.g. a newer glibc (could be any other
program or even guest kernel) to use newer instructions and thereby
trigger an issue that exists in the emulation.
This usually ends in the need to bisect the host to identify a
(hopefully already existing) fix and then conside
27 matches
Mail list logo
