Update…
It appears updating the init.xy file AND adjusting the KERNEL RAMDISK SIZE setting was the key to get it working. Only have tested with 1 of the images created on the new 1.5.9 server, deploying on the 1.5.5 server. Looks like we can limp along doing this until we can get the other sites updated, which is in motion now.
I owe you guys a beer! Thank you again!
Ah… good to know.
Will give that a try as well, and update this comment on the results. It may be tomorrow before I have a tester at the site to see if that resolves it. Crossing my fingers. As always, thank you!
@george1421 Hey there, and thanks for the reply.
Tried the init.xz file, and deploys on the 1.5.5 server still failed, but with a new message about Kernel panic.
Figured I would try with the whole ipxe directory in case the service needed the updated files within the directory as well, and again still received the Kernel panic mssg, slightly different… but the same.
At this point, I think I would have to adjust many things to include the newest Kernel for FOG to use, but that that point it may have dependencies on code that may not exist in the older 1.5.5 version… so I am not sure that it is worth the adjust. We have tested the image deploy through the 1.5.9 FOG server, and it worked fine, so we know it is not image related.
Gonna fast-track the FOG server rebuild so we can deploy these newer images. As always, thank you for the confirmation on differences, and ideas on what can be tested or tried.
Note for self going forward… higher version of FOG is backward compatible to images created with earlier versions of FOG, but Older versions of FOG is not compatible with images created with newer versions of FOG. Pretty typical with any software, just figured I may be able to make something work for a few weeks while we update, we will just halt the image creation for now.
While we are updating our server OS’s to deal with the newer version of FOG that is out… we are finding that the images that have been created with the newer version of FOG, and replicated to the other sites with the older versions of FOG that’s running. Seems there is a sizing issue when trying to deploy newer images with the older FOG version. For some reason it is expected a Petabyte in storage to deploy… and the images obviously are no where close to this.
My initial thoughts are that in the newer versions of FOG, PartClone was updated, and maybe the older versions of PartClone can’t read the partition information correctly regarding sizing. I figured if this was the case, there still should be a way around it temporarily until we have the new servers at the other sites up and going.
Can I get someone to confirm what I am seeing is the case? And if there is a work around that I can use for partclone to ignore size, and just deploy.
Image Build Server: Ubuntu 20.04, FOG 1.5.9
Image Deploy Servers: Ubuntu 18.04, FOG 1.5.5
New images created by Build server, fail on deploy servers with: PartClone Fail… failed to restore image. Not enough free memory, partclone suggests you have 55732046249873802 bytes available.
Update:
Finally had some time to sit and putz with it. Seems it was a carry over issue between what the password was in /opt/fog/.fogsettings for "fogproject’ versus what the UI had for the TFTP settings for the ftp user account, and for the storage node. Interesting that it was able to Image, and pull images though.
For those that may be interested, or have the same issue:
FTP to the FOG server from another box, and test FTP user and password that is shown in the storage management UI. This password should ALSO match what is in the FOG Settings in the UI for TFTP server. In my case… the password in the GUI would not allow me to connect to the FTP. Started searching for the proper way to change the FTP password for FOG… but ended up finding that the password was different in the .fogsettings file. I tried the password in the settings file and it worked to connect to the ftp.
At this point, I took the password shown for fogproject in /opt/fog/.fogsettings and placed it in the UI for the Storage, and TFTP server settings. Attempted to delete from the UI… and bingo, all good.
A good ref that helped to figure this out:
Troubleshoot_FTP
Update:
Ran chown -R fogproject:root /images against the directory, so permissions seem right on the images directory as far as ownership, and it still gives the same error. Seems maybe in the carry over the “fogproject” user may not be known to the system, and only configured inside of FOG because of the DB copy over? Not sure… if anyone has some pointers to try, my ears are open.
Currently deleting manually… remove image pointer from DB on the GUI, then going to the images directory and running rm -r images/sysprepxxxxx to remove the directory and contents… so we are not down by any means, would just like to have the GUI delete working from within the image screen.
Had a successful migration, DB, images, and install of 1.5.9 to the new Ubuntu 20.04 server, however it seems FOG’s rights to delete images was lost. There is an error that comes up on delete:
Seems imaging, or capturing images all seem to work fine. PXE works fine… just seems to be the delete, as of right now. Any idea on what I need to do to ensure a user can delete the images? I suspect the old setup storage account from the DB that was transferred, then updated may not be correct now… though it seems to be reading from storage fine, location didn’t change, and rights were copied with images.
Any idea’s on resolving this 1, and 2 is there anything else I should do to ensure the rest of the configuration is good? We have 2 more site servers to convert over the same way, want to get the process down to keep downtime low. Thank you!
Some background:
Each install is there own storage and site server, we manually replication to other sites with rsync for network throttling reasons, and script out the DB image list for the other sites so each site DB stays updated at the other sites. Think of it as 3 Master Sites, with a sync from Master 1, to Master 2 and 3. Each with thier own single data storage node.
@sebastian-roth Doing the DB maintenance resolved the issue.
Wanted to give a reply… but with Houston after Hurricane, and business having to pickup and move… just now getting around to following up.
Thank you for your help and patience!
@sebastian-roth Will give this a try as soon as power is restored to the office. We are located in Houston, so it may be a few days before I can let you know. Thank you for the reply!
Doesn’t cause any issues really… but seems ever since the upgrade to 1.4.4 the counts are off.
If I am imaging the count will increase… but at zero tasks, zero tasks waiting, and nothing active the dashboard still shows activity, and continues even after reboot of the FOG server. Need to be able to reset this back to zero somehow. I saw a method in another post about going into MySQL and resetting the count in the table to “0” but that did not work either.
Any idea’s to get this back to zero when not in use?
