← Back to team overview

touch-packages team mailing list archive

  1. touch-packages team
  2. Mailing list archive
  3. Message #50463

[Bug 1415077] [NEW] resize2fs behavior differs greatly between trusty and utopic and vivid

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

I have a disk image created as part of lp:maas-images.
This process takes a cloud image (http://cloud-images.ubuntu.com) such as
http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.tar.gz .
Inside that .tar.gz is a .img file.  The .img file is operated on
by loop mount, chroot, apt-get install and other changes.

Immediately upon download and extraction of a pristine image, resize2fs output
on trusty, utopic and vivid differ.  A summary of differences:
 a.) 'resize2fs -P' on
     trusty (1.42.9) : 230329
     utopic (1.42.10): 236103
     vivid  (1.42.12): 236103
 b.) vivid resize2fs requires running 'e2fsck -f' first.

I do realize that 'resize2fs -P' reports "Estimated minumum size" and that a
difference of ~6k blocks doesn't seem like too big of a deal, but I'm seeing
this behavior on a much grander scale after doing some loop mount operations
on the disk image as part of the maas-images build process (lp:maas-images).
On that derived image, I see 'resize2fs -P' numbers like:
 trusty: 274500
 utopic: 358400
 vivid:  358400
The 83900 blocks out of a 358400 seems significant (23% of the fs size),
and results in the image appearing full on utopic/vivid, even though
a mount and df show only 74% full.

See below for more information.

## The original image as downloaded.
$ wget http://cloud-images.ubuntu.com/releases/14.04/release-20150123/ubuntu-14.04-server-cloudimg-amd64.tar.gz
$ tar -Sxvzf ubuntu-14.04-server-cloudimg-amd64.tar.gz
$ md5sum trusty-server-cloudimg-amd64.img
9fd4790c920aaeb0b503ebd2bf7f383c  trusty-server-cloudimg-amd64.img

## Trusty
$ resize2fs -P trusty-server-cloudimg-amd64.img
resize2fs 1.42.9 (4-Feb-2014)
Estimated minimum size of the filesystem: 230329

$ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
dumpe2fs 1.42.9 (4-Feb-2014)
http://paste.ubuntu.com/9898743/

## Utopic
$ resize2fs -P trusty-server-cloudimg-amd64.img
resize2fs 1.42.10 (18-May-2014)
Estimated minimum size of the filesystem: 236103

$ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
dumpe2fs 1.42.10 (18-May-2014)
http://paste.ubuntu.com/9898789/

## Vivid
$ resize2fs -P trusty-server-cloudimg-amd64.img
resize2fs 1.42.12 (29-Aug-2014)
Please run 'e2fsck -f trusty-server-cloudimg-amd64.img' first.

$ cp trusty-server-cloudimg-amd64.img trusty-server-cloudimg-amd64.img.dist
$ e2fsck -f trusty-server-cloudimg-amd64.img
e2fsck 1.42.12 (29-Aug-2014)
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
cloudimg-rootfs: 57885/90112 files (0.0% non-contiguous), 207837/360448 blocks

$ resize2fs -P trusty-server-cloudimg-amd64.img
resize2fs 1.42.12 (29-Aug-2014)
Estimated minimum size of the filesystem: 236103

$ md5sum trusty-server-cloudimg-amd64.img.dist trusty-server-cloudimg-amd64.img
9fd4790c920aaeb0b503ebd2bf7f383c  trusty-server-cloudimg-amd64.img.dist
c38a3ca8cba7996c85365e122175d013  trusty-server-cloudimg-amd64.img

$ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
dumpe2fs 1.42.12 (29-Aug-2014)
http://paste.ubuntu.com/9898831/

$ dumpe2fs trusty-server-cloudimg-amd64.img.dist | pastebinit
dumpe2fs 1.42.12 (29-Aug-2014)
http://paste.ubuntu.com/9898832/


## maas images image
## output below is for the maas build process output image
## This one specifically is an arm64 image, and the operations
## done (apt-get update) and such were done with the help chroot via
## qemu-static.

## build the image (works on trusty, fails due to resizing issues on utopic)
$ time maas-cloudimg2eph2 -vv --kernel=linux-generic --arch=arm64 \
  http://cloud-images.ubuntu.com/daily/server/vivid/20150125/vivid-server-cloudimg-arm64.tar.gz \
  /tmp/maas_final/vivid/arm64/20150125/root-image.gz \
  --krd-pack=linux-generic,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-kernel,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-initrd 2>&1 | tee out.log

$ pastebinit out.log
http://paste.ubuntu.com/9899165/

$ zcat /tmp/maas_final/vivid/arm64/20150125/root-image.gz > /tmp/root-
image

$ ls -l /tmp/root-image
-rw-rw-r-- 1 ubuntu ubuntu 1468006400 Jan 27 14:56 /tmp/root-image

## see attached root-image.e2image.xz
$ e2image /tmp/root-image /tmp/root-image.e2image
e2image 1.42.9 (4-Feb-2014)
$ xz /tmp/root-image.e2image


