@tech49 said in Full Registration glitch, cannot type hostname for this computer.:

When I try to do a quick host registration and then select the host and prenamed image to be captured.

Registration allows deployment of an image, not capture.

For capture, issue a capture task for the now registered host in the WebUI.

@jeremyvdv The IP of the client (that it receives when imaging) is possibly in the NAS FTP blocklist due to too many incorrect login attempts.

@tech49 Please make a new thread for the new issue so we can help you there. (since it’s unrelated to the thread)

What does the Virtualbox configuration look like?

@lucjayjay You don’t need to worry about partclone, this would just be ran afterwards (since all it will do is try and look for an EFI bootable file and write those to the NVRAM if the entry doesn’t exist yet, which means it has to run after partclone is fully finished)

I’m not sure if you can just grab that script as is and try and call it like that with options, though. It seems like it tries to grab some stuff from other files too, not entirely sure what’s in those.

This will likely require some more investigation for implementation, but you can try it already with post deploy scripts as said.

@Duncan As I understand it, Acronis uses WinPE, supporting the idea that this some kind of Linux problem, but it appears to be hard to track down exactly how and why it happens.

Hmm, maybe have to get a little bit creative, unless I’m missing something.

If you install the plugin tasktypeedit, you can create a new task that boots to the live linux.

Then you could cron schedule that task for the hosts in question for every minute. This does leave a windows of time where it wouldn’t work if they reboot within that minute, but should otherwise work I think.

@MHImager Does this happen on models with NVMe SSDs only?

@george1421 Regardless, partclone is much slower for him than even this dd test. In the github issue thread I linked, they hypothesize that dd uses O_DIRECT and partclone does not, hence the difference.

It’s also worth noting that they had better speeds when the target was mounted, which live Ubuntu does automatically when it can.

Of course this is working under the assumption that it’s the exact same issue.

@Duncan Please replace the dots with the appropriate ending for the drive. (eg 0n1) and try again.

@loutrage Looks the resize test fails, which automatically marks the partition as fixed size.

Possibly the filesystem or disk is damaged causing the failure.

Try and fix the filesystem by running chkdsk C: /f on the windows client you want to capture. (you’ll then need to confirm to schedule on reboot and then ofc reboot)

@jeremyvdv said in Mount NFS:

I made a redirection of the images folder of my debian to a nas.

What do you mean by that?

If you have mounted the NAS folder to your Debian machine then it won’t work since the Debian machine can’t “export” a folder that isn’t its own. (you can’t daisy chain it)

If you want to use a NAS as storage, you can try configuring it as a storage node.

You have 2 resizable partitions.

FOG attempts to maintain the percentage that those partitions take up for its resize logic.

So, because your 2nd partition is approx 53% of it will attempt to organize the partitions as such on deployment too.

But since your partition needs a minimum of 34GB of 55GB to function, that means that approx 62% is already taken up, forcing the system to allocate whatever remains to the other partition (D: presumably) to make sure it’s more or less the expected outcome.

In other words; you need to either make the 2nd partition smaller before capture or deploy to a larger disk.

For some reason this reminded me of some of the earliest (and most explored) reports on slow deployments on certain system drive combinations.

https://github.com/Thomas-Tsai/partclone/issues/112

That user notes that if a partition is formatted and mounted on the target disk just prior to restore that it runs at expected speeds (but in FOS only if it’s not NTFS for whatever reason). Next attempt to restore will be slow again unless the same step is taken.

They then went on to try a different drive (different brand) and that one worked normally.

The advice is to install FOG 1.5.7 instead of 1.4.4

@Duncan Perhaps they are using different NVME controllers for some reason. Should be interesting to check it out at least.

@Duncan Are the BIOS versions the same on these laptops? Settings too?

@EduardoTSeoane

Here is a possible alternative for the fastmerge function.

    public static function fastmerge($array1)
    {
        $others = func_get_args();
        array_shift($others);
        $array1 = array_merge($array1,...$others);

        return $array1;
    }

Though I expect performance difference to be minimal.

More likely that the problem lies in the sheer number of it.

Possibly 1.6 is a better environment for that.

I’d say, only update database itself if task fails or is completed.

Keep webserver progress update ping as is.

@Tom-Elliott said in Failure in Capturing an image:

@ismith-hpu But the machine, indeed, does have an OS on the disk? I can only assume the -a0 is a part of the problem. I don’t know what the argument is doing for the 0.3.12 version of partclone.

It’s to ensure compatibility with 0.2.89 images, allowing them to be deployed with 0.3.12.

0.2.89 had a broken checksum system, so we force it disabled on 0.3.12 in order to allow those images a normal deployment. It’s also faster and slightly smaller images, certainly not complaining about that part.

It is curious that 0.3.12 doesn’t seem to work in this instance, though I wonder if a non-resizable (not raw) capture has been tried?