FOG unable to capture/deploy resizeable images correctly.
-
@dambron Ah well, why go to bed if digging through the script code is just so much fun… Please schedule another debug capture task. When you get to the shell run the command
fog
to start the capture as usual but in debug mode you need to manually step through pressing ENTER for every action. When you see the lineSaving original partition table.....
take a picture of the screen and post that picture here. -
Here is the screenshot of the stepped process for capturing this image.
-
@dambron Ok, that all seems fine so far. I still can make heads or tails of this. Can you please do the debug capture again and step through till you see the message
Processing Hard Disk: /dev/sda
and then take a picture again.As well please post the contents of
/images/<IMAGENAME>/d1.original.fstypes
here. -
@Sebastian-Roth said in FOG unable to capture/deploy resizeable images correctly.:
@dambron Ok, that all seems fine so far. I still can make heads or tails of this. Can you please do the debug capture again and step through till you see the message
Processing Hard Disk: /dev/sda
and then take a picture again.As well please post the contents of
/images/<IMAGENAME>/d1.original.fstypes
here.Processing Hard Disk: /dev/sda
d1.original.fstypes
/dev/sda1 ntfs
I feel bad for making you dig through all this but I really appreciate the time you’ve taken. If worse comes to worse I can always have my team change their process to always pull the image off of the smallest drive size we deploy on site to avoid this in the future, but honestly I’m just so curious as to why this isn’t working now. I feel like it was working previously, but maybe I just never ran into this particular situation.
-
There was a bug in the inits that would cause issues with recording the wrong info about “fixed size partitions”. I believe 1.5.6 (just released!) contains the fix though. You’ll have to recapture the images though.
It was fixed in this PR, no? (the PR isn’t labelled that well, but basically the code hadn’t been updated in that file, but now we just read the info instead of running the same tests twice) https://github.com/FOGProject/fos/pull/24
The other user hasn’t reported back yet, but give 1.5.6 a go and let us know!
-
Wow so that’s funny, I was just following another thread about editing the inits but it was from 2017 or so. I randomly stumbled upon it while trying to find more information on my issue.
So, do you know if there is any way to update the inits without performing the 1.5.6 version update? I suppose I could wait until the weekend since we do half day Fridays all summer and then deploy and make sure everything is working, but I feel like it’s kind of a dicey time to be pushing an update (especially since it will be the first time I’m doing it on my own!).
-
@dambron The script grabs the init from this url https://fogproject.org/inits/init.xz
Put it in /var/www/fog/service/ipxe
-
@Quazz said in FOG unable to capture/deploy resizeable images correctly.:
@dambron The script grabs the init from this url https://fogproject.org/inits/init.xz
Put it in /var/www/fog/service/ipxe
You are the greatest. I will let you know how it goes!
-
-
@Sebastian-Roth said in FOG unable to capture/deploy resizeable images correctly.:
@dambron Yeah, Quazz is totally right. We have updated the init files and I totally forgot to ask you to try out the most current ones (32 bit and 64 bit). Hope this will fix the issue for you.
Thanks so much to both of you. I replaced the init file and everything is now working properly. Many thanks for your time and efforts.