UNSOLVED read ERROR:No such file or directory

  • Server
    • FOG Version: git commit ac340187ca9f1f8c0a6d09724367818a05c77186 from the working branch 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 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.

    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.

    0_1493697298577_read ERROR:No such file or directory.png

    Image directory listing from the test fog server:

    root@testServer:/images/win10# pwd
    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


    /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



    Disk configuration.

    0_1493697306298_disk config.png

  • @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.
    0_1493855732085_zstd and gzip.png

  • 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.