Description of problem: When having an appliance without the README.fixed file (just root, kernel, initrd) all libguestfs commands fail Version-Release number of selected component (if applicable): 1.28.5 Appliance: 1.28.1 How reproducible: always Steps to Reproduce: # ls -l total 335452 -rw-r--r-- 1 root root 1208832 Oct 18 13:21 initrd -rw-r--r-- 1 root root 6263432 Oct 18 13:21 kernel -rw-r--r-- 1 root root 978 Jan 19 19:30 README.fixed -rw-r--r-- 1 qemu qemu 4294967296 Oct 18 13:21 root # echo $LIBGUESTFS_PATH /usr/share/guestfs/appliance/ # pwd /usr/share/guestfs/appliance -> everythings fine: [...] ===== TEST FINISHED OK ===== Delete the README.fixed (like the gentoo ebuild installs it, under /usr/share/doc where it imho belongs): libguestfs-test-tool: error: cannot find any suitable libguestfs supermin, fixed or old-style appliance on LIBGUESTFS_PATH (search path: /usr/share/guestfs/appliance/) For some reason, libguestfs now looks for initramfs.x86_64.img and vmlinuz.x86_64 (I straced it) When creating two symlinks for those, everything goes completly mad, as it gets totally confused. Output libguestfs-test-tool then: http://pastebin.com/Gv1gRMrs OS here is Gentoo with the ebuilds from the tree, but I don't think this is a gentoo specific issue as depending on that readme file in the guestfs-appliance directory seems strange.
Ah, so this is the Gentoo problem? Indeed, libguestfs.git/src/appliance.c contains this function: static int contains_fixed_appliance (guestfs_h *g, const char *path, void *data) { return dir_contains_files (path, "README.fixed", "kernel", "initrd", "root", NULL); } All of those files (including README.fixed) need to exist on the $LIBGUESTFS_PATH for libguestfs to recognize that the directory contains a fixed appliance. > For some reason, libguestfs now looks for initramfs.x86_64.img > and vmlinuz.x86_64 (I straced it) That's because if you delete README.fixed, then libguestfs looks for what is called an "old style" appliance. This is totally obsolete, and in any case won't work with the fixed appliance that we supply on http://libguestfs.org/download/binaries/appliance So don't use this. Anyhow, I'm not really sure what the bug is here. README.fixed is part of the fixed appliance, so don't delete it. If you delete it, you'll have trouble as you've shown :-)
Convoluted upstream code here ... https://github.com/libguestfs/libguestfs/blob/master/src/appliance.c
For me, depending on a readme file to detect the appliance format is just wrong. For me, the gentoo ebuild does the right thing to put a readme into /usr/share/doc. It should imho either have a better detection logic (like actually looking at the files, like the header or something) or not caring about README.fixed; at least it should not require it's existence.
If we drop or change README.fixed then we end up breaking the existing appliances, which isn't nice. I see a few solutions here: Gentoo could carry this simple non-upstream patch: static int contains_fixed_appliance (guestfs_h *g, const char *path, void *data) { return dir_contains_files (path, - "README.fixed", "kernel", "initrd", "root", NULL); } Or Gentoo could not move the README.fixed file. Or we could work on something upstream (not sure exactly what -- I don't want to introduce yet another "type" of appliance, we have too many of them already). Or Gentoo could build a supermin appliance, but I appreciate that is likely to be difficult since supermin does make a lot of assumptions about binary packages which certainly don't apply to Gentoo.
Since the Gentoo bug was resolved (by not deleting README.fixed), I am closing this bug.