Posts made by Rick Cooper

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]

[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

[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

[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: 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 completed

Nothing 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=“Junkhacker, post: 28401, member: 21583”]run a Client System Information (compatibility) test from the boot menu[/quote]

Sorry should have mentioned I did that before the debug deploy
All seven disks had the following Error unrecognized disk label (but I assumed that is because there is no OS)
Results
This computer appears to be compatible with fog
Network pass
disk pass

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 completed

Nothing 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

One, initial question. I was using the 33b version and just upgraded to the git version which was supposedly 33b but shows 1.0.0 on the pages and in the changelog. The change log states all images must be re-uploaded but does that pertain only to the 32 version or also to the 33b version?

Also, anywhere that might return zero hosts is throwing an error stating an issue with the foreach in getHostCount, first place I saw it was in the group management section and I assume it was because of the membership count column. Also when you edit a group without current members it throws an error at line 240 in GroupManagementPage.class.php and this is, again , caused by trying to use an undefined or empty value in a foreach. I fixed the issues by validating anything returned by calling ->get(‘hosts’) with is_array()

[quote=“Tom Elliott, post: 24170, member: 7271”]Look,

I can only try what I know, but as I’m not in either of your environments, I can’t tell you what’s wrong. I need to know details.

Eric, your issue appears (to me) to be with not finding the /init.xz and /bzImage files. When you installed 0.33b did you install fresh or perform an upgrade? If you upgraded, you’ll need to change the init.xz and bzImage lines in FOG Settings to say only init.xz and bzImage respectively as my guess is you upgraded.

Rick,
While I understand the frustration, I’d recommend taking a look at your options 66,67 lines and verify they’re pointing in the proper locations. The biggest change that you should need is instead of looking for pxelinux.0 change it to undionly.kpxe.

Thank you,[/quote]

Ok, I really did not understand exactly what you mean above, but I did remember reading about the [SIZE=2]undionly.kpxe change and I did not not that. I tried to work it out about four times and finally I just removed fog entirely (almost more about that ) and did a scratch install of 0.33b. I was able to PXE boot the clients but when I pulled the image it got stuck not being able to move it again, but this time it gave a reason (bad user name or password) and I realized I did not remove the fog users so I grabbed the new password out of the config.php and updated fog’s system passwd and worked [/SIZE]immediately[SIZE=2]. That was on a DD copy. I decided to go ahead and pull another image as single disk multi-partition no resize and that went through pretty quickly.[/SIZE]

[SIZE=2]Deployed the image and it worked right out of the gate. I will try doing a couple more but 0.33b certainly worked much better in every way including more information as to what was going on even in DD mode. There are a few errors running the 0.33b web interface but they seem like they are probably little things. For instance when you save a host an error comes up that says something to the effect of FOG ERROR: Location record not found error. No data array or ID passed… but everything is updated.[/SIZE]

[SIZE=2]After fighting with fog_0.32 for a few days I would recommend you think about a wide beta because it certainly worked out well for me once I stopped trying to update and just did a fresh install[/SIZE]

[SIZE=2]Thanks [/SIZE]

[quote=“Eric V. Baker, post: 22998, member: 22214”]Hi to all!

I am attempting to upload a Windows 7 image from an HP Z230 to my FOG server 0.32. On upload we are getting the[SIZE=3] “unable to move /images/dev/macaddress to /images/name-of-image” [/SIZE]problem seen before. I did the chown -R fog.root /images and chmod -R 777 /images and are still getting the problem. looking at the /images/dev folder I see the folder of the MAC of the PC being used to create teh image. inside it is a d1.mbr file. In /images there is no folder created for the name of the image file that should be created.

Any ideas?[/quote]
Has this ever been resolved or should I just move on to clonezilla? I mean really, I have followed all the recommendations, I have manually logged into ftp server as fog and have not an an issue. BUT every time I try and pull an image it cannot move from /images/dev to /images… and If I move the image to where it is supposed to be and try and pull it I get a quick GFY and in debug you find fog unable to mount the nfs share. I have totally reinstalled fog to no avail, I installed the 33b version and that cannot even boot PXE on the machines… so anyone have a clue or do I just move on

RIck

[quote=“Tom Elliott, post: 23986, member: 7271”]Do me a favor and remove the cd from the drive and try again.

Something tells me the image it captured is from the drive itself, rather than your actual hard drive, though I don’t know why it would. Can you try using my kernel as I don’t allow it to read the cd drive at all, this should mean you don’t have to worry about sr0 trying to load as a viable drive.[/quote]

Also, as I see you are a developer, all of the PCs I am going to deploy to (as well as the reference machine) are UEFI… Will this cause an issue with a partion image or should I DD them to make sure UEFI data remains untouched? They are all Compaq 6200 pro boxes and I have found there is no way to set PXE as a default boot option when EFI is in play, they will not boot to windows wihout the EFI windows boot manager source being selected and network is only in the legacy section which cannot be prefered over EFI source :-[