Disk overflow during image converting

[WhiteShadow]

During next guide:

Standalones and HVMs

During step:

Copy the root image file from the originating qube (here called untrusted) to a temporary location in dom0, typing this in a dom0 terminal:
qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.img

I copy 20G raw image, to dom0 with 40G in varlibqubes (rebooted and increased according another guide).
dom0 have enough free space for sure with ~10G extra free space to use after process.

Process result in lost of functionality of dom0 terminal, instability and crash of QubesOS installation.
After hard reset (can’t restart or shutdown normally) QubesOS boot into “recovery” mode.

What could be root of issue? should i convert .raw image format into .img format before copy to determine it final size?

[appih5587]

It would help if you could provide some dom0 diagnostic information - you might think that dom0 have enough free space for sure, but how have you actually checked ? Can you show the commands and outputs that led you to this assessment ?

[WhiteShadow]

@appih5587

It would help if you could provide some dom0 diagnostic information - you might think that dom0 have enough free space for sure, but how have you actually checked ?

I follow another source from forum in order to increase varlibqubes partition size:

Dom0 update fails

If you want to increase the size of dom0 to avoid this happening in the future, you can also increase the space allocated to dom0. For example: sudo lvresize --size 40G /dev/qubes_dom0/root sudo resize2fs /dev/mapper/qubes_dom0-root I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.

@appih5587

Can you show the commands and outputs that led you to this assessment ?

Device already formatted to new clean installation of QubesOS, I can perform same actions 3th time to collect same information from terminal after dom0 crash - but need any guide or steps to follow up

[appih5587]

I follow another source from forum in order to increase varlibqubes partition size:

The guide tells you how to resize your partition - it does not tell you how much you need to add to it.

Looking at your previous posts, I suspect that your dom0 was already nearly full, meaning that you don’t just need to resize it to 40G - but to add 40G. [note: using 40G as an example. As I said, without the logs showing the size of the file you are copying and your disk usage state before, I can’t give an exact result]

The docs do say:

About 60 GB of disk space is required for conversion. Use an external hard drive if needed. The final root.img size is 40 GB.

---

should i convert .raw image format into .img format before copy to determine it final size?

Either way qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.img just passes the data around - the file type should be totally unrelated

[WhiteShadow]

@appih5587

Either way qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.img just passes the data around - the file type should be totally unrelated

source type .raw, destination type .img .
Could .img format of same file be in higher size then original .raw?
How qvm-run --pass-io logic working?
Options I can think about:

1. copy .raw file and then change it to .img (both files exist on same moment in dom0)
2. use RAM to store step between .raw and .img state (expect high RAM usage)
3. convert .raw file to .img and then copy it (expect high disk usage in source VM)

I believe, but have no proof that qvm-run --pass-io handle tasks as option 1 and it may result in dom0 damage if dom0 free disk space isn’t at less twice then needed.

[rustybird]

A raw disk image is already the correct format, no need to convert it any further. The file extension doesn’t matter.

But it looks like you don’t have enough space in dom0. Try importing directly into the VM pool:

Importing a large (> dom0 disk size) standalone VM

It’s possible with a named pipe (FIFO). You have to do the volume import separately after VM creation, because qvm-create cannot automatically detect the correct volume size in this case so it has to be passed manually - which is only implemented for qvm-volume import. Continuing after the qemu-img convert step: [user@dom0 ~]$ mkfifo /tmp/fifo [user@dom0 ~]$ qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /tmp/fifo While this^ is still running, open another terminal and…

[appih5587]

Afaik file extentions are totally irrelevant here. You can think of them like fancy labels, no different from the filename itself.

You could as well run qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.fuckyeah, it would change nothing.