Hide Forgot
Description of problem: In a fresh F15 install: T, [2011-04-20T08:52:34.711108 #11402] TRACE -- : GFS: supermin helper [00556ms] visiting /usr/lib64/guestfs/supermin.d T, [2011-04-20T08:52:34.711242 #11402] TRACE -- : GFS: supermin helper [00556ms] visiting /usr/lib64/guestfs/supermin.d/base.img T, [2011-04-20T08:52:37.325705 #11402] TRACE -- : GFS: supermin helper [03172ms] visiting /usr/lib64/guestfs/supermin.d/daemon.img T, [2011-04-20T08:52:37.334953 #11402] TRACE -- : GFS: supermin helper [03181ms] visiting /usr/lib64/guestfs/supermin.d/hostfiles T, [2011-04-20T08:52:47.898170 #11402] TRACE -- : GFS: febootstrap-supermin-helper: ext2fs_mkdir: /var/lock/lvm: Ext2 inode is not a directory F, [2011-04-20T08:52:47.899766 #2115] FATAL -- : external command failed, see earlier error messages (Guestfs::Error) In F15 /var/lock is a symlink -> /var/run. It appears that /var/lock contains files (from another package)? These are being populated before /var/run is created. Version-Release number of selected component (if applicable): 1:libguestfs-1.10.1-1.fc15.x86_64 systemd-24-1.fc15.x86_64 filesystem-2.4.40-1.fc15.x86_64 How reproducible: Only in F15 fresh install. On upgrading from F14, /var/lock is NOT a symlink.
Created attachment 493366 [details] /usr/lib64/guestfs/supermin.d/hostfiles
The relevant section is: /var/lock /var/lock/lvm /var/lock/subsys [...] /var/run If /var/lock on the host is a symbolic link to /var/run, then when creating the ext2 image we will create /var/lock -> /var/run, then try to populate /var/lock (eg. /var/lock/lvm) but because /var/run doesn't exist yet this operation will fail. The failure would be consistent with the error seen.
(In reply to comment #2) > The relevant section is: > > /var/lock > /var/lock/lvm > /var/lock/subsys > [...] > /var/run > > If /var/lock on the host is a symbolic link to /var/run, then > when creating the ext2 image we will create /var/lock -> /var/run, > then try to populate /var/lock (eg. /var/lock/lvm) but because > /var/run doesn't exist yet this operation will fail. The > failure would be consistent with the error seen. This explanation is not quite correct. /var/lock is a symlink to -> /run/lock /run/lock *does* exist. However the febootstrap-supermin-helper ext2 handling code tries to create the lvm object inside /var/lock which is a symlink (not a directory) and ext2 library barfs at this.
Verified this bug happens on a brand new F15 beta install.
Adding the following patch to febootstrap fixes the problem for me: http://git.annexia.org/?p=febootstrap.git;a=commitdiff;h=b6cce31ec4d8232d6400fe4fe915f53d285a3b4f Also fix was verified by mgoldmann.
febootstrap-3.4-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/febootstrap-3.4-2.fc15
Package febootstrap-3.4-2.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing febootstrap-3.4-2.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/febootstrap-3.4-2.fc15 then log in and leave karma (feedback).
febootstrap-3.4-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.