Posts made by Junkhacker

@cmurray139 i’m not sure. I don’t have much experience with devices that don’t have Ethernet built in. if you search the forums, you might find someone who’s already solved the problem though.

@cmurray139 we are evaluating alternative unique identification methods, but it’s difficult to find something that fits our needs. in the meantime, you can register the wifi adapter’s mac address instead of the USB device.

@JB2019 please paste the contents of your install log. it should be located, from the base directory of the install files, in /bin/error_logs/foginstall.log

@paravane so, you re IP’d a server that you never had working, removed .fogsettings and reran the installer, and you’re using the FOG server for DHCP?

frankly, there are so many things that need reconfigured and so many things unknown that the easiest thing to do at this point might be to start over.

@JB2019 port 80 http://<ipaddressofserver>/fog/ just like the end of the install script says

@JB2019 said in FOG 6.4 fails to download per instructions - install fails:

fog_0.32

wow. haven’t seen that in a while.

@tutu10 i think you posted this to the wrong forum…

@salted_cashews i think the issue you’re describing is because the FOS hits the problem and bails before the step where it checks in with the web interface to say it’s done.

@george1421 No problem. I was just hoping to make progress on this. I found this https://github.com/stevenshiau/clonezilla/issues/31 and wondered if it was related since it was from when clonezilla updated their partclone version.

@george1421 have you had a chance to do any further testing? did you build 32bit versions and have you tried using them?

@jemerson93 there shouldn’t be a need to adjust the ramdisk size for the current release init files. the installer downloads the init files specified for the release during the install. we updated the inits that are downloaded for the 1.5.6 release so that anyone running the installer now gets the init files with this issue fixed.

@jemerson93 there was a bug that was in the initial 1.5.6 release. it has been fixed. if you rerun the installer it will update the init files and solve the problem, or you can update the init files manually to the new version.

@salted_cashews yes. it’s the minimal Linux OS that loads over the network to do the imaging tasks

@salted_cashews the log that’s gets generated during the imaging process is on the client booted to FOS. it’s gone as soon as the computer reboots.

@salted_cashews it looks like the image file for partition 3 is missing

@ayoward yes

@george1421 for reference: I tested with your inits using both bios and uefi configurations using a physical computer and a vmware VM. I had no problems with booting the systems after imaging. all images were compressed with zstd (not that that should make a difference, but putting it out there) and the images ranged from windows 7 to windows 10. imaging done while in uefi mode seemed significantly slower. i don’t know if that’s normal, since i don’t normally use that.

@ayoward it could be a buggy network firmware. have you checked for bios/firmware updates for the computer?

@george1421 i just tested a deploy with the init i downloaded from your google drive link today. it deployed and booted (though i did get the UUID error, so you need to update your files to the latest build, not that it’s related to the partclone issues)

I’m at kind of a loss as to what’s wrong at this point

@george1421 just looking at the partclone binary file sizes in the init from you and the one from @Sebastian-Roth the sizes are all different. I’m curious as to the differences in the config files used to compile the different versions. yours are smaller.