Bug#1069844: More debug info
On Fri, 26 Apr 2024 at 16:48, Julian Andres Klode <
julian.kl...@canonical.com> wrote:
> On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> > Alex Bennée writes:
> >
> > > Julian Andres Klode writes:
> > >
> > >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> > >>>
> > >>> Continuing to debug on QEMU it seems there is an incompatibility with
> > >>> the images and the peloader (which overrides the normal efi loader):
> > >>>
> >
> > >
> > >> In the error case you can see though, that one of the section
> > >> addresses in the Xen binary to be relocated points into the (PE)
> > >> header of the binary, which obviously seems wrong.
> > >>
> > >> So go check your PE sections and check which one is wrong?
> > >
> > > Is there any tooling for examining PE sections?
> >
> > Nothing really jumps out from objdump:
> >
> > 1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen
> >
> > /boot/xen: file format pei-aarch64-little
> >
> > Sections:
> > Idx Name Size VMA LMA File
> off Algn
> > 0 .reloc
> 2**0
> > ALLOC, LOAD, READONLY, DATA
>
>
> This looks suspicious. Yes it's 0 size but it's address is 0 which
> clearly points into the header, and we don't skip 0 size sections when
> loading the PE binary for later relocation, and we don't use any .reloc
> section.
>
It does get skipped in the reloc code:
if (!info->reloc || !(info->reloc->size))
{
grub_dprintf ("linux", "no relocations\n");
return GRUB_EFI_SUCCESS;
}
Although the x86_64 build of Xen uses reloc sections (which Xen itself
deals with) we don't actually need them for Arm. However the way the PE
binary is built is a little funky:
make
UPD include/xen/compile.h
Xen 4.19-unstable
make[1]: Nothing to be done for 'include'.
make[1]: 'arch/arm/include/asm/asm-offsets.h' is up to date.
CC common/version.o
LD common/built_in.o
CC arch/arm/acpi/domain_build.o
INIT_O arch/arm/acpi/domain_build.init.o
LD arch/arm/acpi/built_in.o
CC arch/arm/domain_build.o
INIT_O arch/arm/domain_build.init.o
CC arch/arm/efi/boot.o
INIT_O arch/arm/efi/boot.init.o
LD arch/arm/efi/built_in.o
CC arch/arm/setup.o
LD arch/arm/built_in.o
LD prelink.o
ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \
./common/symbols-dummy.o -o ./.xen-syms.0
nm -pa --format=sysv ./.xen-syms.0 \
| ./tools/symbols --sysv --sort \
> ./.xen-syms.0.S
make -f ./Rules.mk obj=. ./.xen-syms.0.o
CC .xen-syms.0.o
ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o \
./.xen-syms.0.o -o ./.xen-syms.1
nm -pa --format=sysv ./.xen-syms.1 \
| ./tools/symbols --sysv --sort \
> ./.xen-syms.1.S
make -f ./Rules.mk obj=. ./.xen-syms.1.o
CC .xen-syms.1.o
ld-EL --no-warn-rwx-segments --fix-cortex-a53-843419 -T
arch/arm/xen.lds -N prelink.o --build-id=sha1 \
./.xen-syms.1.o -o xen-syms
nm -pa --format=sysv xen-syms \
| ./tools/symbols --all-symbols --xensyms --sysv --sort \
> xen-syms.map
rm -f ./.xen-syms.[0-9]*
objcopy -O binary -S xen-syms xen
ln -sf xen xen.efi
I can't work out how to build without the reloc section and trying to
remove the .reloc section after the fact results in something where the
file-offset is ahead of the VMA position:
➜ objcopy --remove-section=.reloc -O binary -S xen-syms xen-test
17:03:23 alex@gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objdump -h xen-test
xen-test: file format pei-aarch64-little
Sections:
Idx Name Size VMA LMA File off
Algn
0 .reloc
2**0
ALLOC, LOAD, READONLY, DATA
1 .text 00127ea8 0160 0160 0160
2**4
CONTENTS, ALLOC, LOAD, CODE
17:03:25 alex@gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objcopy --remove-section=.reloc xen-test
17:03:37 alex@gwenyn:xen.git/xen on testing/new-attempt:new-attempt
[!?]
➜ objdump -h xen-test
xen-test: file format pei-aarch64-little
Sections:
Idx Name Size VMA LMA File off
Algn
0 .text 00127ea8 0160 0160 01b0
2**2
CONTENTS, ALLOC, LOAD, CODE
>
> > 1 .text 0
Bug#1069844: More debug info
Alex Bennée writes: > Julian Andres Klode writes: > >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote: >>> >>> Continuing to debug on QEMU it seems there is an incompatibility with >>> the images and the peloader (which overrides the normal efi loader): >>> > >> In the error case you can see though, that one of the section >> addresses in the Xen binary to be relocated points into the (PE) >> header of the binary, which obviously seems wrong. >> >> So go check your PE sections and check which one is wrong? > > Is there any tooling for examining PE sections? Nothing really jumps out from objdump: 1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen /boot/xen: file format pei-aarch64-little Sections: Idx Name Size VMA LMA File off Algn 0 .reloc 2**0 ALLOC, LOAD, READONLY, DATA 1 .text 00107ea8 0160 0160 0160 2**4 CONTENTS, ALLOC, LOAD, CODE 21:08:53 [root@debian-arm64:~] # objdump -h /boot/vmlinuz /boot/vmlinuz: file format pei-aarch64-little Sections: Idx Name Size VMA LMA File off Algn 0 .text 018c 0001 0001 0001 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0090a200 018d 018d 018d 2**2 CONTENTS, ALLOC, LOAD, DATA -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#1069844: More debug info
Julian Andres Klode writes: > On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote: >> >> Continuing to debug on QEMU it seems there is an incompatibility with >> the images and the peloader (which overrides the normal efi loader): >> >> Thread 1 hit Breakpoint 3.2, grub_load_normal_mode () at >> ../../../grub-core/kern/main.c:241 >> 241 in ../../../grub-core/kern/main.c >> >> >> (grub gdb) hbreak do_load_image >> >> >> Hardware assisted breakpoint 4 at 0x23bdf0e00: do_load_image. (2 >> locations) >> >> (grub gdb) c >> >> >> Continuing. >> >> >> add symbol table from file "bli.module" at >> >> >> .text_addr = 0x23ba772e0 >> >> >> .bss_addr = 0x0 >> >> >> .module_license_addr = 0x23ba7764a >> .data_addr = 0x0 >> >> >> .rodata.str1.1_addr = 0x23ba77560 >> >> >> .rodata_addr = 0x23ba77550 >> >> >> add symbol table from file "xen_boot.module" at >> >> >> .text_addr = 0x23bcef3c0 >> >> >> .bss_addr = 0x23bcf0370 >> >> >> .module_license_addr = 0x23bcf035e >> >> .data_addr = 0x0 >> >> .rodata.str1.1_addr = 0x23bcefff8 >> >> Thread 1 hit Breakpoint 4.1, do_load_image (boot_policy=0 '\000', >> parent_image_handle=0x23e889f18, file_path=0x237d1bce0, >> source_buffer=0x239f0, source_size=1081352, >> image_handle=0x4766c498) at ../../../grub-core/loader/efi/peimage.c:745 >> warning: 745../../../grub-core/loader/efi/peimage.c: No such file or >> directory >> (grub gdb) hbreak grub_error >> Hardware assisted breakpoint 5 at 0x6db0: grub_error. (2 locations) >> (grub gdb) c >> Continuing. >> >> Thread 1 hit Breakpoint 4.2, 0x00023bdf0e4c in do_load_image >> (boot_policy=, parent_image_handle=, >> image_handle=, >> source_size=, source_buffer=, >> file_path=) at ../../../grub-core/loader/efi/peimage.c:751 >> 751 in ../../../grub-core/loader/efi/peimage.c >> (grub gdb) c >> Continuing. >> >> Thread 1 hit Breakpoint 5.2, grub_error (n=GRUB_ERR_BAD_OS, >> fmt=0x23bdf1703 "section inside header") at ../../../grub-core/kern/err.c:41 >> warning: 41 ../../../grub-core/kern/err.c: No such file or directory >> (grub gdb) bt >> #0 grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 "section inside >> header") at ../../../grub-core/k
Bug#1069844: More debug info
y=0x23bd17660, auto_boot=auto_boot@entry=0) at ../../../grub-core/normal/menu.c:306 #7 0x00023bf41e2c in show_menu (autobooted=, nested=, menu=) at ../../../grub-core/normal/menu.c:925 #8 grub_show_menu (menu=menu@entry=0x23bd1a940, nested=nested@entry=1, autoboot=autoboot@entry=0) at ../../../grub-core/normal/menu.c:940 #9 0x00023bf408a8 in grub_normal_execute (config=, nested=nested@entry=1, batch=batch@entry=0) at ../../../grub-core/normal/main.c:291 #10 0x00023bf32260 in grub_cmd_source (cmd=, argc=1, args=0x23bd1fcc8) at ../../../grub-core/commands/configfile.c:48 #11 grub_cmd_source (cmd=, argc=, args=0x23bd1fcc8) at ../../../grub-core/commands/configfile.c:30 #12 0x00023bf48d0c in grub_script_execute_cmdline (cmd=) at ../../../grub-core/script/execute.c:1034 #13 0x00023bf478c0 in grub_script_execute_cmd (cmd=cmd@entry=0x23bd190c8) at ../../../grub-core/script/execute.c:819 #14 0x00023bf4874c in grub_script_execute_cmdlist (list=) at ../../../grub-core/script/execute.c:1079 #15 0x00023bf478c0 in grub_script_execute_cmd (cmd=) at ../../../grub-core/script/execute.c:819 #16 0x00023bf489b4 in grub_script_execute (script=) at ../../../grub-core/script/execute.c:1191 #17 0x00023bf497fc in grub_normal_parse_line (line=line@entry=0x23bd20060 "configfile $prefix/grub.cfg", getline=getline@entry=0x23bf40430 , getline_data=getline_data@entry=0x23bd20380) at ../../../grub-core/script/main.c:36 #18 0x00023bf409a0 in read_config_file (config=0x23bd20780 "(hd0,gpt1)/EFI/debian/grub.cfg") at ../../../grub-core/normal/main.c:179 #19 grub_normal_execute (config=config@entry=0x23bd20780 "(hd0,gpt1)/EFI/debian/grub.cfg", nested=nested@entry=0, batch=batch@entry=0) at ../../../grub-core/normal/main.c:277 #20 0x00023bf40ca4 in grub_enter_normal_mode (config=config@entry=0x23bd20780 "(hd0,gpt1)/EFI/debian/grub.cfg") at ../../../grub-core/normal/main.c:304 #21 0x00023bf40da0 in grub_try_normal_prefix (prefix=0x23bd209a0 "(hd0,gpt1)/EFI/debian") at ../../../grub-core/normal/main.c:356 #22 0x00023bf40ea0 in grub_try_normal (variable=0x23bf4e492 "fw_path") at ../../../grub-core/normal/main.c:407 #23 grub_cmd_normal (cmd=, argc=0, argv=) at ../../../grub-core/normal/main.c:421 #24 grub_cmd_normal (cmd=, argc=, argv=) at ../../../grub-core/normal/main.c:412 #25 0x00023c018fb8 in grub_command_execute (name=0x23c01ec6e ")", argc=0, argv=0x0 <_start>) at ../../../include/grub/command.h:126 #26 grub_load_normal_mode () at ../../../grub-core/kern/main.c:247 #27 grub_main () at ../../../grub-core/kern/main.c:339 #28 0x00023c5c02c8 in ?? () #29 0x00023c62a000 in ?? () #30 0xafafafaf6c617470 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Is it possible to override the peloader or does the Xen image need to be prepared a certain way? -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#1069844: grub-efi-arm64: grub fails to load Xen hypervisor on arm64 EFI systems (AVA & QEMU)
../grub-core/normal/main.c:356 #21 0x00023bf40ea0 in grub_try_normal (variable=0x23bf4e492 "fw_path") at ../../../grub-core/normal/main.c:407 #22 grub_cmd_normal (cmd=, argc=0, argv=) at ../../../grub-core/normal/main.c:421 #23 grub_cmd_normal (cmd=, argc=, argv=) at ../../../grub-core/normal/main.c:412 #24 0x00023c018fb8 in grub_command_execute (name=0x23c01ec6e ")", argc=0, argv=0x0 <_start>) at ../../../include/grub/command.h:126 #25 grub_load_normal_mode () at ../../../grub-core/kern/main.c:247 #26 grub_main () at ../../../grub-core/kern/main.c:339 #27 0x00023c5c02c8 in ?? () #28 0x00023c62a000 in ?? () #29 0xafafafaf6c617470 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) While there are different firmwares (QEMU is EDKII targeting -M virt) it looks like the same error. However before writing off the firmware I did build the upstream grub: ➜ git describe grub-2.12-17-g8719cc204 17:25:21 alex@gwenyn:grub.git on master [?] ➜ git show HEAD commit 8719cc2040368d43ab2de0b6e1b850b2c9cfc5b7 (HEAD -> master, origin/master, origin/HEAD) Author: Daniel Kiper Date: Tue Apr 9 19:56:02 2024 +0200 windows: Add _stack_chk_guard/_stack_chk_fail symbols for Windows 64-bit target Otherwise the GRUB cannot start due to missing symbols when stack protector is enabled on EFI platforms. Signed-off-by: Daniel Kiper Reviewed-by: Vladimir Serbinenko And installed it in parallel with the distro grub. This was able to start Xen using the same grub.cfg and get most of the way through the Dom0 boot before that failed for unrelated issues. So it seems there is a bug introduced by the debian customisation of the package or missing a fix from the current state of upstream. -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#1059295: RFP: gfxstream -- wrapper for graphics streams across VirtIO
Package: wnpp Severity: wishlist * Package name: gfxstream Version : v0.1.2 Upstream Author : Google * URL or Web page : https://android.googlesource.com/platform/hardware/google/gfxstream * License : Apache2 Description : wrapper for graphics streams across VirtIO This package (and the supporting aemu and rutabagga_ffi bindings) is needed if we want to compile QEMU with rutabaga support - hence support Vulkan and Wayland over virtio-gpu. We have some notes for building in tree here in the meantime: https://linaro.atlassian.net/wiki/spaces/ORKO/pages/28985622530/Building+QEMU+with+virtio-gpu+and+rutabaga+gfx -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#1054412: reassign 1054412 cross-toolchain-base-ports
-- Alex Bennée Emulation and Virtualisation Tech Lead @ Linaro
Bug#1054412: cross-toolchain-base-ports: Stable update request to include latest glibc
Package: libc6.1-dev-alpha-cross Severity: serious X-Debbugs-Cc: none Dear Maintainer, The current alpha cross toolchain can't build working static binaries due to missing the fix for bug #1028200. This is fixed in the latest bookworm glibc but this isn't included in cross-toolchain-base-ports-62. See also: https://lists.debian.org/debian-alpha/2023/10/msg5.html -- System Information: Debian Release: 12.2 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf, i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#918812: failure to mount persists since bookworm
Hi, Just a quick note that the failure mode still exists after upgrading to bookworm (testing). If anyone has any pointers on how to diagnose mount failures during initrd I'd happily run some experiments. -- Alex Bennée Virtualisation Tech Lead @ Linaro
Bug#1005323: multipath-tools contains headers and executables so can't be used for cross-compilation
Package: multipath-tools Version: 0.8.5-2 Severity: normal Dear Maintainer, While trying to convert QEMU's cross-build images to lci-tool I discovered installing multipath-tools:arm64 as a foreign architecture package would fail due to unsatisfied dependencies. Switching the cross policy to "native" works but of course now the .so files don't match the target build architecture. In common with other Debian packages I would expect development files to be split into a separate -dev package so they could be installed without requiring binaries to execute. -- Package-specific info: /etc/multipath.conf does not exist. -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (900, 'stable'), (500, 'stable-security'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf, i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages multipath-tools depends on: ii kpartx 0.8.5-2 ii libaio1 0.3.112-9 ii libc6 2.31-13+deb11u2 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libjson-c5 0.15-2 ii libreadline88.1-1 ii libsystemd0 247.3-6 ii libudev1247.3-6 ii liburcu60.12.2-1 ii lsb-base11.1.0 ii sg3-utils-udev 1.45-1 ii udev247.3-6 multipath-tools recommends no packages. Versions of packages multipath-tools suggests: pn multipath-tools-boot -- no debconf information
Bug#918812:
I've hit what I think is a thin related issue on upgrading to bullseye/testing. My boot hangs on fsck timing out on the 3 thin provisioned partitions. I manually did a vgchange -ay to active them but it didn't solve the problem. If I drop into maintenance mode and manually "mount -a" things do mount and I can exit and continue the boot. I'm not sure the best way to further diagnose this and see if it's really related. -- Alex Bennée KVM/QEMU Hacker for Linaro
Bug#960271: Status on bug 960271 - 'BITS_PER_LONG' wrongly used
FWIW I would like it to be sooner rather than later because as the latest Debian images have rolled out more and more of our CI's have fallen over. Our attempts to work around the fix with a snapshot failed as well so we are currently hoping Debian based builds don't bitrot too much before stuff starts working again. On Fri, 22 May 2020 at 15:36, Lukas Straub wrote: > > Hello Everyone, > When will this fix be released? > > Regards, > Lukas Straub -- Alex Bennée KVM/QEMU Hacker for Linaro
Bug#960271: PATCH
This patch adds Christian Borntraeger's patch (467d12f5c784) to the
package build. It seemed to build OK following these steps:
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118.tar.xz
./debian/bin/genorig.py linux-4.19.118.tar.xz
make -f debian/rules orig
make -f debian/rules source
dpkg-buildpackage
Once I install the package I can build QEMU again.
>From eb53234b3feb45f26e0a8ff36779d49ca8965fbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alex=20Benn=C3=A9e?=
Date: Tue, 12 May 2020 11:36:37 +0100
Subject: [PATCH] uabi: fix breakage for compiling userspace (#960271)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Alex Bennée
---
debian/changelog | 6 ++
...ux-swab.h-fix-userspace-breakage-use.patch | 71 +++
debian/patches/series | 1 +
3 files changed, 78 insertions(+)
create mode 100644 debian/patches/bugfix/all/include-uapi-linux-swab.h-fix-userspace-breakage-use.patch
diff --git a/debian/changelog b/debian/changelog
index 6cac52587efea..0d6d0d05f819e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+linux (4.19.118-3) unstable; urgency=medium
+
+ * Fix uabi breakage (#960271)
+
+ -- Alex Bennée Mon, 11 May 2020 20:03:06 +0100
+
linux (4.19.118-2) buster; urgency=medium
* Merge changes from 4.19.67-2+deb10u2 to include all security fixes from
diff --git a/debian/patches/bugfix/all/include-uapi-linux-swab.h-fix-userspace-breakage-use.patch b/debian/patches/bugfix/all/include-uapi-linux-swab.h-fix-userspace-breakage-use.patch
new file mode 100644
index 0..f78e55ce99a63
--- /dev/null
+++ b/debian/patches/bugfix/all/include-uapi-linux-swab.h-fix-userspace-breakage-use.patch
@@ -0,0 +1,71 @@
+From cb93a89a6b400dbb7a5e2e1106616c93745f734d Mon Sep 17 00:00:00 2001
+From: Christian Borntraeger
+Date: Thu, 20 Feb 2020 20:04:03 -0800
+Subject: [PATCH] include/uapi/linux/swab.h: fix userspace breakage, use
+ __BITS_PER_LONG for swap
+
+QEMU has a funny new build error message when I use the upstream kernel
+headers:
+
+ CC block/file-posix.o
+In file included from /home/cborntra/REPOS/qemu/include/qemu/timer.h:4,
+ from /home/cborntra/REPOS/qemu/include/qemu/timed-average.h:29,
+ from /home/cborntra/REPOS/qemu/include/block/accounting.h:28,
+ from /home/cborntra/REPOS/qemu/include/block/block_int.h:27,
+ from /home/cborntra/REPOS/qemu/block/file-posix.c:30:
+/usr/include/linux/swab.h: In function `__swab':
+/home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:34: error: "sizeof" is not defined, evaluates to 0 [-Werror=undef]
+ 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE)
+ | ^~
+/home/cborntra/REPOS/qemu/include/qemu/bitops.h:20:41: error: missing binary operator before token "("
+ 20 | #define BITS_PER_LONG (sizeof (unsigned long) * BITS_PER_BYTE)
+ | ^
+cc1: all warnings being treated as errors
+make: *** [/home/cborntra/REPOS/qemu/rules.mak:69: block/file-posix.o] Error 1
+rm tests/qemu-iotests/socket_scm_helper.o
+
+This was triggered by commit d5767057c9a ("uapi: rename ext2_swab() to
+swab() and share globally in swab.h"). That patch is doing
+
+ #include
+
+but it uses BITS_PER_LONG.
+
+The kernel file asm/bitsperlong.h provide only __BITS_PER_LONG.
+
+Let us use the __ variant in swap.h
+
+Link: http://lkml.kernel.org/r/20200213142147.17604-1-borntrae...@de.ibm.com
+Fixes: d5767057c9a ("uapi: rename ext2_swab() to swab() and share globally in swab.h")
+Signed-off-by: Christian Borntraeger
+Cc: Yury Norov
+Cc: Allison Randal
+Cc: Joe Perches
+Cc: Thomas Gleixner
+Cc: William Breathitt Gray
+Cc: Torsten Hilbrich
+Signed-off-by: Andrew Morton
+Signed-off-by: Linus Torvalds
+---
+ include/uapi/linux/swab.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
+index fa7f97da5b768..7272f85d6d6ab 100644
+--- a/include/uapi/linux/swab.h
b/include/uapi/linux/swab.h
+@@ -135,9 +135,9 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
+
+ static __always_inline unsigned long __swab(const unsigned long y)
+ {
+-#if BITS_PER_LONG == 64
++#if __BITS_PER_LONG == 64
+ return __swab64(y);
+-#else /* BITS_PER_LONG == 32 */
++#else /* __BITS_PER_LONG == 32 */
+ return __swab32(y);
+ #endif
+ }
+--
+2.20.1
+
diff --git a/debian/patches/series b/debian/patches/series
index c4eedde94a350..0b32d63827c04 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -302,3 +302,4 @@ bugfix/all/blktrace-fix-dereference-after-null-check.patch
bugfix/s390x/s390-mm-fix-page-table-upgrade-vs-2ndary-address-mod.patch
Bug#925555: linux-image-4.19.0-4-amd64 causes X regression
I can confirm I've seen the same symptoms on my system. I was unable to get a working X session (although the cursor would appear on one of my two displays). Manual startx would also fail. HW: 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor DRAM Controller Flags: bus master, fast devsel, latency 0 Capabilities: Kernel driver in use: hsw_uncore 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 26 Memory at f780 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 32 Memory at f7e14000 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) (prog-if 30 [XHCI]) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB xHCI Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at f7e0 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family MEI Controller Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at f7e1e000 (64-bit, non-prefetchable) [size=16] Capabilities: Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family USB EHCI Flags: bus master, medium devsel, latency 0, IRQ 20 Memory at f7e1c000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High Definition Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f7e1 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: Kernel driver in use: pcieport 00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 18 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: f7d0-f7df Prefetchable memory behind bridge: f000-f00f Capabilities: Kernel driver in use: pcieport 00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: f7c0-f7cf Capabilities: Kernel driver in use: pcieport 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) (prog-if 20 [EHCI])
Bug#924667: qemu-user-static: setting up of binfmt_misc is slightly naive about cpu features
Package: qemu-user-static Version: 1:3.1+dfsg-4 Severity: normal Dear Maintainer, Trying to build gitlab-runner on an ThunderX arm64 box it tries to run a docker image with armhf binaries which fails: standard_init_linux.go:207: exec user process caused "exec format error" You can replicate by running: 14:30:41 [root@qemu-test:/v/l/d/info] 1 # uname -a Linux qemu-test 4.20.0 #5 SMP Tue Jan 8 10:57:44 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux 14:30:46 [root@qemu-test:/v/l/d/info] # arch-test -n armhf armhf: not supported on this machine/kernel The underlying reason is because binfmt_misc isn't set up for armhf binaries because qemu-user-static.postinst does: # find which fmts needs to be filtered out, which is arch-dependent. # Drop support for emulating amd64 on i386, http://bugs.debian.org/604712 case "$DPKG_MAINTSCRIPT_ARCH" in amd64 | i386) omit="i386|x86_64" ;; arm | armel | armhf | arm64) omit="arm|aarch64" ;; mips | mipsel) omit="$DPKG_MAINTSCRIPT_ARCH" ;; ppc64 | powerpc) omit="ppc|ppc64|ppc64abi32" ;; ppc64el) omit="ppc64le" ;; s390x) omit="s390x" ;; sparc | sparc64) omit="sparc|sparc32plus|sparc64" ;; *) omit="$DPKG_MAINTSCRIPT_ARCH" ;; esac Which is certainly not true for all aarch64 CPUs. Some do not support aarch32. The following change makes it work but requires arch-test as a dependency: # find which fmts needs to be filtered out, which is arch-dependent. # Drop support for emulating amd64 on i386, http://bugs.debian.org/604712 case "$DPKG_MAINTSCRIPT_ARCH" in amd64 | i386) omit="i386|x86_64" ;; arm | armel | armhf) omit="arm" ;; arm64 ) if arch-test -n armhf > /dev/null; then omit="arm|aarch64" else omit="aarch64" fi ;; mips | mipsel) omit="$DPKG_MAINTSCRIPT_ARCH" ;; ppc64 | powerpc) omit="ppc|ppc64|ppc64abi32" ;; ppc64el) omit="ppc64le" ;; s390x) omit="s390x" ;; sparc | sparc64) omit="sparc|sparc32plus|sparc64" ;; *) omit="$DPKG_MAINTSCRIPT_ARCH" ;; esac This logic is repeated in the prerm script so there is probably some scope in cleaning up and sharing the logic. -- System Information: Ubuntu Release: bionic Debian Release: buster/sid Architecture: arm64 I found this on bionic but the bug exists upstream as well: binfmt-support/bionic,now 2.1.8-2 arm64 [installed,automatic] qemu-user-static/bionic-updates,now 1:2.11+dfsg-1ubuntu7.10 arm64 [installed] -- no debconf information -- Alex Bennée
Bug#922979: qemu-efi-aarch64: arm64 UEFI image is unpadded which may confuse new users
Package: qemu-efi-aarch64 Version: 0~20181115.85588389-2 Severity: normal Dear Maintainer, With an un-patched QEMU running with: -drive if=pflash,file=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd,format=raw,readonly will fail cryptically as the image isn't padded to the device size. The qemu-efi-arm package is currently padded: $ ls -lh /usr/share/qemu-efi-aarch64/QEMU_EFI.fd /usr/share/AAVMF/AAVMF32_CODE.fd -rw-r--r-- 1 root root 64M Nov 26 23:34 /usr/share/AAVMF/AAVMF32_CODE.fd -rw-r--r-- 1 root root 2.0M Nov 26 23:34 /usr/share/qemu-efi-aarch64/QEMU_EFI.fd Whether fixing the packaging or using a patch like currently being discussed on qemu-devel: https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg05934.html I leave as a decision for the Debian maintainers ;-) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- Alex Bennée
Bug#922786: [Virtualsquare] Bug#921648: apt-get build-dep -a arm64 qemu fails on multiarch setup due to binary dependancies in -dev packages
Package: libcacard-dev Version: 1:2.6.1-1 Alex Bennée writes: > Alex Bennée writes: > >> Renzo Davoli writes: >> >>> Alex, >>> we have tried to replicate the problem with no luck. > >> > > Hmm on my dev machine I still get: > > 18:17:40 [root@zen:~] # apt build-dep -a arm64 qemu > Reading package lists... Done > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: >builddeps:qemu:arm64 : Depends: libcacard-dev:arm64 but it is not going to > be installed > Depends: libvdeplug-dev:arm64 but it is not going > to be installed > Depends: xfslibs-dev:arm64 but it is not going to > be installed > E: Unable to correct problems, you have held broken packages. > > But I suspect that asking for the arm64 build-deps at the same time as > the native build-deps is probably a bit too much for the system. Should > not being able to have side by side deps for the same package be > considered a bug? With a minimal docker test case the failure I get is: The following packages have unmet dependencies: builddeps:qemu:arm64 : Depends: libcacard-dev:arm64 but it is not going to be installed E: Unable to correct problems, you have held broken packages. The steps are: # # On its own you can't build much but the docker-foo-cross targets # build on top of the base debian image. # FROM debian:buster-slim # Duplicate deb line as deb-src RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> /etc/apt/sources.list # Install common build utilities RUN apt update RUN DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata RUN DEBIAN_FRONTEND=noninteractive eatmydata apt dist-upgrade -yy RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt install -y --no-install-recommends \ bison \ build-essential \ ca-certificates \ clang \ flex \ gettext \ git \ pkg-config \ psmisc \ python \ texinfo \ $(apt-get -s build-dep qemu | egrep ^Inst | fgrep '[all]' | cut -d\ -f2) RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get build-dep -yy qemu RUN dpkg --add-architecture arm64 RUN apt update RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ crossbuild-essential-arm64 RUN DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get build-dep -yy -a arm64 qemu -- Alex Bennée
Bug#921648: [Virtualsquare] Bug#921648: apt-get build-dep -a arm64 qemu fails on multiarch setup due to binary dependancies in -dev packages
Alex Bennée writes: > Renzo Davoli writes: > >> Alex, >> we have tried to replicate the problem with no luck. > > Anyway I shall close the bug now. Hmm on my dev machine I still get: 18:17:40 [root@zen:~] # apt build-dep -a arm64 qemu Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:qemu:arm64 : Depends: libcacard-dev:arm64 but it is not going to be installed Depends: libvdeplug-dev:arm64 but it is not going to be installed Depends: xfslibs-dev:arm64 but it is not going to be installed E: Unable to correct problems, you have held broken packages. But I suspect that asking for the arm64 build-deps at the same time as the native build-deps is probably a bit too much for the system. Should not being able to have side by side deps for the same package be considered a bug? -- Alex Bennée
Bug#921648: [Virtualsquare] Bug#921648: apt-get build-dep -a arm64 qemu fails on multiarch setup due to binary dependancies in -dev packages
Renzo Davoli writes: > Alex, > we have tried to replicate the problem with no luck. > > * We created a clean VM (amd64) running Stretch (ssh server/base files only) > * THe VM has been updated to SID > -8<-- > root@testmultiarch:~# dpkg --add-architecture arm64 > root@testmultiarch:~# apt install build-essential > ... > root@testmultiarch:~# apt-get build-dep -a arm64 qemu > Reading package lists... Done > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages were automatically installed and are no longer > required: > dh-python libbind9-140 libdns162 libicu57 libisc160 libisccc140 > libisccfg140 liblwres141 libperl5.24 libpython3.5-minimal > libpython3.5-stdlib python3.5 python3.5-minimal rename sgml-base tcpd > xml-core > Use 'apt autoremove' to remove them. > The following NEW packages will be installed: > adwaita-icon-theme autoconf automake autopoint autotools-dev binutils- > [...cut cut cut...] > x11proto-dev x11proto-fixes-dev x11proto-input-dev x11proto-randr-dev > x11proto-record-dev x11proto-xext-dev x11proto-xf86vidmode-dev > x11proto-xinerama-dev xfslibs-dev:arm64 xfsprogs:arm64 > xorg-sgml-doctools xtrans-dev zlib1g:arm64 zlib1g-dev:arm64 > 0 upgraded, 482 newly installed, 0 to remove and 0 not upgraded. > Need to get 200 MB of archives. > After this operation, 864 MB of additional disk space will be used. > Do you want to continue? [Y/n] > -8<-- > It works for a while but eventually completes the installation without any > further problem. > > Can you please help us to replicate the erroneous behavior you have > got? It looks like something has been fixed in the meantime \o/ For reference these where the steps we were following: https://github.com/stsquad/dockerfiles/blob/master/multiarch/debian-arm64-cross/Dockerfile > > renzo > (tnx to Diego Zuccato who actually ran the tests) Is there anyway to list all the package changes that have happened since the bug was reported? Anyway I shall close the bug now. -- Alex Bennée
Bug#921458: qemu-system-common: dependancy on gcc-s390x-linux-gnu fails on non-x86 hosts
Michael Tokarev writes: > 06.02.2019 13:58, Alex Bennée wrote: > [] >>> What should the dependencies look like? As per: From: Helmut Grohne Subject: Re: [PATCH] binutils: enable s390x/ppc64el on arm64 hosts Message-ID: <20190213051906.ga24...@alf.mars> The workaround is to use: apt-get build-dep --arch-only qemu On non-x86 build machines to skip attempting to install only the packages needed for this architectures build. There is further background mentioned in the above email: For more background on this matter, I recommend the rather longer thread on the open policy bug about adding Build-Indep-Architecture (#846970). That field is supposed to document which architecture you can build architecture-independent packages on. This may sound backwards initially, but you'll encounter a number of affected packages and the field is supposed to at least document the status quo. So I'm closing this bug. -- Alex Bennée
Bug#921458: Handling build-depends-indep for non-x86 source packages (was: Bug#921458: qemu-system-common: dependancy on gcc-s390x-linux-gnu fails on non-x86 hosts)
Hi, The following bug has come up and we would like some input from the multiarch and cross developers on how best to handle this case. In an ideal world all cross compilers would be available on all release architectures but I think it will be a while before we get there. My own efforts to get just all the cross binutils cleanly building on arm64 have stalled somewhat so in the meantime is there anything we can do to keep build-dependencies working on all arches? See bellow for more context: Michael Tokarev writes: > 06.02.2019 13:58, Alex Bennée wrote: > [] >>> What should the dependencies look like? >> >> I'm not sure - it does seem weird that we are treating what is in effect >> an s390x architecture blob as architecture independent. I guess QEMU is >> good at generating weird exception cases. > > Actually _all_ firmware blobs are shipped as indep packages. We don't want > to enable whole mips or arm or sparc or ppc multiarch on x86 just to install > or run qemu on host. > >> How did we ship s390x blobs on non-x86 release architectures before >> this change? > > For s390x we didn't, at all, there was a bug open for missing s390x fw, > users of qemu-system-s390x were getting firmware from upstream site. > > For some other stuff, like qemu-specific x86 firmware (needed on all > arches as well, just like s390x or ppc blobs), we used an ugly hack > to embed sources for said firmware in other package's debian/foo.tar.gz > files. For yet another, we created separate package which builds > arch-all blobs (openbios, seabios, etc). > > I really like to stop this mess, and now it is possible finally because > cross-compilers are available. > > There was another way to deal with this - one package which qemu-team > maintains builds a cross-compiler from gcc source first and uses that > compiler to build actual firmware blobs. I don't think this is a good > solution. > > I especially used build-depends-indep for all these cross-compilers, > in order for qemu arch-specific packages to remain buildable on non- > x86 architectures. Is this wrong somehow? If this is wrong, I think > we should bring this on some mailinglist, so that maybe multiarch > or cross-gcc people will share their opinion? > > Thank you! > > /mjt -- Alex Bennée
Bug#921648: apt-get build-dep -a arm64 qemu fails on multiarch setup due to binary dependancies in -dev packages
Alex Bennée writes: Package: qemu Version: 3.1+dfsg-2 Package: xfsprogs Version: 4.15.1-1 > > Which would uninstall the base QEMU binaries. Backtracking I think the > problem is: > > The following packages have unmet dependencies: >libvdeplug-dev:arm64 : Depends: libvdeplug2:arm64 (= 2.3.2+r586-2.2) but > it is not going to be installed >xfslibs-dev:arm64 : Depends: xfsprogs:arm64 (>= 3.0.0) but it is not going > to be installed > > As the libvdeplug2 and xfslibs dependancies have been in the QEMU > package for a while this looks like a regression in the dev packages. I > know these work in stretch as we use a dockerised stretch as the basis > for our cross-compile tools upstream. OK testing on inside an otherwise clean docker container (so as not to clash with my native build-deps) I get: The following packages have unmet dependencies: builddeps:qemu:arm64 : Depends: xfslibs-dev:arm64 but it is not going to be installed E: Unable to correct problems, you have held broken packages. So it looks like libvde2 is in the clear and it's the xfslibs-dev that is broken. However I can install it directly: apt-get install xfslibs-dev:arm64 and then if I try apt-get build-dep -a arm64 qemu again I get: The following packages have unmet dependencies: builddeps:qemu:arm64 : Depends: glusterfs-common:arm64 E: Unable to correct problems, you have held broken packages. Which leads to: apt install glusterfs-common:arm64 which complains with: The following packages have unmet dependencies: glusterfs-common:arm64 : Depends: python3-prettytable:arm64 but it is not installable Depends: python3-requests:arm64 but it is not installable Depends: python3-jwt:arm64 but it is not installable However if I try: apt install glusterfs-common:arm64 python3-prettytable:arm64 python3-requests:arm64 python3-jwt:arm64 It turns out a bunch of unavailable packages: E: Package 'python3-prettytable:arm64' has no installation candidate E: Package 'python3-requests:arm64' has no installation candidate E: Package 'python3-jwt:arm64' has no installation candidate -- Alex Bennée
Bug#921648: apt-get build-dep -a arm64 qemu fails on multiarch setup due to binary dependancies in -dev packages
Package: qemu Version: 3.1+dfsg-2 Package: vde2 Version: 2.3.2+r586-2.2 Pakcage: xfsprogs Version: 4.15.1-1 Severity: normal Dear Maintainer, Running on an x86_64 machine with dpkg --add-architecture arm64: apt-get build-dep -a arm64 qemu Reports: The following packages have unmet dependencies: builddeps:qemu:arm64 : Depends: libcacard-dev:arm64 but it is not going to be installed Depends: libvdeplug-dev:arm64 but it is not going to be installed Depends: xfslibs-dev:arm64 but it is not going to be installed I tried to work through the dependencies manually and eventually got to: apt-get install libcacard-dev:arm64 libvdeplug-dev:arm64 \ xfslibs-dev:arm64 libnss3-dev:arm64 \ libvdeplug2:arm64 xfsprogs:arm64 libnspr4-dev:arm64 Which offered to install but: The following packages were automatically installed and are no longer required: cryptsetup cryptsetup-bin cryptsetup-initramfs cryptsetup-run db-util guile-2.2 hfsplus icoutils ipxe-qemu ldmtool libacl1-dev libafflib0v5 libconfig9 libdate-manip-perl libewf2 libgfapi0 libgfchangelog0 libgfdb0 libgfrpc0 libgfxdr0 libglusterfs-dev libglusterfs0 libhfsp0 libhivex0 libldm-1.0-0 libsys-virt-perl libtcl8.6 libtsk13 liburcu6 libwin-hivex-perl libyara3 lsscsi mtools openbios-ppc openbios-sparc openhackware python3-jwt python3-prettytable qemu-efi qemu-slof qemu-system-common qemu-system-data qemu-system-gui scrub seabios sgabios sleuthkit supermin syslinux zerofree Use 'apt autoremove' to remove them. The following additional packages will be installed: libblkid1:arm64 libcacard0:arm64 libdevmapper1.02.1:arm64 libffi6:arm64 libglib2.0-0:arm64 libmount1:arm64 libnspr4:arm64 libnss3:arm64 libpcre3:arm64 libpcsclite1:arm64 libreadline5:arm64 libselinux1:arm64 libsqlite3-0:arm64 libtinfo6:arm64 libudev1:arm64 libuuid1:arm64 uuid-dev:arm64 uuid-runtime Suggested packages: xfsdump:arm64 quota:arm64 The following packages will be REMOVED: glusterfs-common libcacard-dev libguestfs-hfsplus libguestfs-perl libguestfs-reiserfs libguestfs-tools libguestfs-xfs libguestfs0 libnspr4-dev libnss3-dev libvdeplug-dev libvdeplug2 qemu-kvm qemu-system qemu-system-arm qemu-system-mips qemu-system-misc qemu-system-ppc qemu-system-sparc qemu-system-x86 xfslibs-dev xfsprogs The following NEW packages will be installed: libblkid1:arm64 libcacard-dev:arm64 libcacard0:arm64 libdevmapper1.02.1:arm64 libffi6:arm64 libglib2.0-0:arm64 libmount1:arm64 libnspr4:arm64 libnspr4-dev:arm64 libnss3:arm64 libnss3-dev:arm64 libpcre3:arm64 libpcsclite1:arm64 libreadline5:arm64 libselinux1:arm64 libsqlite3-0:arm64 libtinfo6:arm64 libudev1:arm64 libuuid1:arm64 libvdeplug-dev:arm64 libvdeplug2:arm64 uuid-dev:arm64 uuid-runtime xfslibs-dev:arm64 xfsprogs:arm64 0 upgraded, 25 newly installed, 22 to remove and 0 not upgraded. Need to get 6,270 kB of archives. After this operation, 354 MB disk space will be freed. Do you want to continue? [Y/n] Which would uninstall the base QEMU binaries. Backtracking I think the problem is: The following packages have unmet dependencies: libvdeplug-dev:arm64 : Depends: libvdeplug2:arm64 (= 2.3.2+r586-2.2) but it is not going to be installed xfslibs-dev:arm64 : Depends: xfsprogs:arm64 (>= 3.0.0) but it is not going to be installed As the libvdeplug2 and xfslibs dependancies have been in the QEMU package for a while this looks like a regression in the dev packages. I know these work in stretch as we use a dockerised stretch as the basis for our cross-compile tools upstream. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- Alex Bennée
Bug#921458: qemu-system-common: dependancy on gcc-s390x-linux-gnu fails on non-x86 hosts
Michael Tokarev writes: > Control: reassign -1 src:qemu > Control: tag -1 + moreinfo > > 05.02.2019 22:12, Alex Bennée wrote: >> Package: qemu-system-common >> Version: 1:3.1+dfsg-2+b1 >> Severity: normal >> >> Dear Maintainer, >> >> This is a problem when running: >> >>apt build-dep qemu >> >> On a arm64 host. I also ran into other failures while trying: >> >>apt build-dep -a arm64 qemu >> >> On a multiarch setup. The root reason is that the s390 cross compiler >> isn't packaged for all of debian's release architectures. > > Hm. So how this should be done? Please note that gcc-s390x is only > listed in Build-Depends-Indep, not in Build-Depends, and the indep > target is really only buildable on x86 exactly _because_ > cross-compilers s/cross-compilers/some cross-compilers/ Most of the other architectures tend to at least have their 32 bit cousins as well as x86 cross compilers available. However x86 currently has the largest breadth of cross compiler support. > are not available on other architectures. Ideally I'd like to support more cross compilers on more host architectures. However my attempts at getting all target binutils on arm have stalled somewhat and I suspect it's too late for the buster release cycle. > What should the dependencies look like? I'm not sure - it does seem weird that we are treating what is in effect an s390x architecture blob as architecture independent. I guess QEMU is good at generating weird exception cases. How did we ship s390x blobs on non-x86 release architectures before this change? > > Thanks, > > /mjt -- Alex Bennée
Bug#921458: qemu-system-common: dependancy on gcc-s390x-linux-gnu fails on non-x86 hosts
Package: qemu-system-common Version: 1:3.1+dfsg-2+b1 Severity: normal Dear Maintainer, This is a problem when running: apt build-dep qemu On a arm64 host. I also ran into other failures while trying: apt build-dep -a arm64 qemu On a multiarch setup. The root reason is that the s390 cross compiler isn't packaged for all of debian's release architectures. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64, armhf Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-common depends on: ii adduser 3.118 ii libc6 2.28-5 ii libcap-ng00.7.9-2 ii libcap2 1:2.25-1.2 ii libglib2.0-0 2.58.2-3 qemu-system-common recommends no packages. qemu-system-common suggests no packages. -- no debconf information -- Alex Bennée
Bug#909128: gcc-defaults: debian/rules control duplicates amd64 compilers when regenerated on arm64 hosts
Source: gcc-defaults Version: 1.179 Severity: normal Dear Maintainer, If you run debian/rules control on an arm64 machine dpkg barfs warning about duplicate *-x86-64-linux-gnu packages causing the build to fail. This is probably due to clashing special casing for the amd64 packages. A simple patch to fix this is: --- gcc-defaults-1.179/debian/rules 2018-08-16 10:44:12.0 + +++ gcc-defaults-1.179-ajb/debian/rules 2018-09-18 18:30:03.621593507 + @@ -366,7 +366,7 @@ $(if $(filter $(DEB_HOST_ARCH), i386 x32), amd64) \ $(if $(filter $(DEB_HOST_ARCH), amd64 x32), i386) else ifeq ($(DEB_HOST_ARCH),arm64) - CROSS_ARCHS = amd64 armel armhf i386 + CROSS_ARCHS = armel armhf i386 else ifeq ($(DEB_HOST_ARCH),ppc64) CROSS_ARCHS = ppc64el else ifeq ($(DEB_HOST_ARCH),ppc64el) This is a problem as amd64 is always added to the build in: ifeq ($(with_cross),yes) : # FIXME: filter-out some gdc and gccgo multilib configs $(foreach a,amd64 $(CROSS_ARCHS), \ I think either amd64 shouldn't be in the cross arch filters or shouldn't be unconditionally added later on. This may apply to other architectures too and would probably show up if the control files where regularly regenerated on non-x86 hosts. Regards, Alex.
Bug#903657: debootstrap checks for existence of wget on --second-stage, breaking --foreign bootstraps
Package: debootstrap Version: 1.0.95ubuntu0.1 Severity: important Dear Maintainer, QEMU's build system has support for debootstrap using binfmt_misc and QEMU's linux-user emulation. Since commit 9a6ebf628 this is broken as it checks for the presence of wget which isn't available in the second-stage environment. If the user is doing a --second-stage it shouldn't matter that wget is missing as all the packages have already been downloaded on the host system. For reference the wrapper script is: https://git.qemu.org/?p=qemu.git;a=blob;f=tests/docker/dockerfiles/debian-bootstrap.pre;h=56e1aa7a21418437b5b0fbaf473a8686338d9014;hb=cee35138b59c6d6b0808c5fa644e3f063832860f And you should be able to debootstrap on QEMU's master with a line like: make docker-binfmt-image-debian-ubuntu-xenial-arm64 DEB_ARCH=arm64 \ DEB_TYPE=xenial DEB_URL=http://ports.ubuntu.com EXECUTABLE=./aarch64-linux-user/qemu-aarch64~ There is also a bug in QEMU's own script which means it always falls back to the SCM version of debootstrap, but that is mine to fix ;-) -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 4.15.0-24-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.19.4-1ubuntu2.1 Versions of packages debootstrap recommends: ii gnupg 2.2.4-1ubuntu1.1 ii ubuntu-keyring 2018.02.28 Versions of packages debootstrap suggests: pn ubuntu-archive-keyring -- no debconf information
Bug#857932: xfslibs-dev:ppc64el Fails to install on multi-arch setup with merged /usr
Package: xfslibs-dev Severity: normal Tags: stretch, sid Usertags: usr, usrmerge, multiarch Hi, While trying to build a cross-build environment for QEMU I ran into a problem installing xfslibs-dev. The docker build looked like this: # # Docker ppc64el cross-compiler target # # This docker target builds on the base debian image. # # Broken in Jessie FROM debian:stretch-slim # Duplicate deb line as deb-src RUN cat /etc/apt/sources.list | sed "s/deb/deb-src/" >> /etc/apt/sources.list # Add the foreign architecture we want and install dependencies RUN dpkg --add-architecture ppc64el RUN apt update && apt dist-upgrade -yy RUN apt-get build-dep -yy -a ppc64el qemu RUN apt install -yy gcc-multilib-ppc64el binutils-multiarch # Specify the cross prefix for this image (see tests/docker/common.rc) ENV QEMU_CONFIGURE_OPTS --cross-prefix=ppc64el-linux-gnu- The error message reported by the build-dep stage was: Unpacking xfslibs-dev:ppc64el (4.9.0) ... dpkg: error processing archive /tmp/apt-dpkg-install-u0zpz1/10-xfslibs-dev_4.9.0_ppc64el.deb (--unpack): unable to install new version of '/lib/libhandle.a': No such file or directory Errors were encountered while processing: /tmp/apt-dpkg-install-u0zpz1/10-xfslibs-dev_4.9.0_ppc64el.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Testing with debian:unstable-slim produced the same result. After discussion on #debian-bootstrap we reproduced with a simpler setup: I can reproduce your problem in unstable now. fresh sid debootstrap amd64; dpkg --add-architecture ppc64el; apt-get update; apt-get install usrmerge; apt-get install xfslibs-dev:ppc64el # reproduces There seems to be debate as to if this is a straight up multi-arch bug or a user merge bug so I've tagged them as both for now. Certainly static libraries need to be properly placed in the relevant multi-arch paths but this seems to work for arm64 and armhf (which I have also set up QEMU cross build environments for). --- Alex Bennée
Bug#837092: The package description needs to be more clear
We were discussing this on IRC: chazy: on debian/ubuntu UEFI for arm64 is included in package qemu-efi suihkulokki: cool. who did this work? chazy: the debian Qemu team :) suihkulokki: cool nice of them it's the same way seabios (for x86) and openbios (for sparc, ppc?) is done suihkulokki: yes, but people really care about their x86 hardware ;) > suihkulokki: so the qemu-efi on my x86 box is the x86 efi build? ajb-linaro: no. qemu-efi on your x86 is for aarch64. EFI build for x86/qemu is in package ovmf I think this is confusing for me. I can't bear how confusing this is for people outside our field of expertise. > suihkulokki: maybe changing the package description to be a bit more explicit? If I run "file" on the blob I just get the magic "data" type ;-) So I learnt the package is what I need for running aarch64 guests on my x86 box. Perhaps the description could be tweaked to make this clearer? -- Alex Bennée
Bug#830869: [PATCH] debootstrap: excise all devices.tar.gz code
Since bug #571136 was fixed the --second-stage doesn't even use the
devices tarball so we can remove all its related cruft. The README has
been updated to show when real root access is required and give an
example of a foreign debootstrap which works with fakeroot.
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
---
.gitignore | 1 -
Makefile| 25 -
README | 18 ++
debootstrap | 3 ---
functions | 8 +---
5 files changed, 15 insertions(+), 40 deletions(-)
diff --git a/.gitignore b/.gitignore
index 8b3512f..8b13789 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-devices.tar.gz
diff --git a/Makefile b/Makefile
index 1020cbc..55f229d 100644
--- a/Makefile
+++ b/Makefile
@@ -2,17 +2,9 @@
VERSION := $(shell sed 's/.*(\(.*\)).*/\1/; q' debian/changelog)
DATE := $(shell sed -n '/^ -- /{s/.*> \(.*\)/\1/p;q;}' debian/changelog)
-MAKEDEV ?= /sbin/MAKEDEV
-
-ifeq ($(shell uname),Linux)
-all: devices.tar.gz
-else
all:
-endif
clean:
- rm -f devices.tar.gz
- rm -rf dev
DSDIR=$(DESTDIR)/usr/share/debootstrap
install:
@@ -25,20 +17,3 @@ install:
sed 's/@VERSION@/$(VERSION)/g' debootstrap
>$(DESTDIR)/usr/sbin/debootstrap
chown root:root $(DESTDIR)/usr/sbin/debootstrap
chmod 0755 $(DESTDIR)/usr/sbin/debootstrap
-
-ifeq ($(shell uname),Linux)
- install -o root -g root -m 0644 devices.tar.gz $(DSDIR)/
-endif
-
-devices.tar.gz:
- rm -rf dev
- mkdir -p dev
- chown 0:0 dev
- chmod 755 dev
- (cd dev && $(MAKEDEV) std ptmx fd consoleonly)
- tar --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz
- @if [ "$$(tar tvf devices.tar.gz | wc -l)" -lt 2 ]; then \
- echo " ** devices.tar.gz is empty!" >&2; \
- exit 1; \
- fi
- rm -rf dev
diff --git a/README b/README
index 5c08e15..af30a75 100644
--- a/README
+++ b/README
@@ -18,11 +18,21 @@ First, get the source.
* Or by visiting <http://packages.debian.org/source/sid/debootstrap>
and downloading the tar.gz file
-Then as root, in the debootstrap source directory:
+Then in the debootstrap source directory:
-make devices.tar.gz
-export DEBOOTSTRAP_DIR=`pwd`
-debootstrap sid sid
+export DEBOOTSTRAP_DIR=`pwd`
+sudo ./debootstrap stable my-stable-dir
+
+If you are running a multi-stage boot strap (for example for a QEMU
+rootfs) you don't even need root:
+
+export DEBOOTSTRAP_DIR=`pwd`
+fakeroot ./debootstrap --foreign --arch=armhf testing my-testing-dir
http://httpredir.debian.org/debian
+
+Of course you will need to execute the second stage as root to finish the
bootstrap:
+
+ (on foreign hardware)
+ /debootstrap/debootstrap --second-stage
Future
diff --git a/debootstrap b/debootstrap
index 2a959bb..4cea268 100755
--- a/debootstrap
+++ b/debootstrap
@@ -18,8 +18,6 @@ if [ -z "$DEBOOTSTRAP_DIR" ]; then
fi
fi
-DEVICES_TARGZ=$DEBOOTSTRAP_DIR/devices.tar.gz
-
. $DEBOOTSTRAP_DIR/functions
exec 4>&1
@@ -635,7 +633,6 @@ if am_doing_phase first_stage; then
if ! am_doing_phase second_stage; then
cp "$0"
"$TARGET/debootstrap/debootstrap"
cp $DEBOOTSTRAP_DIR/functions"$TARGET/debootstrap/functions"
- cp $DEBOOTSTRAP_DIR/devices.tar.gz
"$TARGET/debootstrap/devices.tar.gz"
cp $SCRIPT
"$TARGET/debootstrap/suite-script"
echo "$ARCH">"$TARGET/debootstrap/arch"
echo "$SUITE" >"$TARGET/debootstrap/suite"
diff --git a/functions b/functions
index 031721f..67701ee 100644
--- a/functions
+++ b/functions
@@ -1065,13 +1065,7 @@ setup_devices () {
hurd*)
;;
*)
- if true; then
- setup_devices_simple
- elif [ -e "$DEVICES_TARGZ" ]; then
- zcat "$DEVICES_TARGZ" | (cd "$TARGET"; tar -xf -)
- else
- error 1 NODEVTGZ "no %s. cannot create devices"
"$DEVICES_TARGZ"
- fi
+ setup_devices_simple
;;
esac
}
--
2.9.3
Bug#830869: debootstrap: script fails first stage due to missing devices.tar.gz despite no longer being used
Hi,
Sorry I misfiled this bug against debhelper, this has now been fixed.
In short there seems to be a bunch of cruft associated with the
devices.tar.gz file which used to be used by the second stage to set up
devices in the bootstrapped chroot. This manifests itself if you run the
script from a SCM checkout without first doing a root based build (which
only works on Debian anyway).
In my case I fixed this by simply making cp || true although I guess
there is a bigger argument for properly excising the code as it is now
longer used AFAICT, see the main script:
if true; then
setup_devices_simple
elif [ -e "$DEVICES_TARGZ" ]; then
zcat "$DEVICES_TARGZ" | (cd "$TARGET"; tar -xf -)
else
error 1 NODEVTGZ "no %s. cannot create devices"
"$DEVICES_TARGZ"
fi
Sorry for the additional bug noise.
--
Alex Bennée
Bug#830869: [debhelper-devel] Bug#830869: debhelper: script fails first stage due to missing devices.tar.gz despite no longer being used
Niels Thykier <ni...@thykier.net> writes: > Alex Bennée: >> >> Niels Thykier <ni...@thykier.net> writes: >> >>> Alex Bennée: >>>> Package: debhelper >>>> Severity: normal >>>> >>> >>> Hi Alex, >>> >>> I am a bit confused by this bug. Did you perhaps intend to submit it >>> against debootstrap instead of debhelper? >> >> Apologies, completion fail. I was fighting M-x debian-bug which took >> several attempts to send the email. >> >> Yes it should be against debootstrap. Can I reassign it in BTS? >> >>> >>>[...] > > Yes you can. :) > > Please see [1] for the how to do it. You may also want to retitle[2] > the bug while you are at it (as it says debhelper). :) Finally, you > should remove the "moreinfo" tag I added. OK Thanks, I think I have it figured out now. Sorry for the noise on your list ;-) -- Alex Bennée
Bug#830869: [debhelper-devel] Bug#830869: debhelper: script fails first stage due to missing devices.tar.gz despite no longer being used
Niels Thykier <ni...@thykier.net> writes: > Alex Bennée: >> Package: debhelper >> Severity: normal >> > > Hi Alex, > > I am a bit confused by this bug. Did you perhaps intend to submit it > against debootstrap instead of debhelper? Apologies, completion fail. I was fighting M-x debian-bug which took several attempts to send the email. Yes it should be against debootstrap. Can I reassign it in BTS? > >> Since bug #571136 was fixed we no longer actually need a devices.tar.gz >> to build our tarball. However we can't just checkout the debootstrap >> script and call directly because it still requires the tarball. One >> possible fix is attached bellow, although a more thorough cleaning could >> be done: >> >> --- >> Subject: [PATCH] debootstrap: fail gracefully copying devices.tgar.gz >> >> The devices tarball only exists if you build the source code (as root) >> before invoking the script. Since bug #571136 was fixed the >> --second-stage doesn't even use the devices tarball so we can afford to >> fail gracefully when it doesn't exist. In addition this allows us to >> call the script under -e conditions from a straight checkout which is >> useful in other cases. >> >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> >> --- >> debootstrap | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/debootstrap b/debootstrap >> index 2a959bb..4027a5d 100755 >> --- a/debootstrap >> +++ b/debootstrap >> @@ -635,7 +635,7 @@ if am_doing_phase first_stage; then >> if ! am_doing_phase second_stage; then >> cp "$0" >> "$TARGET/debootstrap/debootstrap" >> cp $DEBOOTSTRAP_DIR/functions >> "$TARGET/debootstrap/functions" >> -cp $DEBOOTSTRAP_DIR/devices.tar.gz >> "$TARGET/debootstrap/devices.tar.gz" >> +cp $DEBOOTSTRAP_DIR/devices.tar.gz >> "$TARGET/debootstrap/devices.tar.gz" || true >> cp $SCRIPT >> "$TARGET/debootstrap/suite-script" >> echo "$ARCH" >"$TARGET/debootstrap/arch" >> echo "$SUITE" >> >"$TARGET/debootstrap/suite" >> -- >> 2.7.4 >> >> -- >> Alex Bennée >> >> >> ___ >> debhelper-devel mailing list >> debhelper-de...@lists.alioth.debian.org >> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debhelper-devel >> -- Alex Bennée
Bug#830869: debhelper: script fails first stage due to missing devices.tar.gz despite no longer being used
Alex Bennée <alex.ben...@linaro.org> writes: > Package: debhelper > Severity: normal > > Since bug #571136 was fixed we no longer actually need a devices.tar.gz > to build our tarball. However we can't just checkout the debootstrap > script and call directly because it still requires the tarball. One > possible fix is attached bellow, although a more thorough cleaning could > be done: I missed this when checking BTS for existing bugs but #770217 is related. It seems even the Make instruction rely on Debian-isms which isn't helpful for a script that should be platform agnostic. I suspect this means all the devices.tar.gz gubbins should be removed. -- Alex Bennée
Bug#830869: debhelper: script fails first stage due to missing devices.tar.gz despite no longer being used
Package: debhelper
Severity: normal
Since bug #571136 was fixed we no longer actually need a devices.tar.gz
to build our tarball. However we can't just checkout the debootstrap
script and call directly because it still requires the tarball. One
possible fix is attached bellow, although a more thorough cleaning could
be done:
---
Subject: [PATCH] debootstrap: fail gracefully copying devices.tgar.gz
The devices tarball only exists if you build the source code (as root)
before invoking the script. Since bug #571136 was fixed the
--second-stage doesn't even use the devices tarball so we can afford to
fail gracefully when it doesn't exist. In addition this allows us to
call the script under -e conditions from a straight checkout which is
useful in other cases.
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
---
debootstrap | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debootstrap b/debootstrap
index 2a959bb..4027a5d 100755
--- a/debootstrap
+++ b/debootstrap
@@ -635,7 +635,7 @@ if am_doing_phase first_stage; then
if ! am_doing_phase second_stage; then
cp "$0"
"$TARGET/debootstrap/debootstrap"
cp $DEBOOTSTRAP_DIR/functions"$TARGET/debootstrap/functions"
- cp $DEBOOTSTRAP_DIR/devices.tar.gz
"$TARGET/debootstrap/devices.tar.gz"
+ cp $DEBOOTSTRAP_DIR/devices.tar.gz
"$TARGET/debootstrap/devices.tar.gz" || true
cp $SCRIPT
"$TARGET/debootstrap/suite-script"
echo "$ARCH">"$TARGET/debootstrap/arch"
echo "$SUITE" >"$TARGET/debootstrap/suite"
--
2.7.4
--
Alex Bennée
Bug#742199: liburcu: Please multiarch this library
Package: liburcu1 Version: 0.7.7-1ubuntu1 Severity: normal File: liburcu Dear Maintainer, * What led up to the situation? I was trying to run a dynamically linked qemu with lttng tracing support in a chroot where I had bind mounted /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu into my guest architecture chroot. * What was the outcome of this action? Running qemu failed because liburcu-bp and liburcu-cds only exist in /usr/lib which I can't bind mount over the guest system. * What outcome did you expect instead? Being able to run a dynamically linked qemu I'm reporting this directly upstream as the problem exists in Debian as well. Cheers, Alex -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), (100, 'saucy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-18-generic (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liburcu1 depends on: ii libc6 2.17-93ubuntu4 liburcu1 recommends no packages. liburcu1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
