livecd-creator seems to leave some tmp files around in /tmp after completing. There seem to be two types: /tmp/tmpXXXXX which seem to contain installroot yum stanzas like: [main] installroot=/var/tmp/imgcreate-SXESBO/install_root cachedir=/var/cache/yum plugins=0 reposdir= failovermethod=priority keepcache=1 and /tmp/resize-image-* files which seem to be sparse large image files. It would be nice if it would clean up any temp files it creates. ;)
We should only be leaving them behind in cases where something fails I think. But I'm now seeing a resize-image- file left on my box... will see why that's started to happen as it should only happen if the fsck fails and we then raise an error. In which case we're leaving the file behind intentionally so that you can give it to sandeen for resize2fs debugging :)
Okay, I see one way we would have left an image behind without raising an exception; fixed it to raise an exception (as it's a failure mode) So should be good in git (and for 026)
I've seen this to: All my last x86_64 images failed to resize. I've described this on the mailing list: > error: /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora: import read failed(-1). > e2fsck 1.41.8 (11-July-2009) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > F12-KDE-016-x86_: 88827/196608 files (0.1% non-contiguous), > 533419/786432 blocks e2image 1.41.8 (11-July-2009) > resize2fs 1.41.8 (11-July-2009) > /sbin/resize2fs: No space left on device while trying to > resize /daten/LIVECD/tmp/imgcreate-Z0Z6zr/tmp-hVegM7/ext3fs.img > Please run 'e2fsck > -fy /daten/LIVECD/tmp/imgcreate-Z0Z6zr/tmp-hVegM7/ext3fs.img' to fix > the filesystem after the aborted resize operation. Resizing the > filesystem > on /daten/LIVECD/tmp/imgcreate-Z0Z6zr/tmp-hVegM7/ext3fs.img to 532899 > (4k) blocks. e2fsck 1.41.8 (11-July-2009) Pass 1: Checking inodes, > blocks, and sizes Pass 2: Checking directory structure Pass 3: > Checking directory connectivity Pass 4: Checking reference counts > Pass 5: Checking group summary information F12-KDE-016-x86_: > 88827/196608 files (0.1% non-contiguous), 533419/786432 blocks > e2image 1.41.8 (11-July-2009) resize2fs 1.41.8 (11-July-2009) > The filesystem is already 786432 blocks long. Nothing to do! https://www.redhat.com/archives/fedora-livecd-list/2009-August/msg00005.html With the last commit livecd-creator is now failing due to this (as expected): passwd: Success e2fsck 1.41.8 (11-July-2009) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information F12-KDE-033-x86_: 86374/196608 files (0.1% non-contiguous), 529539/786432 blocks e2image 1.41.8 (11-July-2009) resize2fs 1.41.8 (11-July-2009) /sbin/resize2fs: No space left on device while trying to resize /daten/LIVECD/tmp/imgcreate-zSQ6P2/tmp-PbQjt_/ext3fs.img Please run 'e2fsck -fy /daten/LIVECD/tmp/imgcreate-zSQ6P2/tmp-PbQjt_/ext3fs.img' to fix the filesystem after the aborted resize operation. Resizing the filesystem on /daten/LIVECD/tmp/imgcreate-zSQ6P2/tmp-PbQjt_/ext3fs.img to 529026 (4k) blocks. /usr/lib/python2.6/site-packages/imgcreate/errors.py:45: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 return unicode(self.message) Error creating Live CD : resize2fs returned an error (1)! image to debug at /tmp/resize-image-fp2RvS
All my nightly-spins composes give this error, so if it's a failure condition, it's happening for me on every spin. ;(
Jepp, i686 is now failing to due to: /sbin/resize2fs: New size smaller than minimum (514552) I always considered this as a warning, not a real error. However, it's enough to let the script fail now.
If resize2fs is exiting with a non-zero exit code, then yep, it's a failure condition. If you file something against e2fsprogs, esandeen will likely knock it out. But that confirms we're not now leaving behind temp files we shouldn't :)
But isn't that up to how livecd-creator calls resize2fs? I mean, if livecd-creator want's to resize the image smaller than the possible minimum size isn't it a false call from livecd-creator?