fail to install qubes-template-fedora-29 "Failed writing body"

[pixel fairy]

$ sudo qubes-dom0-update qubes-template-fedora-29
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
sys-firewall: command failed with code: 1
Fedora 25 - x86_64 - Updates 2.5 MB/s | 24 MB 00:09
Fedora 25 - x86_64 2.1 MB/s | 50 MB 00:24
Qubes Dom0 Repository (updates) 1.1 MB/s | 7.7 MB 00:06
determining the fastest mirror (8 hosts).. done.
Qubes Templates repository 82 kB/s | 10 kB 00:00
Last metadata expiration check: 0:00:00 ago on Thu Jan 3 16:35:37 2019.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
qubes-template-fedora-29 noarch 4.0.1-201812091508 qubes-templates-itl 1.3 G

Transaction Summary
================================================================================
Install 1 Package

Total download size: 1.3 G
Installed size: 1.3 G
DNF will only download packages for the transaction.
Downloading Packages:
[MIRROR] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm [Failed writing body (8615 != 16384)]
[FAILED] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm [Failed writing body (8615 != 16384)]

The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
Curl error (23): Failed writing received data to disk/application for https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm [Failed writing body (8615 != 16384)]
sys-firewall: command failed with code: 1

[799]

Am Fr., 4. Jan. 2019, 01:46 hat pixel fairy <pixel...@gmail.com> geschrieben:

$ sudo qubes-dom0-update qubes-template-fedora-29
[...]

Downloading Packages:
[MIRROR] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm [Failed writing body (8615 != 16384)]
[FAILED] qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm: Curl error (23): Failed writing received data to disk/application for https://mirrors.edge.kernel.org/qubes/repo/yum/r4.0/templates-itl/rpm/qubes-template-fedora-29-4.0.1-201812091508.noarch.rpm [Failed writing body (8615 != 16384)]

[...]

Do you have enough free space in sys-firewall (df -h)

- O

[pixel fairy]

That was the problem. made a clone of the template, gave it more system storage, and used that for sys-firewall, which worked.

[ryan...@ryantate.com]

I had this same issue and the same solution.

Here is my question: Why does Qubes require me to increase the size of the *system storage* in order to enable a larger download in the updateVM (sys-firewall)?

In other words, there is the sys-firewall "Private storage" (/dev/xvdb) and "System storage" (/dev/xvda3).

I would think the update downloads to this VM (which are just destinated for another vm, in this case dom0) should go in private storage. Private storage setting is particular to the vm and can be set while it is running, etc. Also it is a payload that should have nothing to do with the running system of the VM (at least not at that moment).

Instead, the downloads seem to be going to the system storage. This means, to make room for the updatevm download in sys-firewall, I have to go into the template settings, change the size -- which will affect every VM using this template, right? -- and then shut it down, and then reboot sys-firewall which is a big pain. In other words, enabling the download in dom0 means touching two other VMs just to get it working :-\

This seems wrong to me, because shouldn't downloads be kept far from the system files in sys-firewall? Is this an oversight or something intentional/required?