Posts made by Bruce D

Tom? Junkhacker? Anyone? What next?

Being kicked out of my office for the evening. Will take whaqt ever steps you suggest in the morning.

I know you have to ask that, Tom.

Yes, the path in the WebUI and the actual filesystem path now match, letter for letter, as /images/MyImage. Capitalization verified. Do I need a .mntcheck file in that directory? Right now,m the only things in the image directory are the sys.img.000 (big file) and d1.mbr (tiny file).

[QUOTE]
I’d recommend moving the /images/dev/<macaddresshere> to /images/<imagename>[/QUOTE]

Done…but no joy. BTW, I had to create the /image/<imagename> directory. Yes, I chown’ed to fog:root and chmod’ed to 777 (and verified that it took)

It looked to this n00b like it did:

Image Management has accurate “Uploaded” times, and the Scheduler log says:
[07-01-14 2:05:21 pm] * 1 active task(s) awaiting check-in sending WOL request(s).
[07-01-14 2:05:21 pm] - Host: PC1 WOL sent using MAC: aa:bb:cc:dd:ee:ff
[07-01-14 2:05:21 pm] * No tasks found!

Hmm…all is correct, with one possible exception:
The image path is /images/<imagename>
BUT, in the filesystem, the actual path is /images/dev/001d09d73937/sys.img.000
That’s just where Fog put the images when I created them…including the Hex.

(oh, and “/images” is a symlink to /home/fog/images)

-Bruce D.

Hi Tom,

It’s v1.1.2. The first image is a Single Disk image, Win7. The second image is a a Multiple Partition Image - Single Disk, also Win7.

-Bruce D.

Both are correct.

Fresh install of 1.1.2, installed on CentOS 6.5, running under VMware Player 6

I uploaded an image to FOG (the Scheduler log says successfully) and am trying to deploy the image to an identical computer. The images is a Single Disk image. When I try to create the task in the Fog WebUI, I get the following error message:
[QUOTE]Download task failed to create for PC1 with image A
To setup download task, you must first upload an image[/QUOTE]

OK, so I tried this on a different computer - same result.

Tried to manually pull an image from the PXE menu. The error message on both computers is only “An error has been detected.”

Then I followed the instructions in: [QUOTE][url=“http://www.fogproject.org/wiki/index.php/Troubleshooting_an_image_push_to_a_client”]www.fogproject.org/wiki/index.php/Troubleshooting_an_image_push_to_a_client[/url][/QUOTE]
That is, I booted both clients in debug mode and tried to apply the image manually. I get all the way to the partimage restore, and partimage immediately aborts the operation with no error, just “Aborted”. That happens with both the command-line and gui versions of partimage.

So, I tried to do partimage imginfo. Same “Aborted”.

At this point, you’re no doubt thinking that there’s a problem with the image. I had the same thought, so I uploaded another image (this time a Multiple Partition Image - Single Disk, just to change things up) from still another computer (this is the 3rd computer, but it’s DIFFERENT hardware). All the same problems in all same places.

So, I CAN PXE boot, connect to the server, upload images, and see the image files. I just can’t deploy the images.

Help!
Thanks in advance,

Also recommend that the 50-Gb root partition issue in CentOS be discussed, and instructions be added to move the images directory to a larger partition as part of the installation instructions, to avoid the likely issue of someone trying to upload an image bigger than 50 Gb to the root partition.

Hi Tom,

On the page:
[url]http://www.fogproject.org/wiki/index.php/Installation_on_CentOS_6.4[/url]
at #Repositories,
the fourth line in the 32-bit section reads:
rpm -Uvh [url]http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.i686.rpm[/url]
That is an invalid address. It should be:
rpm -Uvh [url]http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.i686.rpm[/url]
(note at the end, “.rf” should be inserted after “el6”)

The 4th line in the 64-bit section should be edited similarly.

-Bruce D.

Can anyone tell me what this is?:
/dev/mapper/vg_fog-lv_root

In my fstab, it’s mounted on the root of my filesystem, and has 50 Gb available. However, it also seems to hold the image uploads, and my systems’ images are much larger than 50 Gb. After trying to upload an image to the FOG server, I spent all afternoon figuring out the sudden “Filesystem / has 0 bytes remaining” error messages that were popping up.

OS is CentOS 6.5, fully updated
FOG v is 1.11

OK, I did the test you requested. I changed the permissions to 644 and the ownership (again) to fog:root using the commands you gave me, and PERMISSION DENIED. Change permissions back to 777, and all is well.

More info:
666 results in DENIED
766 DENIED
676 DENIED
667 ALLOWED ??? (WTF?) (Although the PXE boot does not complete; it stops at "Booting from SAN device 0x80)

Now, I’m no Linux guru, but I’d say that was definitely NOT what I expected to see.

-Bruce D.

[quote=“Tom Elliott, post: 31045, member: 7271”]Well,

Can you do one more test?

We know 777 perms works, but that leaves it open for anyuser logged in to the system to delete it.

Can you reset the mod to
[code]chmod -R 644 /tftpboot
chmod -R fog:root /tftpboot[/code]

My guess is the selinux wasn’t actually allowing the changing of the permissions when you were trying before.

Chances are most likely the restorecon released the locking rights which had been established upon your initial reboot after the /etc/sysconfig/selinux change (which didn’t work).[/quote]

Hi Tom,

I left work immediately after it started working. However, I will be happy to perform the tests you’re requesting when I get back there Monday morning. I’ll let you know what happens.

-Bruce D.

[quote=“Tom Elliott, post: 31045, member: 7271”]Well,

Can you do one more test?

We know 777 perms works, but that leaves it open for anyuser logged in to the system to delete it.

Can you reset the mod to
[code]chmod -R 644 /tftpboot
chmod -R fog:root /tftpboot[/code]

My guess is the selinux wasn’t actually allowing the changing of the permissions when you were trying before.

Chances are most likely the restorecon released the locking rights which had been established upon your initial reboot after the /etc/sysconfig/selinux change (which didn’t work).[/quote]

Winner!

I didn’t think to re-change the ownership and permissions after the first restorecon. After your last post reminded me, I changed them back to fog:root and 777, and now the client is booting! Woo-hoo!

So, it looks like the restorecon (and then re-changing the permissions) did it. Any idea what the problem was?

(Oh, and a BIG thanks! I’d never have figured that out on my own.)

no change after reboot. still permission denied.

tried it withOUT reboot, no change. rebooting now.

Grrrr, indeed!

Negative. Permission denied. (That is, using the command prompt tftp utility on the FOG VM itself.)