@wayne-workman I just did the same today (easy to swap from 8 to Stream) to test it out and see how different it really is.
Most packages got fairly minor updates (eg it runs the same Kernel, just a newer security release), interestingily, httpd got downgraded.
Still, only minor point differences in packages as far as I can tell. I don’t foresee any issues with it.
Of course we have no idea how it will evolve over time.
@baessens I’m going to take a guess, but is the disk a “dynamic virtual disk” by any chance?
There is a missing , at https://github.com/FOGProject/fogproject/blob/ddcc96c4ff8158314ab0383f988c9c6666e8686e/packages/web/lib/pages/processlogin.class.php#L260
and
@developers can you fix this one?
@enzogislard It doesn’t care about whether or not there is data on it, the structure gets captured and deployed.
@enzogislard I think it is a similar problem here, even if Centos.
If you move the swap partition before the root partition and then capture it again (in resizable mode) it should work I reckon.
Are you capturing in resizable mode already? Other modes will fail since your source disk is much larger than target disks, even if the partitions on it are smaller than the target disks (could be mistaken about this though)
@gfrancesco84 What is the output of list vol in diskpart?
@enzogislard This is a known problem on newer Windows 10 versions.
They put a partition (recovery I think) after the main Windows partition now, which FOG doesn’t handle that well currently. (it expects ‘data’ partitions to be last)
You can use a partition manager program to move the partitions around.
If you capture it after moving the Windows partition to the end of the disk, then it should work as expected.
@Tom-Elliott I kind of like that idea of a fallback mechanism, but I fear that it would kind of nullify what it’s trying to solve in a way.
Few people would know about the NVME naming scheme being essentially random on each boot and thus may presumably fill in the name of the drive. This would then get used and the size (if filled in) would be ignored.
I think if it were to be implemented as such, then the GUI should inform to use size over name for NVME drives.
PS: What happens when you have 2 identical drives?
@Wayne-Workman DATE() returns the date without the timestamp. So it will be assumed to be 00:00:00
Use just NOW() and drop DATE(), so that it is updated more accurately.
@benc Can you do
zstdmt -dc </images/_Windows10Prox641909/d1p4.img | partclone.info -s -
And paste the output here? It will tell us which version the image was made with. (if it works ofc)
You can of course build partclone from source from their github repo.
Let’s start with installing partclone 0.3.13, since FOG has been using that for a while and the image format is different to how it used to be. (it can still restore images made under older versions though)
Next up, you need to check the zstd version. FOG uses a fairly recent version (again backwards compatible, but older versions may fail on newer compressed files) Should be 1.45 I believe.
zstdmt -dc </tmp/pigz1 | partclone.restore -n "Storage Location $storage, Image name $img" -O ${target} -Nf 1
Is what FOS uses to restore an image back to a disk (deployment).
So for this case we can modify to
zstdmt -dc </images/_Windows10Prox641909/d1p4.img | partclone.restore -C -O /d1p4.extracted.img -Nf 1 --restore_raw_file
Tested this on my FOG server and it worked fine. Let me know how it goes.
@x23piracy It’s safe to delete if you don’t need that partition.
Alternatively, you could manually create the partitions in windows setup I suppose.
@x23piracy Not sure what program you are using, but perhaps you need to shrink you windows partition first, move it to the right (into the unallocated space), then move the recovery partition in front of it, reallign and expand again.
@x23piracy Yes, that should work. Hopefully we have a better solution by 1.6.0
@x23piracy The newest W10 versions seem to create a partition after the Windows partition. This will be what’s blocking it.
There are some ideas on how to resolve such things in the future, but currently you have to manually move the partition before capture.
@Sebastian-Roth Is it possible to detect if an image is made with partclone 2.89?
If so, we could just err on the side of caution to omit the parameter when we detect the image is the old style I guess.
@Sebastian-Roth Been very busy and don’t really have a great test setup right now.
Ran a quick and dirty test and get roughly 20% speed bump from the provided init over the one on the dev-branch. (ignore the exact numbers, it’s not very scientific, it’s a significant enough difference at least)
Seems to be roughly what was reported in here by OP from what I can tell.
I don’t have 2.89 images to test to see if they do or don’t work, however. That will be key.
@smoooo Unfortunately, Apple is not in the habit of creating open source tools for the community to use, so there’s very little to no options for such things.
@Sebastian-Roth said in Feature request for FOG 1.6.x - Replace NFSv3:
@george1421 said in Feature request for FOG 1.6.x - Replace NFSv3:
The downside with using port 22 ssh is there may be some policies where a certain encryption structure must be used and changing the sshd in certain circumstances will break imaging. The thought would be to then spin up a new sshd server on a different port so the sshd configuration could be tightly managed by FOG.
Hmmm, there are pros and cons on both sides with using default SSH on port 22 and spinning up an extra one on another port. Whichever we decide there will be setups that can’t handle it this or the other way round. So I would suggest we try to make it default to port 22 but build scripts and all in such a way that it’s fairly easy for anyone to switch to a non-standard SSH port if needed. @george1421 @Quazz What do you think?
We’ll need to work out a proof of concept over the next weeks to see if it all works anyway.
I agree with trying to stick to 22 where possible, but to make it configurable. I can imagine some environments have custom ports.
Some reading to consider: https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls
Mentions SSHFS as well (even faster than clear text NFS in their tests??)
I can’t really decide, in the end. Each approach has its own set of downsides and upsides it looks like.
What is most important? Reliability (eg NFS restarting TCP transactions), Security (encrypting the data stream), Maintainability (KISS), Performance (NFS likely slower than SSH pipe)
Additionally, I wonder if we would see differences in performance when we compare transfer performance of a static file vs a data stream. Or perhaps this consideration is irrelevant since more than likely the bottleneck won’t be network transfer anyway, right?