1

I'm trying to resize a disk image (Raspbian image) on disk.

The trouble is, when I attempt to boot the RaspberryPi from the resized image (after writing to an SD card) I get:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block

(Sorry I didn't capture exact error -- I can update if it's relevant).

I think this is because I'm not updating the partition table, here's the background:

Initial image partitions

Here's the initial partitions:

gregmac@test1:~/image$ fdisk -l test.img

Disk test.img: 1389 MB, 1389363200 bytes
255 heads, 63 sectors/track, 168 cylinders, total 2713600 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: 0x5a7089a1

   Device Boot      Start         End      Blocks   Id  System
test.img1            8192      137215       64512    c  W95 FAT32 (LBA)
test.img2          137216     2713599     1288192   83  Linux

Note that initially the disk size is 1389MB.

Resize

Add 500MB

gregmac@test1:~/image$ truncate -s +500M test.img
gregmac@test1:~/image$ fdisk -l test.img

Disk test.img: 1913 MB, 1913651200 bytes
255 heads, 63 sectors/track, 232 cylinders, total 3737600 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: 0x5a7089a1

  Device Boot      Start         End      Blocks   Id  System
test.img1            8192      137215       64512    c  W95 FAT32 (LBA)
test.img2          137216     2713599     1288192   83  Linux

Looks good - New total size is 1913 MB.

Resize filesystem

So now I want to resize the second partition to use up the new space.

Create a loop device using the offset (512 units per sector * 137216 sectors):

gregmac@test1:~/image$ sudo losetup -f --show test.img -o $((512*137216))
/dev/loop0

Run e2fsck (because resize2fs complains if you don't) and resize2fs:

gregmac@test1:~/image$ sudo e2fsck -f /dev/loop0
e2fsck 1.42.9 (4-Feb-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
/dev/loop0: 37167/80640 files (0.2% non-contiguous), 250800/322048 blocks

gregmac@test1:~/image$ sudo resize2fs /dev/loop0
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on /dev/loop0 to 450048 (4k) blocks.
The filesystem on /dev/loop0 is now 450048 blocks long.

Looks like the resize worked correctly. I ran e2fsck again just in case, and though it sees the new blocks nothing else indicates a problem:

gregmac@test1:~/image$ sudo e2fsck -f /dev/loop0
e2fsck 1.42.9 (4-Feb-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
/dev/loop0: 37167/112896 files (0.2% non-contiguous), 252824/450048 blocks

Also worth nothing, I can mount this loop device:

gregmac@test1:~/image$ sudo mount /dev/loop0 temp-mnt
gregmac@test1:~/image$ ls temp-mnt/
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

And df -h shows the correct sizes:

Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      1.7G  928M  667M  59% /home/gregmac/image/temp-mnt

Partition table

Here's what I think is the problem: the partition table is untouched:

gregmac@test1:~/image$ fdisk -l test.img

Disk test.img: 1913 MB, 1913651200 bytes
255 heads, 63 sectors/track, 232 cylinders, total 3737600 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: 0x5a7089a1

   Device Boot      Start         End      Blocks   Id  System
test.img1            8192      137215       64512    c  W95 FAT32 (LBA)
test.img2          137216     2713599     1288192   83  Linux

Note the end and blocks value is still what is was before -- not accounting for the increase in space. I believe the End value should be 3737599 (total sectors minus 1), but I'm not 100% clear on that.

I was expecting that resize2fs would update the partition table, but clearly it doesn't.

So..

Worth also mentioning that if I skip the resize steps, this image boots just fine.

The trouble is I'm trying to do this in a script as part of an automated build, and the stock Raspbian image doesn't have enough free disk space to install everything I need.

  • Assuming the partition table is the cause, how can I get it to update?
  • How do I do that in a scriptable way? (it can't require interactive user input)

  • If the partition table is not the cause, what is?

1 Answer 1

1

Before you resize the filesystem, you need to resize the underlying partition.

parted test.img resizepart 2 1980MB

Then resize the filesystem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .