[Pkg-xen-devel] Bug#921590: xen-utils-4.11: pygrub bails out with "ImportError: No module named fsimage"
Axel Beckert
abe at debian.org
Thu Feb 7 01:13:56 GMT 2019
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
More information about the Pkg-xen-devel
mailing list