Package: xen-utils-4.11,xen-utils-common Version: 4.11.1-1 Severity: serious Control: affects -1 xen-tools
Hi, both, /usr/lib/xen-4.11/bin/pygrub as well as /usr/bin/pygrub bail out for me as follows on Buster: # /usr/bin/pygrub Traceback (most recent call last): File "/usr/bin/pygrub", line 23, in <module> import fsimage ImportError: No module named fsimage This is a regression from Stretch and breaks many DomUs after upgrade as well as most DomUs generated with xen-tools' defaults (which uses pygrub). It especially severly harms the release testing for the xen-tools pending 4.8 release. :-( This seems related (and partially mentioned), but not identical to #912441 as pygrub is present for me, just not working at all. Which means: This bug report is about pygrub being present, but completely broken. There aren't many differences between pygrub in Stretch and Buster: 1c1 < #! /usr/bin/python2.7 --- > #! /usr/bin/python 22,23d21 < < sys.path.insert(1, sys.path[0] + '/../lib/python') That's all differences. The latter removal of a search path is very likely the reason for this issue. (Already hinted towards that in #912441, too.) As a (very ugly) workaround I tried to copy over pygrub from a Stretch Dom0, i.e. from xen-utils-4.8, but this helped only partially: # pygrub Traceback (most recent call last): File "/usr/bin/pygrub", line 25, in <module> import fsimage ImportError: libfsimage.so: cannot open shared object file: No such file or directory Note the different error message on the last line. Now it doesn't find libfsimage.so. "strace /usr/lib/xen-4.11/bin/pygrub" reveals that pygrub from xen-utils-4.8, when copied onto a Buster system, indeed tries to access that /usr/lib/xen-4.11/lib/python/fsimage.so, just doesn't use it: # strace /usr/lib/xen-4.11/bin/pygrub |& fgrep -A20 lib/python/fsimage.so --color openat(AT_FDCWD, "/usr/lib/xen-4.11/bin/../lib/python/fsimage.so", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=16128, ...}) = 0 openat(AT_FDCWD, "/usr/lib/xen-4.11/bin/../lib/python/fsimage.so", O_RDONLY|O_CLOEXEC) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\21\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0644, st_size=16128, ...}) = 0 mmap(NULL, 18352, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f1af1082000 mmap(0x7f1af1083000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f1af1083000 mmap(0x7f1af1084000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f1af1084000 mmap(0x7f1af1085000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f1af1085000 close(4) = 0 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=49493, ...}) = 0 mmap(NULL, 49493, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f1af0f92000 close(4) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libfsimage.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib/x86_64-linux-gnu/tls/x86_64/x86_64", 0x7fff92e70430) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libfsimage.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fff92e70430) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/x86_64/libfsimage.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fff92e70430) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/tls/libfsimage.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/lib/x86_64-linux-gnu/tls", 0x7fff92e70430) = -1 ENOENT (No such file or directory) Reason for this seems to be that the linker doesn't find libfsimage.so: # ldd /usr/lib/xen-4.11/lib/python/fsimage.so linux-vdso.so.1 (0x00007fff1bbb5000) libfsimage.so => not found libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f657bd3a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f657bb72000) /lib64/ld-linux-x86-64.so.2 (0x00007f657bd7a000) What finally works is using pygrub from Stretch _and_ setting LD_LIBRARY_PATH=/usr/lib/xen-4.11/lib/x86_64-linux-gnu: # env LD_LIBRARY_PATH=/usr/lib/xen-4.11/lib/x86_64-linux-gnu pygrub Usage: /usr/bin/pygrub [-q|--quiet] [-i|--interactive] [-l|--list-entries] [-n|--not-really] [--output=] [--kernel=] [--ramdisk=] [--args=] [--entry=] [--output-directory=] [--output-format=sxp|simple|simple0] [--offset=] <image> So using that LD_LIBRARY_PATH when calling xl and the pygrub from stretch, I can boot pygrub/grub-legacy based DomUs again. Even if this doesn't affect the general usage of Xen, this is a severe regression from Stretch and needs to be fixed for Buster. Hence the RC severity. Another reason for RC severity is that shipped binaries and libraries have non-working loading of dynamic libraries, i.e. some kind of missing dependencies. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages xen-utils-4.11 depends on: ii libc6 2.28-5 ii libncurses6 6.1+20181013-1 ii libtinfo6 6.1+20181013-1 ii libxenevtchn1 4.11.1-1 ii libxengnttab1 4.11.1-1 ii libxenmisc4.11 4.11.1-1 ii libxenstore3.0 4.11.1-1 ii libxentoolcore1 4.11.1-1 ii libxentoollog1 4.11.1-1 ii libyajl2 2.1.0-3 ii python 2.7.15-4 ii xen-utils-common 4.11.1-1 Versions of packages xen-utils-4.11 recommends: ii bridge-utils 1.6-2 ii grub-xen-host 2.02+dfsg1-10 ii qemu-system-x86 1:3.1+dfsg-2+b1 ii xen-hypervisor-4.11-amd64 [xen-hypervisor-4.11] 4.11.1-1 Versions of packages xen-utils-4.11 suggests: pn ovmf <none> ii qemu-utils 1:3.1+dfsg-2+b1 ii seabios 1.12.0-1 -- no debconf information