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

Bug #568021 reported by Steve Beattie on 2010-04-21
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
partman-auto (Ubuntu)
Medium
Colin Watson
Lucid
Medium
Colin Watson
partman-partitioning (Ubuntu)
Medium
Colin Watson
Lucid
Medium
Colin Watson

Bug Description

Binary package hint: debian-installer

ISO: netboot 20081029ubuntu101 i386

Attempted to do a side-by-side install in an instance with a 10gb disk that already had a side-by-side install on it, the partitioner reported "The minimum size for this partition is 2.1 GB (or -86%) and its maxnimum size is -2.3 GB." (see attached screenshot). It also offers up a new partition size of 0.1 GB.

Here's the state of the disk as reported by fdisk in cylinders:

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00006e23

   Device Boot Start End Blocks Id System
/dev/sda1 * 2048 499711 248832 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 501758 20969471 10233857 5 Extended
/dev/sda5 501760 11243946 5371093+ 83 Linux
/dev/sda6 11245568 20434943 4594688 83 Linux
/dev/sda7 20436992 20969471 266240 82 Linux swap / Solaris

Also attached are logfiles. I don't recall what the prior test install steps were that created such a partitioning, but d-i partman should not suggest resizing here nor should it report negative numbers.

Steve Beattie (sbeattie) wrote :
Steve Beattie (sbeattie) wrote :
Steve Beattie (sbeattie) wrote :
tags: added: iso-testing
Colin Watson (cjwatson) wrote :

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 ...

affects: debian-installer (Ubuntu) → partman-partitioning (Ubuntu)
Colin Watson (cjwatson) wrote :

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.

Steve Beattie (sbeattie) wrote :

Yes, I can, see attached.

Steve Beattie (sbeattie) wrote :

(And the corresponding partman from that run)

Colin Watson (cjwatson) wrote :

 * 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

Colin Watson (cjwatson) on 2010-04-23
Changed in partman-auto (Ubuntu Lucid):
status: New → Fix Committed
importance: Undecided → Medium
assignee: nobody → Colin Watson (cjwatson)
Changed in partman-partitioning (Ubuntu Lucid):
status: New → In Progress
Changed in partman-auto (Ubuntu Lucid):
milestone: none → ubuntu-10.04
Changed in partman-partitioning (Ubuntu Lucid):
importance: Undecided → Medium
milestone: none → ubuntu-10.04
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) on 2010-04-23
Changed in partman-partitioning (Ubuntu Lucid):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in partman-auto (Ubuntu Lucid):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in partman-partitioning (Ubuntu Lucid):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers