read ERROR:No such file or directory
- FOG Version: git commit
workingbranch in github.
- OS: Debian 8
- OS: Windows 10 Enterprise in a VM.
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
libvirtdhost 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.
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
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
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
- FOG Version: git commit
@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.
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
Just for clarity, I’m currently rebuilding the init’s using pigz to decompress gzip based images.
@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.
I switched from ZSTD to gzip and the capture and deploy went without issue. The problem is definitely associated with the ZSTD feature.
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).
The VM that fails to image does boot, albeit the HDD is not expanded because it didn’t get that far in the deploy.