Posts made by pac1085

We have been imaging E7240’s and E7440’s for well over a year with 0.32 ( though I don’t recall the kernel version ) and some of the new versions with no issues. Would need your FOG version / kernel version to help more…

I am having the same issue on 14.04.

sudo service mysql stop && sudo service mysql start fixes it.

Also seems to cause (maybe unrelated, not sure?) issues with FOGMulticastManager

Hi, I’m just curious if there have been any improvements to NFS security in version 1.x.x over 0.32? We are running 0.32 at multiple facilities and the two default NFS shares /images and /images/dev being read/write with no restrictions were brought up as findings in a recent PCI-DSS audit.

Am curious if anyone else had this issue? My understanding is that any sort of security on the NFS shares would require re-coding of portions of FOG.

Thanks

[quote=“BPSTravis, post: 26772, member: 22444”]IF you were able to have the server configured for pxelinux.0 in what situation would a user not be able to get it updated to undionly.kpxe?? I don’t know of any organization that locks out their DHCP server, and if they did I doubt they would have the ability to use FOG as a PXE server to begin with.

There is always SOMEONE who can access and change the DHCP server, if not, you have bigger problems to worry about than the FOG install script.[/quote]
Organizations that have strict change management protocols make this difficult… In our case the actual FOG servers are managed by the local operations teams - so upgrading to 1.0 is easy, but any changes to server infrastructure including DHCP have to go through a drawn out change management process

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

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

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

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.

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.

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)

It is erroring out on me when I go to upload an image. Does this if i select partimage or partclone… any ideas?

[img]http://i.imgur.com/Yna3aPT.jpg[/img]

ok thanks. svn and bt sync are blocked at work so downloading from your site is the only option I have.

have you been updating the 1.0.0.tar.bz2 on your site with each new revision or will i have to get them manually?

Incase anyone else has this problem - It seems to have resolved it self.

The image I mention above was never sysprepped. I sysprepped it, uploaded it as multiple partition - single disk, and it worked fine multicast. After that I noticed the hidden partition shrunk from 500mb to 100mb. I figured I’d try uploading it as NTFS resizable - and go figure, it works fine multicast now.

Odd

Yes, I’m able to unicast it just fine.

As a test, I narrowed it down. If I set the image to Multiple partition - single disk, it unicasts and multicasts fine.

It seems to be an issue specific to this image, and NTFS resizable - single partition

fogadmin@rocrtpfog01:/images$ ls -lsah /images/apd/
total 16G
4.0K drw-r-xr-x 2 root root 4.0K 2012-09-11 10:00 .
4.0K drwxr-xr-x 14 fog root 4.0K 2012-09-11 16:12 …
8.7M -rw-r–r-- 1 root root 8.7M 2012-09-11 10:00 rec.img.000
16G -rw-r–r-- 1 root root 16G 2012-09-11 10:26 sys.img.000
fogadmin@rocrtpfog01:/images$

the image name is as follows:

Image-20120911
Same naming convention I’ve been using forever.

To test, I renamed the image folder to ‘apd’ and updated the image definition - no change.

The only thing different is the base image im using - i deployed it to this machine with MDT before uploading it to FOG. MDT made a 500mb system hidden partition instead of 100 or 200 like I’ve seen before. Could that have anything to do with it?

I created a new Win 7 image - uploaded to FOG fine. It unicasts fine. However when I try a multicast, immediately after the ‘resizing disk’ page, it comes to a blue screen saying it’s unable to read stdin.001.

Multicast works fine on this server - with other images. It seems to be specific to this one image. Any ideas? The hosts are set to win 7 in the config.

We repurpose PC’s often, and they are usually already registered in the database and have old snapins associated to them. With 20+ snapins, its a tedious process to select each snapin individually and click remove. I imagine this feature would be very easy to write but don’t have the programming experience to do so myself.

remove the file /opt/fog/.fogsettings