If it’s in svn I can test it by deleting the part tables and try again tomorrow

[quote=“Tom Elliott, post: 30374, member: 7271”]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.[/quote]

Well I deployed the second image set today and as with the previous attempts it failed to deploy until I created a blank partition table (via PartEd) on each drive. I did find something else out that might help. When I created the blank partition tables I missed sdd, when I deployed it did sda-sdc correctly but then deployed the sdd image to sdf and f to g so when it’s restoring the images for some reason of the partition table is blank it treats that drive as non existent… instead of failing sdd it just put in on hd4 instead of hd3. Is there a way you test for the existance of a partition table and apply one in the even it’s missing? Again this was not an issue with windows images just the linux image(s). On a positive note, once I corrected the missing part table on sdd and redeployed the image I did not have to repair grub this time

[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

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)

[quote=“Tom Elliott, post: 28815, member: 7271”]What version of php are you running?[/quote]
sorry I missed that one 5.3.28

[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.

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.

[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

[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=“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]