Finally got around to testing a bit.
I compiled partclone 0.3.12, removed --ignore-crc and deployed a 0.2.89 UEFI windows 10 image.
Verified I was running the correct partclone version (since it mentions it while writing the data) and monitored for any trouble
Everything completed successfully and the pc booted normally.
edit: I should additionally mention I haven’t touched ramdisk size or anything.
@alansopro This is typically caused by FTP password issues.
Sounds like you originally installed with SVN (guessing) or unzipped it to /root/fogproject
Either way, moving it or deleting it will allow you to use git checkout no problem.
@george1421 Of course, just trying to figure out if there’s any differences in the inits themselves that might cause a disrepancy.
I’ll let you know if it deploys correctly on my test system tomorrow.
Do you have a funky partition layout perhaps? I’m assuming fairly vanilla, but you never know.
@ITCC You need to run installfog.sh again after updating .fogsettings
The problem is your Windows DHCP server is already handing out Boot info.
Your client sees this info and tries to boot from it immediatly.
ProxyDHCP can only step in and help out if the Network boot info isn’t passed on yet.
@george1421 Well, potentially that was a resize bug in the inits if you’re using an NVME drive.
Could also be the mount failing for some reason?
Just some ideas.
@fernando-gietz Does it consistently work after using George’s command? (even if you shutdown and do a ‘cold boot’?)
My theory is that if you have Windows 10 Fast Boot enabled it will skip that bootloader and boot straight to Windows, however that only happens if you shutdown -> boot as opposed to reboot. Windows 10 Fast Boot does a lot of annoying stuff like make it very hard (or impossible on certain devices) to get into BIOS during boot.
@george1421 Well, we did find a resize bug in the inits, particularily on fast disks.
Might be time to revive this idea soon and test it out again.
Have you tried the troubleshooting steps on the wiki yet?
Currently it fails to capture msftres partitions, throwing exit code 139 (presumably zstd’s error code). msftres is captured with partclone.imager
It’s difficult to see what’s going on because the screen breaks up, but it seems to not recognize any size on this type of partition on partclone 3.12 which is a regression compared to 2.89
edit: Adding a strategic debugPause tells me there is a segmentation fault on line 2041 in funcs.sh
Even stranger is that it is talking about line 2053, yet for some reason mentions line 2041???
Though not sure why this occurs…
edit2: Seems to be down to the fact that it writes to /tmp/pigz1
Direct writing to /images works fine
edit3: Welp, it seems to come and go as it pleases, not sure what the actual cause is!
edit4: My suspicion lies on B128 option being the culprit (initial test is promising), recompiling, will test tomorrow.
Not sure you can upgrade from v.31 to trunk safely, to be honest.
But yes, you need to upgrade the nodes to work properly with the trunk server.
Glad to hear you resolved your problem. For future reference, I think in your case the permission denied was due to not updating the NFS mounting location.
@sudburr Make solid backups of database and such. I don’t know for sure if you can just roll back without setting back the old db.
I do believe this is fixed in the latest version if I’m not mistaken, so upgrade upgrade upgrade.
You shouldn’t have to set date.timezone in your php.ini file (just checked, it’s commented out and blank on my end). I think it is sent dynamically based on your selection in the GUI.
GUI looks normal too. (same as on my end).
There might be a strange problem with a specific timezone, so maybe pick one at random and see if that one does work?
@Sebastian-Roth @pete Tested a host with debug tasking. With the -A ""
argument it works fine, without it Cannot view from browser
@Motech09 Did you alter /opt/fog/.fogsettings with the new images path?
Did you adjust the storage node page with the new paths?
