d-i partman reports negative %/size on guided resize where not enough space is available

If you have time - could you put 'set -x' at the top of /lib/partman/lib/resize.sh before starting the partitioner and get new logs, please? Otherwise I'll try to reproduce this but I'm hoping this way will be quicker in wallclock time as I'm about to go to bed ...

I know a likely workaround, by the way, but that would just leave out whatever partition's going wrong here, and so I want to know why the number's coming out negative. /var/log/partman doesn't seem to show it clearly, which I think means it must be in get_ext2_resize_range around where it calls tune2fs. A shell trace should clarify this.

Yes, I can, see attached.

(And the corresponding partman from that run)

 * cjwatson scratches head over sbeattie's d-i resizing bug
<cjwatson> AFAICT, tune2fs is just lying
<sbeattie> cjwatson: I still have that vm up if you want me to grab any more diagnostic info from it.
<cjwatson> it's saying block count 2497791, block size 4096. that's about 10GB - on a partition around 250MB long
<cjwatson> sbeattie: currently trying to work out what I would need, and if I can reproduce it locally instead
<sbeattie> cjwatson: well, tune2fs isn't lying; I just tried manually mounting the partition and the kernel wouldn't mount it, saying the same thing (the block count exceeds the size of the device)
<cjwatson> oh!
<cjwatson> so the fs there is bogus? do you know why?
<cjwatson> if it's genuinely bogus, I can certainly make d-i safe against that
<cjwatson> I just didn't want to do so when the effect would be hiding some other problem
<sbeattie> cjwatson: I don't know why it's bogus.
<cjwatson> would you agree that it would be best to just guard against this, and otherwise write the underlying problem off as probably transient until reproduced?
<cjwatson> or is the bogus fs reproducible by some sequence of installation steps?
<sbeattie> cjwatson: writing it off as a transient is fine by me; I don't recall how I got it into this state.
<cjwatson> so then I'll just error out if the size reported by ntfsresize or tune2fs is outside [minsize, cursize] as per the partition constraints
<cjwatson> which would result in that partition just not being resizable, which I think is the correct response here

This bug was fixed in the package partman-auto - 89ubuntu8

---------------
partman-auto (89ubuntu8) lucid; urgency=low

  * Explicitly handle failures from get_real_resize_range (LP: #568021).
 -- Colin Watson <email address hidden> Fri, 23 Apr 2010 11:44:29 +0100

This bug was fixed in the package partman-partitioning - 72ubuntu4

---------------
partman-partitioning (72ubuntu4) lucid; urgency=low

  * Check that minimum filesystem sizes reported by tune2fs and ntfsresize
    are between the minimum partition size and the current partition size;
    if not, refuse to resize the partition at all (LP: #568021).
 -- Colin Watson <email address hidden> Fri, 23 Apr 2010 11:54:21 +0100