If you want more output and sanity checking:
- progress indicator (libvirt_compress uses
pvto invent a progress
indicator, I think, might be suitable for adjustment / copy / paste,
otherwise “mygrep” for
pvto see other use examples of
- check size before running (and output)
- check size after running
- output human readable summary
- output size in GB X.XX or so
- Should be smaller. If not, virt-sparsify failed, obviously. In that
case, make the build script fail. Add an
error. (Might happen in
future versions of virt-sparsify or its dependencies or due to build
But all of that is very optional. (Meaning: can merge either way even as
is.) Seems pretty good. Perhaps I’ll include even in Whonix 14.
Maybe even decreases build times (libvirt compression)? (Unimportant
Decreases upload time due to smaller sizes, and download times for
everyone, which is amazing!
Nice! What is the procedure now? Do I suggest this script on phabricator? Or do we continue the discussion here?
A phabricator ticket would be good as reminder (used as todo list).
Description can be minimal. With link to this forum discussion.
Script on phabricator: no need.
Could you post a github pull request (or git push a git branch somewhere
(github if you don’t mind)) please?
Discussion can continue here.
It exits non-zero if file doesn’t exist, yes. The command can be run in verbose mode (-v option) which might be helpful.
-v sounds good in theory. How does the output look like?
Users love some sort of progress indicator. Otherwise they have a
nervous ctrl+c finger.
Note that virt-sparsify can be run against any kind of file, it doesn’t seem to check if the file is a virtual disk image. Not sure of the implications if the file is not a virtual disk, probably none (it runs normally and then quits with “
Sparsify in-place operation completed with no errors”, although the shrinking is not performed.
Ok. Can live with that.
Yes, but I was thinking more of the checks performed in the main() function (
if [ "$WHONIX_BUILD_FLAVOR" = "whonix-gateway" ]; then), do we need to add more checking?
Ah. I guess no. Should be quite similar to
2300_run-chroot-scripts-post-d. So if it is as good as that one,
should be alright.
Regarding the unmounting bug, I will try to give a few more tries and open a new thread. But maybe worth taking into account the following:
- All the build is done in a virtual machine (virtualbox)
- The VM vdi is located on an external hdd which is formatted in NTFS (maybe kpartx doesnt like that?)
This might make a difference indeed even if it should not.
- the VM already has a user “user” with password “changeme”
For now, the only solution I found is to reboot the machine… It only happened with the Workstation, not t he Gateway.
With and without the added 2350 script.
Yes. I doubt the new script is fault.