1

enter image description here

Ubuntu 16.04: A 64GB SD-Card image was created with the command:

date; sudo sh -c 'pv /dev/mmcblk0 >rpi4_Ubuntu18.1_64GB.image'; date

The rasbperry pi SD-Card is outfitted with Ubuntu 18.1

Can a Ubuntu 16.04 laptop:

  • mount the .image file?
  • run zerofree on the mounting point of the .image file?
  • unmount the .image file?

I am aware that it is possible to restore the image file to the SD-card and process the card with zerofree and snapping the image again. It would be nice to be able to process several .image files without restoring them to the SD card.

UPDATE: Test results

Image successfully mounted to /dev/loop9p2:

$ sudo losetup -P /dev/loop9 rpi4_Ubuntu18.1_64GB.image
$ ls -l /dev/loop9*
brw-rw---- 1 root disk   7, 9 Feb  2 19:12 /dev/loop9
brw-rw---- 1 root disk 259, 0 Feb  2 19:12 /dev/loop9p1
brw-rw---- 1 root disk 259, 1 Feb  2 19:12 /dev/loop9p2

zerofree failure:

$ zerofree -v /dev/loop9p2
zerofree: failed to open filesystem /dev/loop9p2

zerofree required sudo:

$ sudo zerofree -v /dev/loop9p2
14346339/14348998/15073019
  • 14346339 number of nonzero blocks encountered
  • 14348998 number of free blocks within the filesystem
  • 15073019 total number of blocks within the filesystem

Bonus: reduce image size with script pishrink

muru
  • 72,889
gatorback
  • 1,384
  • 23
  • 48

1 Answers1

3

zerofree operates on a compatible filesystem, no matter what is the underlying storage medium. The version of zerofree on my Debian 10 system supports ext2, ext3 and ext4 filesystems, so if the filesystem used on the SD-card is one of those, the answer would be yes.

But it looks like you have imaged the whole card, which may have more than one partition on it. If that's the case, you won't be able to just "mount the image file", as the mount command handles one filesystem at a time only. And on a whole-disk image, the partition table usually occupies some space at the beginning of the disk, so you might not be able to even access the first filesystem on the image by attempting to mount the whole-card image directly.

If your system has a losetup command that supports the -P option, you could do a losetup -P /dev/loop0 rpi4_Ubuntu18.1_64GB.image, which would give you devices like /dev/loop0p1, /dev/loop0p2 etc. - one for each partition in the image file. You could then mount each of those partition devices and run zerofree on them, then unmount and losetup -d /dev/loop0 to detach the loop device.

If your losetup command won't support the -P option, there is an alternative: the kpartx tool (sometimes packaged separately, sometimes as part of the device-mapper-multipath tools) can create mappings for individual partitions. In this case, you would first use losetup /dev/loop0 rpi4_Ubuntu18.1_64GB.image to attach the loop device, then kpartx -a /dev/loop to create mapping devices for each partition detected on it. The partition devices will be named a bit differently in this case: they will be /dev/mapper/loop0p1 etc. The mounting and zerofree procedure would be otherwise the same, but the clean-up after you've unmounted the filesystem would also require two steps: first kpartx -d /dev/loop0 to delete the partition mapping devices, then losetup -d /dev/loop0 to delete the main loop device.

telcoM
  • 96,466
  • losetup mapped the ext4 partition to /dev/loop9p2, which was mounted to /mnt/image. Why does zerofree -v /dev/loop9p2 return zerofree: filesystem /dev/loop9p2 is mounted rw? What message is returned when zerofree is successful? – gatorback Feb 02 '20 at 22:45
  • From the man page of zerofree: "filesystem has to be unmounted or mounted read-only for zerofree to work. It will exit with an error message if the filesystem is mounted writable." I actually thought you had some other reason to mount the filesystem beyond running zerofree. So unless you have some specific reason to mount the filesystem, don't mount it before running zerofree on it. – telcoM Feb 03 '20 at 00:01
  • Please consider commenting on test results at the bottom of the OP. – gatorback Feb 03 '20 at 00:48
  • Note that the /dev/loop9p2 device is accessible by root or members of the group disk only, and by default a regular user is neither. So you'll need to use sudo with the zerofree command. – telcoM Feb 03 '20 at 05:13