Zero-filling VM before compacting

Support Virtualization
1

I’m trying to shrink a dynamically-allocated Manjaro guest on a Windows 10 host in VirtualBox, and—after cleaning up unneeded files with the suggestions here—I’m stuck on the step of zero-filling the freed space. I think I should use zerofree to accomplish this, since I’ve made the maximum size of the VM bigger than physical drive on which it resides. Maybe that will be a problem anyway, I don’t know, but the zerofree page gives me to understand that it would potentially be a problem with alternative commands I’ve seen, like

dd if=/dev/zero of=zero.tmp bs=10M; rm -f zero.tmp

or

cat /dev/zero > zero.fill; sync; sleep 1; sync; rm -f zero.fill

Maybe not. Noob here.

After installing zerofree (pamac install zerofree), I’ve been trying to imitate this way of doing it on Ubuntu, but this zeroing doesn’t seem to work the same way in Manjaro. I first tried enabling the boot recovery mode by commenting out GRUB_DISABLE_RECOVERY=true in /etc/default/grub, followed by sudo update-grub. That worked, and pressing esc while booting showed that option in the GRUB menu. lsblk -f showed the disk at dev/sda1 of type ext4 mounted at the root. However, it is mounted read/write, so I get this output:

$ zerofree -v /dev/sda1
zerofree: filesystem /dev/sda1 is mounted rw

Uncommenting GRUB_ROOT_FS_RO=true in etc/default/grub did not change this.

I then bashed my head against mount and chroot a while, thinking the answer must be in there somewhere. I have not found it.

I also tried booting with a live iso in the VM’s “optical drive” and got variations on the same theme.

$ lsblk -f
NAME   FSTYPE FSVER  LABEL             UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squash 4.0                                                                 0   100% /run/miso/sfs/livefs
loop1  squash 4.0                                                                 0   100% /run/miso/sfs/mhwdfs
loop2  squash 4.0                                                                 0   100% /run/miso/sfs/desktopfs
loop3  squash 4.0                                                                 0   100% /run/miso/sfs/rootfs
sda                                                                                        
└─sda1 ext4   1.0                      462d6402-fb0a-4103-813c-82532e2008dc    455G     4%
sr0    iso966 Joliet MANJARO_XFCE_2132 2022-07-04-07-09-08-00                     0   100% /run/miso/bootmnt
$ manjaro-chroot -a
$ zerofree -v /dev/sda1
zerofree: filesystem /dev/sda1 is mounted rw
$ exit
$ mkdir /chroot
$ mount -r /dev/sda1 /chroot
$ zerofree -v /dev/sda1
bash: zerofree: command not found
$ chroot /chroot zerofree -v /chroot
zerofree: failed to determine filesystem mount state  /chroot
$ chroot /chroot zerofree -v /dev/sda1
zerofree: failed to determine filesystem mount state  /dev/sda1

And that’s where I’m at. Is there a way to do the chroot and point zerofree at the right mount or remount or bind or one of those other words? Maybe mount /usr/bin/zerofree in one place and run it on the rest of the drive in another? Is there a better way to accomplish the zeroing?

Just to complete the tale, I hope to go on to finish the process like given here. Yep, perhaps the moral of the story is that a 512 GB vmdk in VirtualBox is not the right call.

2

You probably would want to use

qemu-img(1) — Arch manual pages

to work with it - perhaps shrink it’s size to one that will fit on your disk once it is filled up (with zeroes)
but before you actually tried to fill it up

But this was just my first hunch.

The Arch wiki has more (and examples) on this - but I’m unable to look right now.

3

these approaches will both work - but I’m not sure whether the commands as given will.
because both methods of filling the disk will result in an error
the moment the disk is full and there is no space left.

not sure if the rm command is executed is what I mean
but you can always do that by hand …

But if the allocated size of the disk is greater than the actual space you have, you cannot use this approach - because this will result in the virtual disk reaching that maximum size

4

I got this to work just now by editing /etc/fstab to make the system boot up in read-only mode. I rebooted, hitting esc to get to the enabled Recovery Mode in the GRUB menu. This allowed me to run zerofree, and the size of my VM was not an issue. After that was done, I ended the session with halt and did my compacting on the host. I booted up the VM in Recovery Mode again to restore /etc/fstab to its prior state and rebooted again.

5

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.