0

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

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

parted test.img resizepart 2 1980MB

Then resize the filesystem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.