Posts made by Quazz

I am personally a fan of an SSH/SCP solution. It’s a very familiar protocol, secure and pretty straightforward. SSH ports are likely already configured in firewalls as well. Also has pretty good error handling.

Tools like socat are cool, but I think a lot of people are not very familiar with them and since you’d need SSH or the like to get it going anyway, it seems like an extra step without any clear benefit (unless I’m missing something).

The only nod towards socat I’d give is that it is likely more reliable in network transfers, but this comes at the cost of needing another port open in the firewall.

It also would be kind of ironic to move away from NFS because of insecure open ports only to then turn around and open an insecure port anyway lol.

@Sebastian-Roth Can we add it as an optional parameter since it breaks compatibility with partclone 2 images?

@Sebastian-Roth I actually ended up removing the B128 option (https://github.com/FOGProject/fos/commit/e151e674b14279375884c8597e06f82272fe3f92) when I noticed some issues with it, so it’s not in the current inits.

The a0 option is to disable checksum creation, shouldn’t negatively impact speed either.

Although, it’s possible that the whole checksum thing is bugged, which is one of the issues raised at partclone by Junkhacker and somehow causing issues?

@gadams Look into unattended installations (unattend.xml)

@Baessens What about the files in /images/dev?

We can assume credentials are fine; otherwise it would complain about that before being unable to create a file (I assume, could be wrong)

@gadams If you used sysprep for the original base image, then it likely shut down the PC cleanly; thus avoiding the problem.

@gadams It’s common to confuse the two, but I think Sebastian is referring to Fastboot on the Windows 10 installation itself. (in the software, not the BIOS).

It’s an option under Power Management -> Behavior of power button (translated, could be called differently, it’s top on the left menu anyway)

Then you need to click on the thing to show all options, requiring admin access.

You can now uncheck “Fast boot”

The reason “Fast boot” can cause issues is because it stores certain things in the “hibernation” file so it can more quickly load on next boot. Unfortunately this causes issues for FOG (and certain drivers…) and is pretty pointless for SSDs anyway.

Alternatively, simply shutdown cleanly before capture. (Windows Key + R -> shutdown /s /t 0)

Some time ago, FOG changed the linux user to be ‘fogproject’ instead of simply ‘fog’.

This is the account the FTP tries to connect to.

Looks like it can log in successfully, but fails to move the files, indicating a permission problem.

sudo ls -lah /images

Will show you current permissions.

More than likely the owner is incorrect.

sudo chown -R fogproject:root /images

@kaywokke

type=down for deploy
type=up for capture

Simple as that.

But there are other potential parameters that may be necessary for it to function as expected.

@drumnj said in Error trying to restore GPT partition when deploying Image to smaller drive, Error Return Code: 4:

@Sebastian-Roth Overall the current solution isn’t bad, so no real rush to figure out. I just think it isn’t the best solution. I suppose another option for people is to always make a golden image on a drive smaller than any other drive they plan to deploy to. Doing this I have found does allow the recovery partition to be used (did this with 2004 to make a clean OOBE Win10 image…with Chrome included).

That works, but I believe you run into the problem of being unable to expand the size of the Windows partition itself since the recovery partition is blocking it.

I’m not sure how to resolve this at the moment, personally I don’t use recovery partitions, they don’t really offer that much in my experience, though of course in some environments they may be desired or needed, so a solution would be ideal.

@Trev-lchs No; they are applied recursively (-R)

Can you share a picture of where it hangs?

@Trev-lchs You may need to set the owner and permissions again since you’ve made a new folder and file.

So run the chmod and chown commands again.

@Trev-lchs Use single quotes instead of double round your echo command so the literal string is passed.

Or paste the script in its entirety using a text editor.

@Trev-lchs

mkdir /images/dev
touch /images/dev/.mntcheck
chmod -R 777 /images/dev
chown -R fogproject:root /images/dev

It’s worth noting that cables will sometimes allow for the link to be “10Gbps” but in actuality can only handle “1Gbps”

Can you do a test to another computer with a 10Gbps link that you can actually transfer at that speed?

And as others have mentioned, if you are using SATA drives, then naturally they’ll be far slower than you network throughput regardless!

You can probably script some stuff together and schedule a new capture task using the API https://news.fogproject.org/simplified-api-documentation/

@Jim-Holcomb Third option Multiple Partiton All Disks should work for your case

@Sebastian-Roth Perhaps not for the MBR issue; but certainly for the resize issue.

@Jim-Holcomb said in Error deploying an existing image to SSD drive:

The image itself is less than 60GB (39GB I believe) so not sure why single drive resizeable won’t work here?

The answer to this question is that the last partition is getting in the way. There is currently no moving of partitions done by FOG and as such that last partition is essentially preventing resizable from working together.

Move that partition to before the big windows partition, capture again and it will work as expected for sure.

@cyrmoon Sounds like you need to configure your DHCP server to handle UEFI clients.

The Wiki article you listed has a section for windows server DHCP. Give it a try.