1

I tried the process from this post resize partition on an image file. I didn't succeed in understanding why it goes wrong in my case.

I produced a 8GB image using dd. The image contains two partitions.

I map the image with losetup -P /dev/loop0 $image-file.

Then:

resize2fs /dev/loop0p2 4000M
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/loop0p2 to 1536000 (4k) blocks.
The filesystem on /dev/loop0p2 is now 1536000 (4k) blocks long.

e2fsck -f /dev/loop0p2 ->>> clean

parted /dev/loop0
(parted) resizepart 2 4000MB` ; print gives 4GB partition
(parted) quit

partprobe -s /dev/loop0

lsblk /dev/loop0
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0       7:0    0   7,5G  0 loop 
├─loop0p1 259:2    0   256M  0 loop 
└─loop0p2 259:3    0   3,5G  0 loop 

root@O3:/home/m/tmp# e2fsck -f /dev/loop0p2
e2fsck 1.44.1 (24-Mar-2018)
The filesystem size (according to the superblock) is 1903360 blocks
The physical size of the device is 1154143 blocks
**Either the superblock or the partition table is likely to be corrupt**!
Abort? yes

The partition resize with parted creates the inconsistency, because after resize2fs the e2fsck is clean.

Any ideas to explore to be able to shrink the image file?

  • Try parted /dev/loop0 ... – sudodus Jun 30 '20 at 16:32
  • I resized part #2, the first part is tiny, it didn't change. I edited the question to indicate that parted print shows a loop0p2 partition of 5GB before quit. – sugarman Jun 30 '20 at 16:33
  • I will add it right away. Quickly: resizepart 1 makes sense because inside loop0p2 there is only one partition, I did parted /dev/loop0p2 – sugarman Jun 30 '20 at 16:35
  • I am 'only' relating to how to do things with 'real' drives - and you should poiint parted to the 'whole drive' not to a partition, Then in parted use the commands to shrink the partition(s). But first you should shrink the file system. You could try if it works wirh gparted, which will do it in one step (if it can handle this virtual drive). – sudodus Jun 30 '20 at 16:36
  • In my previous question unix.stackexchange.com/questions/595641/… @fra-san wrote in the 2nd answer to first parted resize a partiton and then resize2fs – sugarman Jun 30 '20 at 16:55
3

Thank you @sudodus and @fra-san.

I think there is a compatibility issue when combining resize2fs and parted for shrinking a fs/partition. resize2fs uses 4k blocks, when parted uses Byte or MB, GB etc.

I eventually found another way to shrink the 2nd partition: gnome-disks. It is provided with Linux Mint and works pretty well. Where parted and gparted failed in shrinking the 2nd partition, gnome-disks succeeded in resizing both fs and partition, in one operation.

After the fs/partition shrink, there was trailing empty space in loop0p2. I want to shrink the image file. So, I did:

root@O3:/home/m# fdisk -l /dev/loop0
Disk /dev/loop0: 7,5 GiB, 8068792320 bytes, 15759360 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
Disklabel type: dos
Disk identifier: 0x8889db7f

Device       Boot  Start     End Sectors  Size Id Type
/dev/loop0p1        8192  532479  524288  256M  c W95 FAT32 (LBA)
/dev/loop0p2      532480 8355839 7823360  3,7G 83 Linux

truncate size? (8192 + 524288 + 7823360) * 512 = 4278190080 B

truncate --size=4278190080 image-file.img

After mapping again the resulting image file to loop0, no more fs/partition errors.

  • 1
    Glad to see you worked it out and thank you for taking the time to self-answer your question! – fra-san Jun 30 '20 at 20:15
  • Thank you for your concern – sugarman Jun 30 '20 at 20:23
  • +1 and good luck with the modified images :-) – sudodus Jul 1 '20 at 8:03
  • I updated the question. I didn't notice at the beginning, the shrunk partition loop0p2 has a consistency problem – sugarman Jul 8 '20 at 7:55

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.