Fixing the chain bootloading issue on the other thread i posted here also fixed this kernel panic issue. thank you Tom.

@Tom-Elliott That did the trick, thank you.

@Quazz sometimes the simple ideas are the best ideas. The image seemed to be not OK so that was the reason for all the problem.

I created a new image which I successfully deployed on the machine. Problem solved. 🙂

After updating FOG to the latest (seemed to be a pretty big update), it succeeded in deploying it with the task (no idea if it would have done this automatically yet though)

@Tom-Elliott

I upgraded to :

Thu Jun 23, 2016 8:52 am
Running Version: 8229
SVN Revision: 5742

It´s work fine, but i have a problem with the multicast I need to run:

service FOGMulticastManager restart
service FOGMulticastManager status

Thank you, Everyone, for the updates and fixes.

Regards,
bogg

@paat said in Installation ERROR: Fresh Install with current git trunk version.:

@Tom-Elliott Thank you Tom. Now the install script runs flawlessly.

This should now be fixed.

@george1421

@george1421 said in Intel Raid0 Image Capture:

@jpmartin How many of these systems are you trying to restore at one time?

Just 2 right now. If it makes it to production it could easily be 25+ at a time.

Understand that each of these systems will need to be registered in FOG and their “Host Kernel Arguments” and “Host Primary Disk” updated to the new settings. I would recommend you create a new group assign these hosts to that group and then use the group update function to set these parameters for all hosts in that group. That way you can be sure they are all the same.

This is actually what I did. When I tried to edit those settings for the group, the Primary Disk and Bios Exit Type (Grub_First_HDD) didn’t “stick”. I’d click update and those fields would return to default values. When I viewed the 2 hosts individually, the values above were also cleared/reset to default so that very easily could have been the problem right there.

I just set them back to the correct settings individually and just finished a unicast deployment to the machine the image was created with.

I deleted the existing RAID0 array on that machine and renamed it to something different as well. Fog didn’t care. So I don’t think that was the issue.

Please also understand we are waking the bleeding edge here. We did just prove that unicast imaging worked. Throwing multicasting into the picture may expose some other bugs (since that wasn’t tested). The random /dev/sda1 is troubling. Now I didn’t go in and change the volume name to see if it messed with the /dev/md126 naming (I’ll do that later for completeness) I did notice under /dev/md/ there was a device with the name of the volume I created Volume0_0, but again we are referencing the logical names of /dev/md126 so the actual volume name should not matter.

Good to know. I’ll do what I can to break stuff and report what happened.

EDIT: Just to update, I corrected the settings for each host individually instead of using group management, created a multi-cast task for the group (I didn’t change any host settings on the group management page hoping it would use the host specific settings) and successfully imaged both hosts via multicast.

Upate!!

We got this fixed. The FreNAS node on our storage group (not the master), was set to get it’s IP address by DHCP. The DHCP lease went up and the address changed. When this happened it caused this error to appear.

I reset the address on our FreeNAS node of our storage group, and everything works perfectly.

Moral of the story, do not set up any of your servers with DHCP addresses when you’ve got stuff pointing to said addresses!!

Thanks for making me think harder.

Cheers,

Joe Gill

@Tom-Elliott Updated, on 8217, seems to be faster! W00t!

@Wayne-Workman @Tom-Elliott, Thanks guys! I had to use Wayne’s commands to get into and out of mysql and Tom’s commands to clear out the DB table.

sddq1 have good size yes (40G)

i don’t know why vmware don’t call it sda

You can actually solve this issue - the problem was the wrong ip address - thanks guys for the support 🙂

🙂 🙂 🙂

0_1466584964300_Screen Shot 06-22-16 at 09.42 AM.PNG

@Tom-Elliott Thank you again for your response
This screenshot is from another fog, which is 100% functional.
My fog does not display the network graphic and freeze dashboard.
cordially

Wanting to point out to readers this problem was due to no remote access enabled on the database, and the answer is in the wiki article “Troubleshoot MySQL”.

@moses Possibly just start by re-installing those ssl and cert packages? rpm -qa | grep -e ssl -e cert to find the packages.

Done.
Now I’m at…

Running Version: 8197 SVN Revision: 5726

I can now select a very recent date that a PC was imaged on (6/15/16). However, another PC was just imaged a few hours ago and today’s date doesn’t show up as an option to choose from. Also, now when sitting at the dashboard /var/log/httpd/error_log now continuously scrolls…

PHP Warning: curl_multi_add_handle() expects parameter 1 to be resource, null given in /var/www/html/fog/lib/fog/fogurlrequests.class.php on line 108, referer: https://10.1.10.212/fog/management/index.php

0.32 images would be in partimage format, so you’d set this per image I think in FOG Trunk, or in fog settings somewhere in 1.2.0. I’d suggest as soon as you’re able to download those images, to re-upload them so they are in the new format.

While I still stand by what I’ve already said - just try multicast and see if it works - for same images at once. Stick computers into a group, and initiate multicast from the group.