read ERROR:No such file or directory

[Wayne Workman]

Server

• FOG Version: git commit ac340187ca9f1f8c0a6d09724367818a05c77186 from the working branch in github.
• OS: Debian 8

Client

• OS: Windows 10 Enterprise in a VM.

Description

I’m getting this error sometimes during image deployment. I think it has something to do with how I’m capturing the image. I should elaborate.

I have a libvirtd host that runs Debian, which runs some VMs, a fog server, and three fog test hosts. I’ve scripted via BASH restoring a snapshot of Windows 10 onto testHost1, and then scheduling it for capture via the API. When this completes, a “blank” snapshot is applied to all three testHosts and then each is scheduled for image deployment using the newly captured image. This is for automatically testing FOG’s functionality - which is a work in progress.

testHost1 has a 50GB .qcow2 disk, testHost2 has a 45GB disk, testHost3 has a 55GB disk. The image is set to single disk - resizable and Windows 10.

Here’s the script that does the automation, it’s a wreak right now but it does go through the process properly. The below script calls a few other scripts, all are in that repository.
https://github.com/wayneworkman/fog-community-scripts/blob/master/fogAutomatedTesting/test_functionality.sh

My automated tests have bombed three times in a row now, so I’m posting the error here for transparency, and appreciate any help. Below also is my disk configuration for the VMs. I don’t think it’s the scripts as they do work sometimes. I think it’s something to do with the snapshots. Or maybe this working version is just busted, which isn’t a big deal.

Image directory listing from the test fog server:

root@testServer:/images/win10# pwd
/images/win10
root@testServer:/images/win10# ls -laht
total 5.0G
-rwxrwxrwx 1 root root 4.7G May  1 21:19 d1p2.img
drwxrwxrwx 5 fog  root 4.0K May  1 21:19 ..
drwxrwxrwx 2 root root 4.0K May  1 21:19 .
-rwxrwxrwx 1 root root 299M May  1 21:04 d1p1.img
-rwxrwxrwx 1 root root  190 May  1 21:03 d1.minimum.partitions
-rwxrwxrwx 1 root root 1.0M May  1 21:03 d1.mbr
-rwxrwxrwx 1 root root   15 May  1 21:02 d1.original.fstypes
-rwxrwxrwx 1 root root    0 May  1 21:02 d1.original.swapuuids
-rwxrwxrwx 1 root root  190 May  1 21:02 d1.partitions
-rwxrwxrwx 1 root root    3 May  1 21:02 d1.fixed_size_partitions

d1.minimum.partitions

label: dos
label-id: 0xc6b67a14
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=    22970438, type=7
root@testServer:/images/win10# cat d1.original.fstypes 
/dev/sda2 ntfs

d1.original.fstypes

/dev/sda2 ntfs

d1.partitions

label: dos
label-id: 0xc6b67a14
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=     1024000, type=7, bootable
/dev/sda2 : start=     1026048, size=   103831552, type=7

d1.fixed_size_partitions

:1

Disk configuration.

[Wayne Workman]

The VM that fails to image does boot, albeit the HDD is not expanded because it didn’t get that far in the deploy.

[Tom Elliott]

If you can capture what’s actually failing (causing the boot loop) it would go a lot further, of course.

The Warning is not what’s causing the boot loop, something else further down the line is. The warning is just meant to show that there was a problem, which I suspect is due to partclone failing to realize the end of the data. (Probably in relation to using ZSTD now).

[Wayne Workman]

I switched from ZSTD to gzip and the capture and deploy went without issue. The problem is definitely associated with the ZSTD feature.

[Tom Elliott]

@Wayne-Workman Can you explain exactly how you came to this determination? You replaced zstdmt with pigz in the appropriate spots?

I’ve not seen any problems with Zstd AS the compression medium. The only time, from my experience, that I’ve seen this problem is if the image was originally captured (as is the case any time before 1.3.5-RC-9) in PIGZ format.

I ask because, this problem is not seeming to be all scenarios and Zstd is supposed to be able to decompress (and it does succeed even in this case) Gzip files.

I am asking for specificity because I can easily adjust the code to use pigz if the format is originally pigz captured.

[Tom Elliott]

Just for clarity, I’m currently rebuilding the init’s using pigz to decompress gzip based images.

[Tom Elliott]

Init’s are rebuilt and in the binaries1.4.0-RC-9.3.zip file.

You can try with:

wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

[Wayne Workman]

@Tom-Elliott When I said I changed from zstd to gzip, I changed it in the image settings via the GUI, pictured below. Then I recaptured & redeployed and it worked fine.