Bugs in FOG 1.0.0
-
What I did was copy an existing image from a 0.32 box (set to partImage), deploy to a machine, this was my attempt to re-upload it to a new image definition (tried partimage and partclone with no success)
-
Also, it is an MBR partition, not GPT. Optiplex 3020. Sorry to keep posting but I can’t edit my posts in Firefox. Get a blank window.
-
Did you do a scrub on the hard drive that you are attempting to image? Could it have GPT garbage left over on it?
-
This PC was imaged with a known good image. I then updated the image and am attempting to upload the new one. There is no GPT stuff that I can see.
I did notice that for some reason there was 4.6gb unallocated space, I just extended the primary drive into that and am going to try uploading again.
-
[quote=“pac1085, post: 26729, member: 144”]This PC was imaged with a known good image. I then updated the image and am attempting to upload the new one. There is no GPT stuff that I can see.
I did notice that for some reason there was 4.6gb unallocated space, I just extended the primary drive into that and am going to try uploading again.[/quote]
You could try blasting the partitions and recreating a basic one and downloading the image (from 0.32 because deleting the partitions will obviously destroy the data on them). You can do so with a live linux CD, you can use a windows disc to delete and re-instate the ntfs partitions, or you can use the debug mode of fog to edit and create partitions.
I would start with a partition I knew was absolutely correct and download my image, then I would try to upload to the new server.
I would do this to make sure that any previous existing partition data isn’t causing troubles.
Then I would step it a little further, such as pushing the image from 0.32 and allowing the image to complete its setup on that machine to verify that nothing is corrupt and the image is still complete. There you could do some troubleshooting and tweaking to help figure out why it is failing on the next upload. If your image installed okay and you didn’t find any issues, I would run a compatibility check on the machine, fog will tell you if it finds something that will make it unhappy.
This will help us to determine where and why your image is failing so we correct the issue, be it the image, the hardware, or a problem with the code.
Is the machine you are using a new machine? Have you imaged on it before? How old is the machine? Could it be possible that the hard drive could have complications or could be failing? Have you trying running a disk repair after deploying to see if that would have any affect before uploading it again?
-
The picture is telling you the image contained within has GPT Structures on it. I don’t know why this is such a hard concept. Just because you don’t see it, doesn’t mean it can’t possibly be. What checks did you perform that actually tells you there is NO gpt data? Did you double check? This known good image, is it a GPT based image? What version and revision of FOG are you running? Is the particular image SUPPOSED to be an MBR, which never got generated properly? Is the system still with UEFI enabled bios? Did you try running the command line: [code]gdisk -l /dev/sda[/code]
-
[quote=“Tom Elliott, post: 26733, member: 7271”]The picture is telling you the image contained within has GPT Structures on it. I don’t know why this is such a hard concept. Just because you don’t see it, doesn’t mean it can’t possibly be. What checks did you perform that actually tells you there is NO gpt data? Did you double check[/quote]
Checked with diskpart in windows, the drive is not listed as GPT drive.[quote]This known good image, is it a GPT based image[/quote]
No. MBR. We have never used GPT images.
[quote]What version and revision of FOG are you running?[/quote]
1.0.0. Do not know the revision number since it was not in the tarball. Filesize of fog_1.0.0.tar.bz2 is 52492413 and I downloaded it on 5/5.
[quote]Is the particular image SUPPOSED to be an MBR, which never got generated properly[/quote]
Yes, it is supposed to be MBR. And everything
[quote]Is the system still with UEFI enabled bios?[/quote]
No, secure boot off, legacy boot mode on.
[quote]Did you try running the command line: [code]gdisk -l /dev/sda[/code][/quote]
No, I can’t find out how to get into debug mode on 1.0.0 - is it hidden somewhere? Did not see anything in the WIKI on this.
Edit: I think I figured it out (how to get into debug mode), will update in a sec with the results.Also, this is on brand new hardware - an Optiplex 3020.
Thanks! -
OK, I think I figured it out. Sorry, I am not familiar with gdisk, and I’ve done this many times before without issue on 0.32 - which is why I ended up posting in this thread.
When I ran gdisk -l /dev/sda it did say there was damaged GPT.
I followed the procedure on this page: [url]http://www.rodsbooks.com/gdisk/wipegpt.html[/url] to wipe out the GPT. Now the disk is MBR only. Will be attempting upload to fog in 20 mins or so. I believe that will fix it. Feel free to move my posts into another thread.
Update: That fixed it. Thanks for the guidance everyone
-
just for future reference, the “problem” is that it IS “brand new hardware.” Dell shipped the drive with a GPT windows install, and you have to properly wipe that out in order to image with legacy.
-
Yeah, I fully understand that now. I guess I actually knew that too, but wrongly assumed that the GPT stuff was wiped when I applied the first image. I never noticed this issue with 0.32, perhaps because it was not GPT aware (right…?) Oh well, it’s working like a charm now
-
Tom, given the number of people that have tripped over this, is there any way that the init.gz could be modified to wipe the gpt at the start of deploying an mbr image?
-
jbsclm,
It already does this by default. The problem was during the “upload” process, it detects if it is an MBR style disk or GPT style disk. If GPT is present, it backs up the “mbr” as GPT, and if it’s not preset as MBR. The problem, in this case (and I’m guessing many others) isn’t FOG’s issue. It’s that the Person creating the image (as this is an upload task) is assuming everything is ready without preparing the system properly. That I can’t do anything for. If you want to upload an MBR image, you need to make sure the disk and environment are prepared for that, especially if switching from GPT to MBR.
-
GUI is broken in groups. To reproduce, goto Groups, select a group and select e.g. Membership. I run r1621. Same happens on others like Image Association …
More info: Does not happen on all my groups. A group with 5 hosts is OK while a group containing 245 hosts makes the GUI broke.
-
[quote=“pmonstad, post: 26759, member: 17422”]GUI is broken in groups. To reproduce, goto Groups, select a group and select e.g. Membership. I run r1621. Same happens on others like Image Association …
More info: Does not happen on all my groups. A group with 5 hosts is OK while a group containing 245 hosts makes the GUI broke.[/quote]
Provide more information. I don’t have a group with 245 hosts as I don’t have 245 hosts. What’s the error logs state?
This is how you can help us help you without getting backlashing answers. Sometimes the descriptions are enough, but for cases like this, how’s it broken? You getting a white screen? You getting a screen, but only part of the hosts are displaying? What’s it doing that you think it’s “Broken?”
-
Broken in the same meaning as posted a couple of days ago. See screenshot: [url]http://awesomescreenshot.com/0812rutycf[/url]
If you need to test with many hosts please import enclosed file.
[url=“/_imported_xf_attachments/0/722_host_export(1).txt?:”]host_export(1).txt[/url]
-
Alright,
I must thank you pmonstad for providing the host list, but I’m not seeing the problem even after importing th e list and putting all of them into the same group. I’d check that all is well, first, by deleting the fog web directory completley and copy the trunk/packages/web back as the original fog web directory.
Then run Debian/ubuntu setup:
[code]sudo chown -R www-data:www-data /var/www/fog
sudo chown -R fog:www-data /var/www/fog/service/ipxe[/code]OR if redhat based setup.
[code]chown -R apache:apache /var/www/html/fog
chown -R fog:apache /var/www/html/fog/service/ipxe[/code]Edit the commons/config.php to make the changes you require (i.e. mysql host, password if set.)
Then try again.
If you’re still getting the same breaks in the page (the reason why display looks funny) get me a copy of the apache error logs. See my signature for the location of those.
-
Thanks! I’ll check the apache log file at work tomorrow. The strange thing is it only breaks the GUI in this particular group of 245 hosts, not my other groups. As mentioned in other threads there have been problems with the creation of groups in previous relewses. I’ll delete the group and recreate another one to eliminate fault possible been in previous releases of FOG.
-
Testing the problem with broken GUI. I deleted the group (not hosts) and recreated the group with the same name. Got the error (broken GUI as screenshot in another post shows). Did a new test adding som other hosts to a new group. Now I am not able to list all groups. Blank screen and an error in apache log:
[Fri May 09 14:05:24 2014] [error] [client 172.20.0.45] PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 82 bytes) in /var/www/html/fog/lib/db/MySQL.class.php on line 119, referer: [url]http://192.168.60.254/fog/management/index.php?node=group[/url]Now I am not able to either search nor list my groups.
-
Hm, i fixed this by editing phpi.no memory_limit = 32M (was 16). This seems to have cured the broken GUI as well. Groups containing many hosts was the problem.
Could there be some check or warning during FOG installation to warn the user about this? Not a problem when you know where to trouble shoot, but a pain when you dont.
-
[quote=“pmonstad, post: 26814, member: 17422”]Hm, i fixed this by editing phpi.no memory_limit = 32M (was 16). This seems to have cured the broken GUI as well. Groups containing many hosts was the problem.
Could there be some check or warning during FOG installation to warn the user about this? Not a problem when you know where to trouble shoot, but a pain when you dont.[/quote]
So just to test, I set my memory_limit to 16M and restarted the httpd service on my CentOS server. I still have your export loaded and tested everything out. All still seems to be working perfectly fine.