Fog 1.5.7 can not capture second image (Debian 10 'Buster')
-
Hello,
I am experiencing some problem with latest Fog 1.5.7 installed in Debian 10 (‘Buster’).
The installation went through smoothly, Fog server is up and running. I can register host(s) and I can capture ‘first’ image from Windows 10 machine (HP dc5750 SFF). The image can be deployed back to the machine. Windows 10 image (win10pro-upd-aug1-2019) is clean install with all updates on Aug 1, 2019.
Now I wanted to install Fog client and to make a new image. Fog client was installed in Windows 10. Fog server was used to create a new image (win10pro-1803-upd-aug1-2019-client) and host scheduled to capture new image immediately.
Host with Windows 10 had no user logged in, but scheduled capture did not started (Fog client did not reboot the computer). I’ve attempted ‘force to start task’ and nothing has happened – I waited for a while to be assured that reboot will not take place.
Then I rebooted host with Windows 10 myself, Fog began to capture new image and everything was fine until partclone was working. Then Fog attempted to update database and it failed, it attempted to reapply changes and it failed again and again. Then Fog informed that host will be rebooted in 1 minute… and on next boot Fog initiated capture process again… it becomes endless loop.
Last messages on the screen indicate ‘invalid Storage group’ but it initiates on ‘Database update’ which fails.
I am sure that partclone did it’s job perfectly, but for some reason Fog fails to communicate/update database records. In web panel I can see a size of the captured image but date/time is wrong – if to believe that information it took 2019 years 8 month couple of days and a few hours to capture the image.
During Fog installation all options are default (I use other DHCP server and answered No on question if I would like Fog server to be DHCP server).
Some an idea came to my mind that may be there is some limitations on image name, I’ve decided to run a test with other image name ‘win10-test’ and the outcome was the same.
I did several attempts, even I have reinstalled Debian 10 and reinstalled Fog just for an assurance but result is the same – first image captured fine, but second fails with same message.
Did somebody came across this situation and is there some remedy to it?
Is my understanding is correct that when a new task (image capture/deployment) is scheduled ‘immediately’ through Fog client the computer (host) should be restarted automatically and I do not need to ‘force the task’ through web interface?
https://wiki.fogproject.org/wiki/index.php/FOG_Client
— Quote --------------------------------------------------------------
Task Reboot – This will just check if the client is in a tasking (other than a snapin tasking). If it is in a tasking, and the module is enabled, the host will be told to reboot. There is a third portion though in that if the user is logged in, and enforce is not enabled nothing will happen.
— End of quote ---------------------------------------------------Thank you in advance
Polar Bear -
@Polar-Bear said in Fog 1.5.7 can not capture second image (Debian 10 'Buster'):
Host with Windows 10 had no user logged in, but scheduled capture did not started (Fog client did not reboot the computer). I’ve attempted ‘force to start task’ and nothing has happened – I waited for a while to be assured that reboot will not take place.
There are a couple of things here, but lets start at this point. We are talking about your golden image. The FOG client should be installed onto your reference image but the service should be set to be disabled according to the wiki. https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep Then you will use the setupcomplete.cmd to reenable the fog client. At this point you should sysprep the image. While some say you don’t have to sysprep, but if you plan on sending this image to more of the same as the reference image hardware yes you do need to sysprep. Have sysprep power off the computer using the proper command line switch. If you choose to NOT sysprep, shut down the reference image using this command
shutdown -s -t 0to properly power off the computer for imaging. The windows shutdown button DOES NOT power off the computer, but instead places it in an enhanced sleep state. If your reference image has not been shutdown properly you FOG (partclone) will complain that the disk hasn’t been closed properly and it will not copy the image. (Google: “check disk dirty bit” to learn more about this issue).Then Fog attempted to update database and it failed, it attempted to reapply changes and it failed again and again. Then Fog informed that host will be rebooted in 1 minute… and on next boot Fog initiated capture process again… it becomes endless loop.
I’d really like to see a screen shot of this error. Because this typically means someone has adjusted the password for the linux user
fogprojectbut I want to make sure. The error may give a better indication of the actual error.Some an idea came to my mind that may be there is some limitations on image name
The only time we’ve seen this is when a space dash ’ -’ is used. For example in this name “Windows10 -Training room”. iPXE would see the " -T" as parameter and complain about it. Also using characters that mean something to the linux file system like question marks, colons and such should be avoided.
-
Hi george1421,
thank you for quick return to my question
Just a quick update:
- I have woken up my computers (3 linux boxes: DHCP/DNS servers, webserver/storage/tftp, fog server (storage/tftp/apache for fog).
- found that fog server did not waken up properly (something related to nvidia video card) and I had to reboot this computer
- in fog set new task to restore original image (image without fog client)
- to my surprise found that Windows 10 host rebooted (it had fog client installed at that moment) – odd, it did not work before I rebooted fog server
- image deployment went without any surprises well, no errors and took slightly less than 7 minutes (computer quite old by modern standards)
At this moment I did not reached yet point of ‘golden image’ prepared with sysprep – I am testing fog, how it works to be assured that it will not bring surprises at production deployment.
I surely will return to sysprep step as only I get assured that I do understand fog procedures properly and no quirks will come up any more.
I run capture of Windows 10 image by rebooting Windows 10 computer. I believe that at reboot there is no ‘unclean’ filesystem and fog removes swap and hybernate file – at least this is what I see on the screen of host machine which goes through fog capture process.
I will verify that there is no ’ -’ combination when I create the image.
I open web form through web browser and type ‘Win10 Pro 1803 upd Aug 1, 2019 client’ and field in image name filled automatically for me (I believe javascript takes care of this part and I believe that fog developers have looked into the code to handle situation for invalid characters – at least I confirm that I did not typed image name manually).
I did not spent sufficient time for ‘think process’ of how to name images – what came to my mind to have the name descriptive enough to distinguish what type of content it has. Any idea on this subject is welcome – I am very flexible in adopting ‘good practice’ approach.
Right now I plan to make a new attempt – who knows may be fog server restart has ‘kicked in’ something what did not worked earlier.
I will report as soon as I will get new results.
Thank you again
Polar Bear -
Hi,
next attempt failed as well, please see included pictures
Polar Bear
-
@Polar-Bear Boy this one has me a bit stumped. The FOG web ui works OK but you are getting this error? I can see if the web ui was broken this error would happen too.
You did perform the prerequisites of disabling the linux firewall as well as setting selinux to permissive?
-
@george1421
George,well I installed Debian 10 essentials+ssh-server+sudo only – no firewall, no selinux.
I guess that problem is somewhere else. So far I did not see obvious reason which could cause described by me problem. What is most interesting that for first image it works fine, but when I try to create second image it fails… puzzling
Would you suggest to dive into ‘debug’ mode?
NOTE: for a test I attempted to install Fog 1.5.0 just to see if it does not ‘manifests’ this problem and found that installation has failed (last message does not clarify the reason – I did not looked into installation files).
Right now ‘Fog server’ under automatic re-installation of Debian 10 … (takes about 15 minutes to get it running again).
Polar Bear
-
@Polar-Bear said in Fog 1.5.7 can not capture second image (Debian 10 'Buster'):
Would you suggest to dive into ‘debug’ mode?
Debug mode is something that we might do but right now I’m still confused by this error.
Just to be sure you didn’t enable https on your fog server?
In this new image definition, you do have a storage group selected and you only have one storage group?
Actually the error you captured may be the results of a previous error. Debug mode might let you capture the initial error message.
-
@george1421
George,I did install Fog with all defaults and I believe that https was not part of it (otherwise I did not touch https myself – may be in the future but not at test stage).
At this moment I use defaults in Fog web interface, no special storage groups was created – I use default storage.
I’ve thought about may be try to create new storage group and try to use it instead of ‘default’ – but I believe that ‘default’ should work anyway, otherwise this problem should be filed as a bug.
Polar Bear
-
@george1421
George,hmm, something interesting have happened – I have reinstalled Debian and Fog once more.
And this time when I was creating new image in web interface I found that now instead of dashes ‘-’ replacing spaces ’ ’ it has removed them!!! Does anybody working on code right now? I thought that if release 1.5.7 came out then it will not be changing (except patches to fix faulty pieces of code).
I have created one image and then almost immediately attempted to create another one and went to grocery store. On my return back found that that second image was created fine and now in imaging logs it listed with dates.
For me it is a mystery, on my part I have repeated same steps without any deviation and if earlier it produced described error now it works fine.
I will run more tests to see how reliable current setup.
Polar Bear
-
@Polar-Bear said in Fog 1.5.7 can not capture second image (Debian 10 'Buster'):
For me it is a mystery, on my part I have repeated same steps without any deviation and if earlier it produced described error now it works fine.
We have seen this exact error reported by other users and I am still unable to reproduce the problem and find the real cause of this. Not really sure what to do about it. Seems to be something that does not occur for everyone (obviously) but it’s still around. I even don’t know if it’s something fixed by a reboot or not.
And this time when I was creating new image in web interface I found that now instead of dashes ‘-’ replacing spaces ’ ’ it has removed them!!! Does anybody working on code right now?
I suppose what you are referring to is in management/js/fog/fog.image.js and has not been changed since August 2017 as you see in the github commit history. Which version of FOG did you use before?