## Now, the above 'root-image' file on utopic, vivid and trusty.
##
## Trusty
$ resize2fs -P /tmp/root-image
resize2fs 1.42.9 (4-Feb-2014)
Estimated minimum size of the filesystem: 274500

$ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
  df /tmp/mp && sudo umount /tmp/mp
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/loop0       1356344 980284    359676  74% /tmp/mp

$ dumpe2fs /tmp/root-image | pastebinit
dumpe2fs 1.42.9 (4-Feb-2014)
http://paste.ubuntu.com/9899267/

## Utopic
$ resize2fs -P /tmp/root-image
resize2fs 1.42.10 (18-May-2014)
Estimated minimum size of the filesystem: 358400

$ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
  df /tmp/mp && sudo umount /tmp/mp
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/loop0       1356344 980284    359676  74% /tmp/mp

$ dumpe2fs /tmp/root-image | pastebinit
dumpe2fs 1.42.10 (18-May-2014)
http://paste.ubuntu.com/9899313/

## Vivid
$ resize2fs -P /tmp/root-image
resize2fs 1.42.12 (29-Aug-2014)
Estimated minimum size of the filesystem: 358400

$ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
  df /tmp/mp && sudo umount /tmp/mp
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/loop0       1356344 980284    359676  74% /tmp/mp

$ dumpe2fs /tmp/root-image | pastebinit
dumpe2fs 1.42.12 (29-Aug-2014)
http://paste.ubuntu.com/9899328/

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: e2fsprogs 1.42.12-1ubuntu1
ProcVersionSignature: User Name 3.18.0-9.10-generic 3.18.2
Uname: Linux 3.18.0-9-generic x86_64
ApportVersion: 2.15.1-0ubuntu2
Architecture: amd64
Date: Tue Jan 27 14:13:26 2015
Ec2AMI: ami-000000f5
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: aki-00000002
Ec2Ramdisk: ari-00000002
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: e2fsprogs
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: e2fsprogs (Ubuntu)
     Importance: Medium
         Status: Confirmed


** Tags: amd64 apport-bug ec2-images vivid

** Attachment added: "e2image output for maas arm64 image in description"
   https://bugs.launchpad.net/bugs/1415077/+attachment/4306584/+files/root-image.e2image.xz

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1415077

Title:
  resize2fs behavior differs greatly between trusty and utopic and vivid

Status in e2fsprogs package in Ubuntu:
  Confirmed

