In the current iteration, FOS will always require at least the position of the last partition to be included.

In practice this means that if you have a non-resizable partition (eg recovery) after your Windows partition, then it will always be the full disk size being deployed.

This is because the start position of that partition is near the end of the disk and will be deployed as such (on bigger disks this means it will start near about where it does on the 500GB disk), which means it can’t deploy on smaller disks.

We hope to one day be able to shuffle partitions around and resize regardless, but for now you will have to fix your layout before capture by moving the recovery partition to before the windows partition.

@rocksteve69 That’s fine, try that one. As long as it’s before kernel 4.11

@rocksteve69 Sorry, can you try Kernel 4.9.11?

FOS is updated when you update FOG.

You can manually update it the way you did it. (though you don’t need packages: partclone, partimage, testdisk, zstd) and then copy the init.xz files to /var/www/fog/service/ipxe

Do note, that your current configuration is untested by FOG. Updating the Buildroot version without testing is not recommended and can introduce breaking changes or unintended consequences. (you can check current versions in the Jenkinsfile)

Alternatively, to make it easier, you could install and configure Jenkins to handle it since the github repo contains a Jenkinsfile.

@Gilberto-Ferraz If you don’t have SSH access; nor physical access, then please post a diskmanagement screenshot of the windows installation you are trying to image. (so we can see partition layout, roughly)

You likely have partitions located after your main Windows one which forces the minimum size to be close to 500GB or the full source disk size.

@rocksteve69 I’ve looked into this a bit more and there’s some people complaining about NVME speeds declining greatly when they update Linux kernel to a version above 4.9 (4.9 being a version that works fine for them)

So maybe trying an older kernel version can help.

Of course, the problem you can run into then is that other parts of your system aren’t supported, but it’s worth a try!

@rocksteve69 I’d be interested in seeing if you’d see better results with a RAW capture.

@rocksteve69 This reminds me of an issue another user had on certain SSD/PC combinations where he had to create a working NTFS partition before tools could copy to it full speed. (not FOG specific)

Still don’t know how or why that’s a thing, and the creator of partclone seems to have given up in that direction too.

@george1421 I believe at one point it was suggested to use SSH to handle interactions with the server instead of ftp/nfs (one or both, don’t remember)

Though I imagine that’s further down the line.

Does the system boot if you leave the settings on AHCI?

What kind of DHCP server do you have? It is often possible to make it automatically boot UEFI capable computers to UEFI and the rest to legacy.

It’s true that FOG can’t capture (or deploy) if the disk mode is set to RAID in the BIOS.

All that said, I’m unsure why your system would fail to boot after a capture.

Tested on Centos 7 PHP 7.2 FOG 1.5.7

No problem with @ in password on my end.

@vangrimoire what’s in your PHP/apache error logs?

@Tom-Elliott I agree that it’s not a bug (everything is working as designed).

I don’t have a lot of experience with AD; I was unsure what is and isn’t allowed. It seems that spaces in AD names are bad practice and cause more problems than they’re worth. (though it doesn’t seem impossible, just breaks half your stuff)

@martial Correct, they generate the same MAC address regardless of their host.

The real problem was likely that they were set as ‘primary MAC’ for multiple hosts.

@Sebastian-Roth I think it’s fine to leave X86 to 8 since I don’t think they make huge multicore 32 bit CPUs. (wouldn’t really make sense to me anyway) Though I also think it wouldn’t necessarily hurt to change it, why bother if it’s not needed? I also believe 8 is default for X86 anyway

As for ARM: https://www.phoronix.com/scan.php?page=news_item&px=ARM64-256-Default-NR_CPUS

Default in Linux 5.1 ARM 64 is 256 now. (current default being 64)

https://bugzilla.redhat.com/show_bug.cgi?id=1652865

Some other people having a similar issue, problem possibly fixed on newer kernel version.

@no0NE Go to the Kernel Update page and try grabbing the Kernel 5.1.16

Technically you can probably capture and deploy it in a non-resizable fashion (it will be slow since it will do a RAW capture), though I’m not sure if this will work reliably with such a filesystem.

It’s closed source and only available on enterprise, so I don’t expect any open source solutions to arrive any time soon.

@no0NE I’d still recommend trying a different cable/switch port just to rule it out completely, even if the first device seems to work properly on it.

I also found the following on this topic that’s worth checking out: https://wiki.hetzner.de/index.php/Low_performance_with_Intel_i218/i219_NIC/en

https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/fog/user.class.php#L214

This function is where it validates the username.

It uses the same regex as the javascript that checks when you try and manually create an account.

@kek can you share some examples that failed so we could potentially modify it?

It doesn’t seem difficult, but we need to know if it’s valid for your case.

It also looks like OP is using mdraid, not sure if specifying a disk will produce the desired results under those circumstances anyway. Though; I don’t know at all how that’s handled behind the screens so it could be no problem at all.

@Sebastian-Roth

There are kernel flags to disable SMP if necessary, so I think it’s pretty safe to compile with MAXSMP. Just my opinion of course; without a diverse test fleet it’s hard to say for sure since kernels can always have bugs or unforeseen interactions. But that would be true for any change we make.

I can’t find anything googling about stalls/problems with MAXSMP either. Only some people on embedded systems who want to reduce the size of their kernel, but that’s a targetted compile anyway.

There will be more and more systems entering the floor with more than 8 cores (our current NR_CPU value) given the recent CPU releases as well, so at the very least that number could use a bump.