Fog 1.1.2 corrupts SQL database
-
I fixed the installer which during your upgrade looks like it broke it’s only because it’s now functioning properly that you were seeing the issues
-
I checked the Config.class.php file and nothing was in it. Anyways I will stop bothering you with this and use 1.1.1 for now.
-
[quote=“Oscar Hilliker, post: 32627, member: 24172”]I checked the Config.class.php file and nothing was in it. Anyways I will stop bothering you with this and use 1.1.1 for now.[/quote]
I don’t mind being bothered with it.
What do you mean nothing was in it? The file didn’t exist?
-
What I mean is the actual Config.class.php file had nothing in it. However after digging around I found a fog prev folder and it had the Config.class.php file and there is code in it. The odd thing is…there is a password not set by us, it has always been blank. I am not sure how it got there or changed. I will make another attempt at the install and report what happens.
-
Hi,
I believe that the SQL service crashing or timing out causes this (database schema update loop) - we’ve seen it too and it is painful.This link from Tom seems to fix it, especially the bottom section:
[url]https://github.com/mastacontrola/fogproject/issues/1[/url]
Cheers,
D.L. -
Tried Rhythmtone’s website and did all the suggestions then did a Re-try of 1.1.2 and it (SQL) failed, I saw some things about Fog 1.2.0 so I will try that as soon as I can get access to Ubuntu again.
-
Hi Guys,
I had this issue too when I upgraded. The /var/www/fog/lib/fog/Config.class.php had a password in the root user for SQL.
On Ubuntu boxes type sudo gedit /var/www/fog/lib/fog/Config.class.php from a terminal will open the correct file. Check if there is a password set for root, if so remove it leaving just the single quote marks (i.e. empty string). Re-link to Fog via browser and the schema updater should work. Did for me anyway…
This issue only seems to have occurred since 1.1.2 was released. Didn’t have any problems upgrading to 1.1.1.
-
Dear Tom,
don’t really know if my problems a right placed here but i try.
I tested the fog 0.33b in the past. while the test you guys released the 1.0.0 Version and later 1.0.1. With 1.0.1 everything was fine, so my Boss asked me if we can upgrade the FoG 0.32 of our customers. So i tested it and installed it with the SVN method. I upgraded both (a new 0.32 and my 1.01) to 1.1.2 and now it runs absolutely instable. Here some Problems i got:- MySQL Database was corrpted. Had to edit vi /opt/fog/.fogsettings and vi /var/www/fog/lib/fog/Config.class.php and it worked.
- I did an Imageupload from a Fujitsu Esprimo P420 with the 3.14 32-bit kernel. It Uploaded with 360MB/min (while an HP ProDesk 400 GI uploaded with 1 GB/min) but it uploaded it. The i used Sysprep to kill the SID and to create a new blank Image again with the 3.14 32-bit kernel and nothig. This is what i’ve got
-
esas2r: driver will not be loaded because no ATTO esas2r devices were found -
request _module: runaway loop modprobe binfmt-464c -
Starting init: /sbin/init exists but couldn’t’ execute it (error -8) -
request _module: runaway loop modprobe binfmt-464c -
Starting init: /bin/sh exists but couldn’t’ execute it (error -8) -
Kernel_panic – not syncing; No working init found. Try passing init=option to kernel. See linux documentation/init.txt for guidance
so i installed your unofficial 3.15 Kernel 32 bit. same Problem here till i renamed bzImage32 to bzImage and init_32.xz to init.xz
worked.
3) I created a Downloadtask with autoshutdown after deploy. As i started working this morning i saw that the Apache Server crashed and with him my Ubuntu 12.04 LTS and corrupted the deployed Image, so i had to restart the deployment.I dont know what’s happenig. I like the FoG Server but with all this Problems i just cant use it or upgrade the existing in customers infrastruktur. Please help.
Greetings from GermanyAndy
-
I noticed that in the config.class.php file in 1.1.2 there is a password. However the config.class.php in 1.1.1 don’t have a password since we didn’t use one. Also during the 1.1.1 install it ask did you leave password blank?. 1.1.2 doesn’t ask that. It looks like the config.class.php file had the password left in by the developers. However still after making it an empty password 1.1.2 still fails to install. I will wait for an update to fog, looks like they are working on 1.2.0
-
[quote=“Oscar Hilliker, post: 33386, member: 24172”]I noticed that in the config.class.php file in 1.1.2 there is a password. However the config.class.php in 1.1.1 don’t have a password since we didn’t use one. Also during the 1.1.1 install it ask did you leave password blank?. 1.1.2 doesn’t ask that. It looks like the config.class.php file had the password left in by the developers. However still after making it an empty password 1.1.2 still fails to install. I will wait for an update to fog, looks like they are working on 1.2.0[/quote]
The password you’re seeing is not one “left in by the developers.” It’s the password that’s set for the snmysqlpass variable in /opt/fog/.fogsettings
The reason why it seems “broken” is actually because in previous revisions it was really “broken” even with 0.32 and earlier. The “upgrade” setup was trying to use the snmysqlpass to set this value but it was never set. In 1.1.2 I made many changes to try to correct this behaviour and make it work properly. In doing so, the value that got stored there was not the database password. In 1.1.0 and 1.1.1, it was the unix user fog password that was stored there. This was a mistake and has been corrected for. However, I don’t have a simple means to edit the /opt/fog/.fogsettings so the correct action to fix this behaviour is to edit the /opt/fog/.fogsettings appropriately for this.
[quote=“Andy783, post: 33384, member: 23069”]Dear Tom,
don’t really know if my problems a right placed here but i try.
I tested the fog 0.33b in the past. while the test you guys released the 1.0.0 Version and later 1.0.1. With 1.0.1 everything was fine, so my Boss asked me if we can upgrade the FoG 0.32 of our customers. So i tested it and installed it with the SVN method. I upgraded both (a new 0.32 and my 1.01) to 1.1.2 and now it runs absolutely instable. Here some Problems i got:- MySQL Database was corrpted. Had to edit vi /opt/fog/.fogsettings and vi /var/www/fog/lib/fog/Config.class.php and it worked.
- I did an Imageupload from a Fujitsu Esprimo P420 with the 3.14 32-bit kernel. It Uploaded with 360MB/min (while an HP ProDesk 400 GI uploaded with 1 GB/min) but it uploaded it. The i used Sysprep to kill the SID and to create a new blank Image again with the 3.14 32-bit kernel and nothig. This is what i’ve got
- esas2r: driver will not be loaded because no ATTO esas2r devices were found
- request _module: runaway loop modprobe binfmt-464c
- Starting init: /sbin/init exists but couldn’t’ execute it (error -8)
- request _module: runaway loop modprobe binfmt-464c
- Starting init: /bin/sh exists but couldn’t’ execute it (error -8)
- Kernel_panic – not syncing; No working init found. Try passing init=option to kernel. See linux documentation/init.txt for guidance
so i installed your unofficial 3.15 Kernel 32 bit. same Problem here till i renamed bzImage32 to bzImage and init_32.xz to init.xz
worked.
- I created a Downloadtask with autoshutdown after deploy. As i started working this morning i saw that the Apache Server crashed and with him my Ubuntu 12.04 LTS and corrupted the deployed Image, so i had to restart the deployment.
I dont know what’s happenig. I like the FoG Server but with all this Problems i just cant use it or upgrade the existing in customers infrastruktur. Please help.
Greetings from GermanyAndy[/quote]
Andy, I guess I don’t fully understand what you’re saying.
In response to #1: The database was NOT corrupted, it was just not logging in to a valid database to make the changes you needed. So it errored out showing you all the Schema update/install items that failed because it couldn’t connect to the database. As it couldn’t connect to the database, nothing was written to the database so if your Database became corrupted, it was some other item. It was not the fog schema updater as it COULD NOT connect to the database to do any work with it.
In response to #2: The speed of the upload process varies from system to system. While I’m sure it was faster in 0.32, it was also because the compression rating used was much less. With the move to 1.x.x, the default compression is set to -9 or MAX compression. This slows down the upload as it’s trying to compress as much as it can. You can actually change the compression rating on your own in 1.x.x through the FOG GUI under FOG Configuration->FOG Settings->Boot Settings->FOG_PIGZ_COMP which is a slider bar. 0 means the least compression, 9 means max compression. The default in 0.32, which was directed in the init itself, was 3. When we moved to 1.x.x, we also added 64 bit methods to work on things. This is to help “future” prepare us for UEFI stuff. To access UEFI on a 64 bit system you need 64bit methods. With this, you’ll likely have noticed the bzImage and bzImage32 and init.xz and init_32.xz. The default init.xz and bzImage are both 64 bit. There is checking in the iPXE menu to load the proper pair of files. The message you got sounds like you installed the wrong architecture kernel for the init it was attempting to load.
In response to #3: How did apache crashing cause the image to be corrupt? That has anything to do with the image storage information at all. I think what you may have seen, as apache wasn’t running, that the Image did not move itself into the /images folder from the /images/dev folder, but this does not mean it was a corrupt image. The only times it communicates with the FOG server during the image is three parts. The first part is the initial Check-in. The second part is during the imaging and even then it’s only reporting the “progress” information. If the apache server fails it’s not going to stop imaging. If NFS failed, then you might have had an issue. The third part is after the image is complete, it communicates to the FOG Server to close the tasking and, in the case of uploads, moves the image from /images/dev/<MACADDRESS> to /images/<IMAGENAME>.
-
Dear Tom,
thanks for the fast reply. Sorry for my missunderstanding formulation. I knew that the Database problem ist just a logging Problem.
Your Infos helps me a lot understanding FoG more. I’m running Ubuntu LTS 12.04 32 bit so installed the 32 bit kernel. Meanwhile i changed back to the 3.14.2 Kernel just to test it… and the Problem described bevor came back. so i went into Fog Configuration >> TFTP Serrver and renamed FOG_TFTP_PXE_KERNEL bzImage to bzImage32. The same i did with FOG_PXE_BOOT_IMAGE intit.xz. Now it works fine.
In Addition to the Crash Problem: in deployed 4 Clients simultanously before without any Errors. the Crash occured while the Deploy of the next 4 Clients with autoshutdown Task. As i checked my FoG Tasks it told me that it was complete so i wanted to create new ones and it told me that the Image i wanted to use dosn’t exist, so i checkt my Ubuntu and saw the Errors… after Ubuntu reboot the Image was been restored but the deployed Clients were broken and i had to deploy them again.
Greetings
Andy
-
the kernels are the small operating systems that are downloaded and run on the clients when you run tasks on them. it does not matter if your server is 32 bit or 64 bit because these kernels run on the client, you can use the 64 bit kernels.
-
Dear Tom,
Dear Junkhacker,as told by Junkhacker in tryed the 64-bit Kernel and got These Errors:
- esas2r: driver will not be loaded because no ATTO esas2r devices were found
- request _module: runaway loop modprobe binfmt-464c
- Starting init: /sbin/init exists but couldn’t’ execute it (error -8)
- request _module: runaway loop modprobe binfmt-464c
- Starting init: /bin/sh exists but couldn’t’ execute it (error -8)
- Kernel_panic – not syncing; No working init found. Try passing init=option to kernel. See linux documentation/init.txt for guidance
Changed back to the 3.14.2 32-bit kernel without renaming it as i did before and it works.
Greetings
Andy
-
This is because you renamed the init from init_32.xz to init.xz.
There are automated checks during the bootup to ensure the correct pairing matches when the client is iPXE booting.
Can you try this:
[code]ls -l /var/www/fog/service/ipxe[/code] And print the results? -
Dear Tom,
here the print of the fog ipxe Directory. This is a Print of my main fog. This is what i did before:
- renamed the folowing in the FoG configuration => it worked
FOG_TFTP_PXE_KERNEL => bzImage32
FOG_PXE_BOOT_IMAGE => init_32.xz - renamed it back to bzImage and init.xz => dont worked
- renamed bzImage to bzImage.old and init.xz to init.old.xz
- cp bzImage32 bzImage (same with the init_32.xz)
- deleted the .old files
=> Worked again
if i install a new kernel FoG names it “bzImage” automaticly no matter which one it is 32- or 64-bit.
But if install the 64-bit Kernel it dont work.Greetings
Andy
[url=“/_imported_xf_attachments/1/1178_FoG ipxe.png?:”]FoG ipxe.png[/url]
- renamed the folowing in the FoG configuration => it worked