Bug description:
  I have a disk image created as part of lp:maas-images.
  This process takes a cloud image (http://cloud-images.ubuntu.com) such as
  http://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.tar.gz .
  Inside that .tar.gz is a .img file.  The .img file is operated on
  by loop mount, chroot, apt-get install and other changes.

  Immediately upon download and extraction of a pristine image, resize2fs output
  on trusty, utopic and vivid differ.  A summary of differences:
   a.) 'resize2fs -P' on
       trusty (1.42.9) : 230329
       utopic (1.42.10): 236103
       vivid  (1.42.12): 236103
   b.) vivid resize2fs requires running 'e2fsck -f' first.

  I do realize that 'resize2fs -P' reports "Estimated minumum size" and that a
  difference of ~6k blocks doesn't seem like too big of a deal, but I'm seeing
  this behavior on a much grander scale after doing some loop mount operations
  on the disk image as part of the maas-images build process (lp:maas-images).
  On that derived image, I see 'resize2fs -P' numbers like:
   trusty: 274500
   utopic: 358400
   vivid:  358400
  The 83900 blocks out of a 358400 seems significant (23% of the fs size),
  and results in the image appearing full on utopic/vivid, even though
  a mount and df show only 74% full.

  See below for more information.

  ## The original image as downloaded.
  $ wget http://cloud-images.ubuntu.com/releases/14.04/release-20150123/ubuntu-14.04-server-cloudimg-amd64.tar.gz
  $ tar -Sxvzf ubuntu-14.04-server-cloudimg-amd64.tar.gz
  $ md5sum trusty-server-cloudimg-amd64.img
  9fd4790c920aaeb0b503ebd2bf7f383c  trusty-server-cloudimg-amd64.img

  ## Trusty
  $ resize2fs -P trusty-server-cloudimg-amd64.img
  resize2fs 1.42.9 (4-Feb-2014)
  Estimated minimum size of the filesystem: 230329

  $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
  dumpe2fs 1.42.9 (4-Feb-2014)
  http://paste.ubuntu.com/9898743/

  ## Utopic
  $ resize2fs -P trusty-server-cloudimg-amd64.img
  resize2fs 1.42.10 (18-May-2014)
  Estimated minimum size of the filesystem: 236103

  $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
  dumpe2fs 1.42.10 (18-May-2014)
  http://paste.ubuntu.com/9898789/

  ## Vivid
  $ resize2fs -P trusty-server-cloudimg-amd64.img
  resize2fs 1.42.12 (29-Aug-2014)
  Please run 'e2fsck -f trusty-server-cloudimg-amd64.img' first.

  $ cp trusty-server-cloudimg-amd64.img trusty-server-cloudimg-amd64.img.dist
  $ e2fsck -f trusty-server-cloudimg-amd64.img
  e2fsck 1.42.12 (29-Aug-2014)
  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
  cloudimg-rootfs: 57885/90112 files (0.0% non-contiguous), 207837/360448 blocks

  $ resize2fs -P trusty-server-cloudimg-amd64.img
  resize2fs 1.42.12 (29-Aug-2014)
  Estimated minimum size of the filesystem: 236103

  $ md5sum trusty-server-cloudimg-amd64.img.dist trusty-server-cloudimg-amd64.img
  9fd4790c920aaeb0b503ebd2bf7f383c  trusty-server-cloudimg-amd64.img.dist
  c38a3ca8cba7996c85365e122175d013  trusty-server-cloudimg-amd64.img

  $ dumpe2fs trusty-server-cloudimg-amd64.img | pastebinit
  dumpe2fs 1.42.12 (29-Aug-2014)
  http://paste.ubuntu.com/9898831/

  $ dumpe2fs trusty-server-cloudimg-amd64.img.dist | pastebinit
  dumpe2fs 1.42.12 (29-Aug-2014)
  http://paste.ubuntu.com/9898832/

  
  ## maas images image
  ## output below is for the maas build process output image
  ## This one specifically is an arm64 image, and the operations
  ## done (apt-get update) and such were done with the help chroot via
  ## qemu-static.

  ## build the image (works on trusty, fails due to resizing issues on utopic)
  $ time maas-cloudimg2eph2 -vv --kernel=linux-generic --arch=arm64 \
    http://cloud-images.ubuntu.com/daily/server/vivid/20150125/vivid-server-cloudimg-arm64.tar.gz \
    /tmp/maas_final/vivid/arm64/20150125/root-image.gz \
    --krd-pack=linux-generic,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-kernel,/tmp/maas_final/vivid/arm64/20150125/vivid/generic/boot-initrd 2>&1 | tee out.log

  $ pastebinit out.log
  http://paste.ubuntu.com/9899165/

  $ zcat /tmp/maas_final/vivid/arm64/20150125/root-image.gz > /tmp/root-
  image

  $ ls -l /tmp/root-image
  -rw-rw-r-- 1 ubuntu ubuntu 1468006400 Jan 27 14:56 /tmp/root-image

  ## see attached root-image.e2image.xz
  $ e2image /tmp/root-image /tmp/root-image.e2image
  e2image 1.42.9 (4-Feb-2014)
  $ xz /tmp/root-image.e2image

  
  ## Now, the above 'root-image' file on utopic, vivid and trusty.
  ##
  ## Trusty
  $ resize2fs -P /tmp/root-image
  resize2fs 1.42.9 (4-Feb-2014)
  Estimated minimum size of the filesystem: 274500

  $ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
    df /tmp/mp && sudo umount /tmp/mp
  Filesystem     1K-blocks   Used Available Use% Mounted on
  /dev/loop0       1356344 980284    359676  74% /tmp/mp

  $ dumpe2fs /tmp/root-image | pastebinit
  dumpe2fs 1.42.9 (4-Feb-2014)
  http://paste.ubuntu.com/9899267/

  ## Utopic
  $ resize2fs -P /tmp/root-image
  resize2fs 1.42.10 (18-May-2014)
  Estimated minimum size of the filesystem: 358400

  $ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
    df /tmp/mp && sudo umount /tmp/mp
  Filesystem     1K-blocks   Used Available Use% Mounted on
  /dev/loop0       1356344 980284    359676  74% /tmp/mp

  $ dumpe2fs /tmp/root-image | pastebinit
  dumpe2fs 1.42.10 (18-May-2014)
  http://paste.ubuntu.com/9899313/

  ## Vivid
  $ resize2fs -P /tmp/root-image
  resize2fs 1.42.12 (29-Aug-2014)
  Estimated minimum size of the filesystem: 358400

  $ mkdir -p /tmp/mp && sudo mount -o loop,ro /tmp/root-image /tmp/mp &&
    df /tmp/mp && sudo umount /tmp/mp
  Filesystem     1K-blocks   Used Available Use% Mounted on
  /dev/loop0       1356344 980284    359676  74% /tmp/mp

  $ dumpe2fs /tmp/root-image | pastebinit
  dumpe2fs 1.42.12 (29-Aug-2014)
  http://paste.ubuntu.com/9899328/

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: e2fsprogs 1.42.12-1ubuntu1
  ProcVersionSignature: User Name 3.18.0-9.10-generic 3.18.2
  Uname: Linux 3.18.0-9-generic x86_64
  ApportVersion: 2.15.1-0ubuntu2
  Architecture: amd64
  Date: Tue Jan 27 14:13:26 2015
  Ec2AMI: ami-000000f5
  Ec2AMIManifest: FIXME
  Ec2AvailabilityZone: nova
  Ec2InstanceType: m1.small
  Ec2Kernel: aki-00000002
  Ec2Ramdisk: ari-00000002
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: e2fsprogs
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1415077/+subscriptions

Follow ups

References

  Thread Previous • Date Previous • • Thread Next