Fog 1.01 will not deploy linux image
-
Try 1.1.0 SVN 1757 for linux deployments as 1.0.1 and prior did not have logical partition support.
-
[quote=“Rick Cooper, post: 28397, member: 22803”]Have three new servers to deploy. Built a reference server and imaged that one to fog. They are all identical, 7 drives on 3ware raid controller all seven are single disk of 3 different sizes. Six are sata and one is SAS.
All six of seven have linux partition and 2gb swap while the seventh is linux + 4gb swap and the image appears to have been saved correctly. When I attempt to deploy to another server (no OS at all on any disk all brand new) it goes through the following
:Send method NFS
send inventory done
checking in done
mounting files system done
checking mounted file system done
starting image push
using image New Servers
checking hard disks done
restore linux swap partitions
changing host name done
updating computer database done
database updated
task completedNothing at all is actually done the whole thing takes a few seconds (had to do debug deploy to copy info down). I know it’s working over all because I deployed a WIN7 image to three computers just 30 min before attempting to deploy the linux image. What am I missing? To deploy a linux (Centos 5.10) image to I first have to partition and format the drives?
Rick[/quote]
Is there anything special I need to watch for as was the case with 32 - 33b?
-
[quote=“Rick Cooper, post: 28435, member: 22803”]Is there anything special I need to watch for as was the case with 32 - 33b?[/quote]
Tried ti install svn got this when I went to update/migrated db
[B][SIZE=4][FONT=Times New Roman][COLOR=#000000]Fatal error[/COLOR][/FONT][/SIZE][/B][SIZE=4][FONT=Times New Roman][COLOR=#000000]: Uncaught exception ‘UnexpectedValueException’ with message ‘DirectoryIterator::__construct(/var/www/html/fog//lib/plugins/capone/hooks/) [<a href=‘directoryiterator.–construct’>directoryiterator.–construct</a>]: failed to open dir: No such file or directory’ in /var/www/html/fog/lib/fog/HookManager.class.php:180 Stack trace: #0 /var/www/html/fog/lib/fog/HookManager.class.php(180): DirectoryIterator->__construct(‘/var/www/html/f…’) #1 /var/www/html/fog/commons/init.php(221): HookManager->load() #2 /var/www/html/fog/commons/base.inc.php(6): require(‘/var/www/html/f…’) #3 /var/www/html/fog/commons/schemaupdater/index.php(3): require_once(‘/var/www/html/f…’) #4 {main} thrown in[/COLOR][/FONT][/SIZE][B][SIZE=4][FONT=Times New Roman][COLOR=#000000]/var/www/html/fog/lib/fog/HookManager.class.php[/COLOR][/FONT][/SIZE][/B][SIZE=4][FONT=Times New Roman][COLOR=#000000] on line [/COLOR][/FONT][/SIZE][B][SIZE=4][FONT=Times New Roman][COLOR=#000000]180[/COLOR][/FONT][/SIZE][/B] -
[quote=“Rick Cooper, post: 28474, member: 22803”]Tried ti install svn got this when I went to update/migrated db
[B][SIZE=4][FONT=Times New Roman][COLOR=#000000]Fatal error[/COLOR][/FONT][/SIZE][/B][SIZE=4][FONT=Times New Roman][COLOR=#000000]: Uncaught exception ‘UnexpectedValueException’ with message 'DirectoryIterator::__construct(/var/www/html/fog//lib/plugins/capone/hooks/) [<a href=‘directoryiterator.–construct’>directoryiterator.–construct</a>]: …[/COLOR][/FONT][/SIZE][/quote]This was my bad. I did a git not svn. When I did use svn the version was not 1757 it was, I believe 1765. is that going to be a problem? Won’t be able to test until tomorrow (actually since it’s 1:38am later today)
Rick
-
this should not be a problem when you upgrade to the latest svn
-
[quote=“Junkhacker, post: 28500, member: 21583”]this should not be a problem when you upgrade to the latest svn[/quote]
I tried the latest (I belive it was 1765) and that does exactly the same thing so I switched to 1757 and that does exactly the same thing. All done in less than 10 seconds, but nothing is actually done. I find no errors anywhere it just doesn’t do a thing as far as attempting to deploy the image and says it’s completed. Anywhere else for me to look or should I just move on to another solution that can handle multiple drives with multiple partitions? Works great for windows but I would have thought ext3 linux would have been easier.
Rick
-
please check Fog Settings -> Plugin System -> FOG_PLUGINSYS_DIR and make sure it is set to
[CODE]…/lib/plugins/[/CODE] -
[quote=“Junkhacker, post: 28650, member: 21583”]please check Fog Settings -> Plugin System -> FOG_PLUGINSYS_DIR and make sure it is set to
[CODE]…/lib/plugins/[/CODE][/quote]
No it was set as ./plugins. I just changed it, but the [COLOR=#555555]FOG_PLUGINSYS_ENABLED setting is unchecked. Do I need to enable that to deploy images? It’s going to be a while before I can test it again today[/COLOR] -
you do not need to enable that to deploy images, but the code might still be trying to look in that directory, which probably doesn’t exist
-
[quote=“Junkhacker, post: 28686, member: 21583”]you do not need to enable that to deploy images, but the code might still be trying to look in that directory, which probably doesn’t exist[/quote]
That did nothing, and it’s important to remember that the same day I deployed a win7 image to three PCs just before I attempted to deploy the linux image and failed
-
[quote=“Rick Cooper, post: 28805, member: 22803”]That did nothing, and it’s important to remember that the same day I deployed a win7 image to three PCs just before I attempted to deploy the linux image and failed[/quote]
I can also tell you now that this is linux specific as I just pushed a WIN7 image to that server without issue, so it will deploy windows but will not deploy linux to the same box
-
Ok now we are getting somewhere. Just for giggles I tried the Linux image deploy again (after successfully deploying a WIN7 image to sda) and it pushed the /dev/sda images and then quit again. So I pulled out a PartedMagic disk and created empty partitions on the other six disks and then attempted to deploy again. Yeah it’s on disk four of seven right now so it appears it’s going to go. Is this something on the fog side or partimag? It had no issue pushing a WIN7 image to an unpartitioned disk but absolutely would not do so for a Linux image.
-
What version of php are you running?
-
Okay, I’m working completely on theory here but it seems to me there wasn’t a (direct) issue with what FOG was/is doing.
Neither the kernel, nor the initrd support raid arrays, but your setup is a little different. FOG’s not seeing the raids themselves, but rather all volumes of the array as individual disks from what I’m gathering. Is this correct?
Beyond that, you state the /dev/sda is being written to but none of the other disks are?
Is the image setup for Multipart Multidisk?
In the image directory is there d[1-6].partitions or d[1-6].mbr files?
It sounds, to me, like it’s not getting the mbr on the other disks which could be a pointer because of the array itself. This would explain why you’re not having issues with it imaging the other 6 after telling it what partitions exist. But that’s why I ask if you have mbr files int he Image directory.
-
[quote=“Tom Elliott, post: 28816, member: 7271”]Okay, I’m working completely on theory here but it seems to me there wasn’t a (direct) issue with what FOG was/is doing.
Neither the kernel, nor the initrd support raid arrays, but your setup is a little different. FOG’s not seeing the raids themselves, but rather all volumes of the array as individual disks from what I’m gathering. Is this correct?
[/quote]
Yes, the are not multi disk they are exported as single disks[quote]
Beyond that, you state the /dev/sda is being written to but none of the other disks are?Is the image setup for Multipart Multidisk?
In the image directory is there d[1-6].partitions or d[1-6].mbr files?
[/quote]
Yes and no. /dev/sda was written to with a single drive multipartition WIN7 image so it would have only written to sda as a matter of course. HOWEVER, it wrote nothing when I tried to push the linux image until after I had pushed the win7 image, after the win7 image there were, of course, partitions on sda. That is what got me think maybe I should load up partedmagic and create an empty partition on each drive. Once that was done all 7 disks imaged[quote]
It sounds, to me, like it’s not getting the mbr on the other disks which could be a pointer because of the array itself. This would explain why you’re not having issues with it imaging the other 6 after telling it what partitions exist. But that’s why I ask if you have mbr files int he Image directory.[/quote]Yes there were mbrs for each drive in the image dir
There are dx.mbr, dxp1.img and dxp2.img for each drive as there should be (mbr, Linux and swap partitions)
Whatever the reason I am sure it was fog because pushing the win7 image worked right away on the very same hardware that I could not even get it to try and push to with the Linux image… did not even go through the initialization part (clearing, etc) it did after I added blank partitions to each drive. It wasn’t like partimage failed, it was never called at all. -
[quote=“Tom Elliott, post: 28815, member: 7271”]What version of php are you running?[/quote]
sorry I missed that one 5.3.28 -
Ok I know it’s been a while but I have really been tied up. After all this the machine would not boot,
GRUB (flashing cursor)
is all I got. My drive layout is
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 901G 5.6G 849G 1% /var
/dev/sda2swap
/dev/sdb1 901G 1.9G 852G 1% /home
/dev/sdb2swap
/dev/sdc1swap
/dev/sdc2 265G 220M 251G 1% /SquidCache
/dev/sdd1 224G 216M 212G 1% /boot (hd3,0)
/dev/sdd2swap
/dev/sde1swap
/dev/sde2 450G 798M 426G 1% /Special
/dev/sdf1swap
/dev/sdf2 450G 6.3G 420G 2% /
/dev/sdg1swap
/dev/sdg2 899G 15G 838G 2% /FileStorage
I could boot by using SuperGrub but when I tried to repair I of course rooted on (hd3,0) which is how the grub file is laid out. This did not work at all, same thing every time. So I finally pulled my head out and grub-install /dev/sda and it then booted. So to recap:
Fog would not install any image on an drive until I created a partition on them and once I did that and restored the image(s) it would not boot until a full repair of grub. There is definitely an issue here and you should be able to reproduce by deleting the part ion from a disk and attempting to re install (Linux, Windows image installed fine on blank disk) -
If you can, update to the latest and greated.
I’ve, since this problem occurred, followed fractal13’s suggestions on doing, basically, exactly this. From all accounts this should work now. The reason it didn’t before was most likely because of the partitions not being restored properly which was a factor of just the mbr being re-included.
Hopefully it will give you better success. And you shouldn’t have to re-install grub for it to work as we’re collecting all the data of partition. Of course, this is assuming your image type is set to linux, we’ve not yet just added it as there’s no real easy way to detect if grub is installed, but with any luck, all will work properly for you.
-
[quote=“Tom Elliott, post: 30372, member: 7271”]If you can, update to the latest and greated.
I’ve, since this problem occurred, followed fractal13’s suggestions on doing, basically, exactly this. From all accounts this should work now. The reason it didn’t before was most likely because of the partitions not being restored properly which was a factor of just the mbr being re-included.
Hopefully it will give you better success. And you shouldn’t have to re-install grub for it to work as we’re collecting all the data of partition. Of course, this is assuming your image type is set to linux, we’ve not yet just added it as there’s no real easy way to detect if grub is installed, but with any luck, all will work properly for you.[/quote]
I upgraded to the latest release last week (I was using the svn version for the current release) and I am re-uploading the image(s) now. I will know for sure tomorrow or the next day as I plan to use the new image to push out to server 3 of this group of identical servers. The image type is Linux and all disks multi-partition no resize I am keeping the old image if you would like me to try with that one first.
Thanks
-
I’m pretty sure we don’t really need the old, but seeing as you know how to recover using it, it couldn’t hurt to just have a backup just incase.
