Partclone log upload
-
Just a thought reading the following post.
https://forums.fogproject.org/topic/8239/windows-10-image-won-t-deploy/32
If partclone terminates unsuccessfully, assuming it gives a relevant exit code, would it be worth uploading the partclone log, /var/log/partclone.log to the fog server.
It could even be uploaded for every deploy, just keeping the latest. -
I agree, but the issue is how to name the file? I can easily create a place to mount so we can overly the /tmp/ folder of the host and have the host stored, but it can also fill things VERY quickly.
-
@Tom-Elliott Hi Tom. since we use the mac address as the unique id for the hosts, then the file could be named mac-partclone.log.
If it overwrites any previous file for that host then there would only ever be one file per host, I don’t know how big the file is, but given that images are gigabytes, then it shouldn’t be that much data (relatively) even with many hosts.
Even better if it could be restricted to when partclone fails. -
My first thought was to do it via http, which would give the server the option of ignoring it if space was an issue, or it could be made a configurable item.
-
@Tom-Elliott said in Partclone log upload:
I agree, but the issue is how to name the file?
MAC Address, same as uploads. If the file already exists, overwrite it. Can you specify Partclone to write to the mounted directory instead of doing some copy stuff later that may or may not work?
idk if the inits mount the /dev folder already for deployments, so if they don’t, I sure don’t wanna change that. The logs would need to go elsewhere.
/images/dev/partclone/00:11:22:33:44:55:66.log -
Also - I suppose, it’s valid to say that you never need to even transfer the partclone log to the server.
Think about this. FOG can do a debug deployment or capture. Doing this would allow you access to the partclone log.
So maybe not fix what isn’t broken? We’re close to release, best to not further complicate the imaging process???
-
I wouldn’t see it as something to go in the next release, as you say it will complicate things.
It would help in cases were the imaging process fails, and then the host auto reboots and loses the log. A debug will allow you to see the error if it happens again, but uploading it to the server would make it available via the fog console without the need to deploy again.