@Sebastian-Roth this seems relevant to this discussion as well.
Should be fixed in the partclone version FOG uses, but sounds like a btrfsfsck might be useful to try.
@Sebastian-Roth this seems relevant to this discussion as well.
Should be fixed in the partclone version FOG uses, but sounds like a btrfsfsck might be useful to try.
@RobTitian16 I only have a 2015 version to compare with, but at the very lest you shouldn’t instruct it to load files it won’t be able to find, yes.
Not sure where iPXE is pulling the Magic instruction from though?
Might want to test something like:
initrd http://${fog-ip}/pmagic.iso
chain memdisk iso
@RobTitian16 There’s a mistake in your menu item, it’s trying to use Magic as a command which it obviously isn’t.
I don’t see Magic anywhere in the wiki article either, so perhaps it would be useful if you were to post your menu item here anyway.
@Tom-Elliott Windows 8 often reads the key straight from BIOS if I’m not mistaken (assuming there is one in BIOS), Windows 10 checks with Microsoft servers if your computer is registered or not. (in other words, once registered, you no longer need the Windows 7 keys since it will activate off of the Microsoft servers).
However, I don’t know how it works if you want to use W7 keys to activate it. How does FOG enter the product key? Does it use the registry?
@fry_p From what I can tell, they’ve turned up the debugging messages on it. I noticed far more data/text while uploading.
Where exactly on the server is your ISO stored? The full path would be helpful.
@cojohnson Failing to update the database is generally an FTP issue, check the wiki on how to troubleshoot it.
I think that’s the issue, it’s using an SSD with eMMC memory.
Might have to call in the devs on this one perhaps.
You can try fixparts /dev/mmcblk0 though
For future reference, all devices are listed in /dev, so regardless of your devices name it will be there.
As far as I know <ComputerName> doesn’t work in unattend on Windows 10 anwyay.
@Arrowhead-IT Just a fyi, you can modify it slightly to allow for spaces in share names/paths by putting quotation marks whenever the share variables are called. I tested this earlier and it works great.
Your script is pretty awesome 
@SteveB689 This all depends on how the second HDD is set up. Can you give us some more information about that?
LVM would be easiest and would require almost no action besides setting up the LVM itself.
But I’m guessing you’re not using LVM?
What’s the actual path to the image location you created on /dev/sdb?
@SteveB689 Fairly certain you’re seeing the target HDD, not the source.
What do you see when you try to image?
Windows XP cant’ be a NFS server as far as I know. I think Windows Server 2008 and newer Windows Servers support it (maybe earlier too) , but you’re out of luck if you’re looking for client OS NFS server software on Windows.
@RobTitian16 Does Crystaldisk report any warnings?
Can you try to disable Fast Startup in Windows and try again?
@RobTitian16 Are you sure you’re running CHKDSK on the correct partition? CHKDSK /R should last quite a while on the main windows drive even if it’s minimal (25GB). What’s the partition layout like? (perhaps a screenshot of Disk Management would be useful)
FOG Trunk has early hostname changer I believe, not sure if that’s what you’re looking for though.
If it has a physical hard drive, try chkdsk /r (this will take a long time) or perhaps before that point you might want to check the hard drive health with something like crystaldisk. If chkdsk /f does not resolve that error and it returns consistently, it points to hardware defect imo.
Is this resolved or do you still require help?
The recommended way to boot WinPE based media is to use wimboot.
With small ISOs you can sometimes get away with just using memdisk on the ISO, but that’s not feasible for W10 ISO for example. (since the entire ISO would try to unpack in the RAM at once)
Booting W10 installation over the network is possible, but requires a lot more work to get it going. The basic principle is to load a modified WINPE ISO and then mount the unpacked ISO path and manually call the setup file to run.
@jhuesser Not 100% but I believe the script file needs to be called SetupComplete.cmd