Comment 8 for bug 568021

 * 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