Posts made by afmrick

We got it to work manually across or WAN by adding the following flag to [B]udp-sender[/B] command (above):
[code]–mcast-data-address 239.blah.blah.blah[/code]
The default [B]232[/B].blah.blah.blah is reserved/special apparently. Here’s a link that sort of breaks that down:
[COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR]

To fix it in FOG, I add that command line parameter to every [B]udp-sender[/B] command in [B]/opt/fog/service/common/lib/MulticastTask.class.php[/B] and restarted all the FOG services. Everything works just the way it should have now. However, adding this parameter to every udp-sender command in the file is just a “make-it-go” hack that I’ll have to clean up next week. This should really be an option to set within FOG. …Still, Yahoo!!!

Note: [B]blah.blah.blah[/B] is the last 3 octets of the FOG server’s IP address.

MulticastManager fires up “udp-sender”

You can do whatever you’d like from the command line with mysql. This one will show you the names of all the images in the images table (without column names):
[CODE]mysql --batch -u fog -pmyFOGpassword -Dfog --skip-column-names -e “SELECT imageName FROM images;”[/CODE]
Here’s the same thing except it stores all the images names in the “image_names” variable which can be handy in a script:
[CODE]#!/bin/bash
image_names=$(mysql --batch -u fog -pmyFOGpassword -Dfog --skip-column-names -e “SELECT imageName FROM images;”)
echo “image_names = $image_names”[/CODE]

For general scripting help, I really like the Advanced Bash Scripting Guide at [url]http://tldp.org/LDP/abs/html/[/url]

The first google hit for each of those models suggests that the Lenovo’s may have bigger hard drives. If that’s true and your image type is non-resizeable then that could be an issue. …but, that’s pretty far into wild guess territory.

I don’t have a Fedora box laying around but, the first google hit for php-gettext on fedora showed “php-php-gettext” FWIW. So, assuming that’s correct then change php-gettext to php-php-gettext in that file and try again. If you get any more errors then correct 'em and try again!

You could add “[B]vga=771[/B]” as a Kernel Argument for each host or as a global setting under [B]Other Information > FOG Settings > General Settings > FOG_KERNEL_ARGS[/B] to force it to 8-bit 800x600. For other settings see [url]http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers[/url]

…or try different kernels until you find one that makes all your clients happy.
[url]http://sourceforge.net/projects/freeghost/files/Kernels/[/url]

If you check out fog_0.32/lib/redhat/config.sh you’ll see a line like this:
[CODE]packages=“httpd php php-gd php-cli php-gettext mysql mysql-server php-mysql dhcp tftp-server nfs-utils vsftpd net-tools wget xinetd tar gzip make m4 gcc gcc-c++ htmldoc perl perl-Crypt-PasswdMD5 lftp clamav-update”;[/CODE]
When the install failed at “php-gettext” it probably didn’t install any of the packages listed after it. IIRC, there’s a couple package names you might have to modify in that list for Fedora (or repositories) …and possibly a path or two in the script.

Cool!
We had an issue with the 780’s hanging at “Restarting system” after imaging that went away when we added “[B]reboot=bios[/B]” to [B]Other Information > FOG Settings > General Settings > FOG_KERNEL_ARGS[/B] (or just for that host or group in “[B]Host Kernel[/B]”). Since you’re not having that problem I feel like I gotta revisit it again.

You can do it from the command line. For example, something like this would delete -ALL- scheduled tasks:
[CODE]# mysql -u root -Dfog
mysql> truncate table scheduledTasks;
mysql> quit[/CODE]

I’ve got Dell Optiplex 780’s and they works fine with the Kernel-3.2.4.core kernel available at [URL=‘http://http://sourceforge.net/projects/freeghost/files/Kernels/’]http://sourceforge.net/projects/freeghost/files/Kernels/[/URL]
Our Optiplex 990’s pause at that “[FONT=Tahoma]vbe_init() failed with -22” for a minute or so but, work fine otherwise. There’s probably some use flags I could pass to eliminate that or a different kernel but, so far the 3.2.4 core works with all the Optiplex’s we tested on FWIW[/FONT]

FOG stores the mysql password in /opt/fog/service/etc/config.php AND /var/www/fog/commons/config.php. You can try firing up mysql from the command line to make sure that the information in those two files is correct to start with:
[CODE]mysql -u FOGuser -pFOGpassword -Dfog[/CODE]
…and while you’re in there, assuming that worked, you can change the fog logon password in the users table.

Just more information:

I’m trying this again manually from the command line:
From the server i am running:[CODE]udp-sender --file /opt/fog/log/multicast.log --ttl 32 --min-receivers 2[/CODE]
and from two different clients I’m running:[CODE]udp-receiver --mcast-rdv-address <myFOGserver>[/CODE]
…and here’swhat I get on the server:[CODE]# udp-sender --file /opt/fog/log/multicast.log --ttl 32 --min-receivers 2
Udp-sender 2007-12-28
Using mcast address 232.blah.blah.blah
UDP sender for /opt/fog/log/multicast.log at <myFOGserver> on eth0
Broadcasting control to 224.0.0.1
New connection from <TEST-HOST-1> (#0) 00000009
Ready. Press any key to start sending data.
New connection from <TEST-HOST-2> (#1) 00000009
Ready. Press any key to start sending data.
Starting transfer: 00000009
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
Bad command 0200
Bad command 0200
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=103166
Disconnecting #0 (<TEST-HOST-1>)
Disconnecting #1 (<TEST-HOST-2>)[/CODE]

The “Bad command 0200”'s appear when I “Press any key to start receiving data!” on the clients. If I add the “–nokbd” flag to all three then I don’t get the “Bad command 0200” error but still get the “Timeout notAnswered” errors.

To me, this suggests that the “OK Go” message is not getting communicated correctly. It still works fine to only 1 client.

I can’t multicast an image to multiple hosts in a group. I don’t think this is a FOG issues as much as it is a UDPCast issue but, I’m running out of ideas.

Things I CAN do:
[LIST=1]
[]I can create a group with a single host and multicast to that (pointless but it shows it can work).
[]If I multicast to a group and prevent all the hosts except one from checking in (say by unplugging them) then it will happily multicast to that single client after it times out (UDPSENDER_MAXWAIT = 90).
[/LIST]
Below is the log files where:

[COLOR=#ff0000]myFOGserver[/COLOR] is running Scientific Linux 6.2 (Carbon), FOG 0.32, FOG Kernel-3.2.4.core and Syslinux 4.05
[COLOR=#ff0000]TEST-HOST-1[/COLOR] is a Dell Optiplex 990
[COLOR=#ff0000]TEST-HOST-2[/COLOR] is a Dell Optiplex 780

I also swapped out the IP’s in the log files with the above host names.

Here’s the udp-sender command running on the FOG server (wrapped to make it easier to read):
[CODE]sh -c gunzip -c “/images/TestLab/rec.img.000” |
/usr/local/sbin/udp-sender --min-receivers 2 --portbase 63140 --interface eth0 --max-wait 90 --half-duplex --ttl 32 --nokbd;
gunzip -c “/images/TestLab/sys.img.000” |
/usr/local/sbin/udp-sender --min-receivers 2 --portbase 63140 --interface eth0 --max-wait 90 --half-duplex --ttl 32 --nokbd;
/usr/local/sbin/udp-sender --min-receivers 2 --portbase 63140 --interface eth0 --max-wait 90 --half-duplex --ttl 32 --nokbd[/CODE]
So, the server has fired up udp-sender on port 63140

Here’s the contents of /tftboot/pxelinux.cfg/[COLOR=#ff0000]MAC_ADDRESS[/COLOR] for [COLOR=#ff0000]TEST-HOST-1 [/COLOR](identical to [COLOR=#ff0000]TEST-HOST-2[/COLOR]):
[CODE]append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= type=down img=<TestLab>
mc=yes port=63140 storageip=<myFOGserver> storage=<myFOGserver>:/images/ mac=<foobar>
ftp=myFOGserver web=<myFOGserver>/fog/ osid=5 imgType=n shutdown= loglevel=4 consoleblank=0
reboot=bios fdrive= chkdsk=0 hostname=<TEST-HOST-1>[/CODE]
The clients are given the correct information to launch udp-receiver

Here’s /var/log/messages:
[CODE]rpc.mountd: authenticated mount request from <TEST-HOST-1>:816 for /images (/images)
udpcast: New connection from <TEST-HOST-1> (#0)
udpcast: first connection: min wait[0] secs - max wait[90] - min clients[2]
rpc.mountd: authenticated mount request from <TEST_HOST-2>:822 for /images (/images)
udpcast: New connection from <TEST_HOST-2> (#1)
udpcast: min receivers[2] reached: starting
udpcast: Starting transfer: file[] pipe[] port[63142] if[eth0] participants[2]
…unrelated entries…
udpcast: dropped client #0 because of timeout
udpcast: Disconnecting #0 (<TEST-HOST-1>)
udpcast: dropped client #1 because of timeout
udpcast: Disconnecting #1 (<TEST-HOST-2>)[/CODE]
Both clients connect, broadcast apparently starts and then times out.

Here’s /opt/fog/log/multicast.log.udpcast.1:
[CODE]Udp-sender 2007-12-28
Using mcast address 232.blah.blah.blah
UDP sender for (stdin) at <myFOGserver> on eth0
Broadcasting control to 224.0.0.1
New connection from <TEST-HOST-1> (#0) 00000009
New connection from <TEST-HOST-2> (#1) 00000009
Starting transfer: 00000009
Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
…repeats above line several times…
Dropping client #0 because of timeout
Disconnecting #0 (<TEST-HOST-1>)
Dropping client #1 because of timeout
Disconnecting #1 (<TEST-HOST-2>)

gzip: stdout: Broken pipe
Udp-sender 2007-12-28
Using mcast address 232.blah.blah.blah
UDP sender for (stdin) at <myFOGserver> on eth0
Broadcasting control to 224.0.0.1[/CODE]
Same thing here as in /var/log/messages.

Meanwhile both clients show “Please wait…” on their screens.
Does anyone have any ideas on how to fix this or to continue troubleshooting?

Seems to be a popular problem. This post suggest it’s a known bug to be fixed in FOG 0.33: [url]http://fogproject.org/forum/threads/scheduled-tasks-bug.58/[/url]

FWIW, you can delete it from the <b>scheduledTasks</b> table from MySQL.

This is by design according to [url]http://www.fogproject.org/wiki/index.php?title=Managing_FOG#Functions_and_Operation[/url]

“[SIZE=4][FONT=Times][COLOR=#000000][I]This module of the FOG Service will log a user off of a client pc after X minutes of inactivity. This module will display a screen saver-like GUI after 3/4 of the inactive time is up. So if the time out value is 40 minutes, the GUI will be displayed at 30 minutes of inactivity. [B]When the time is up, the client computer will reboot[/B].[/I][/COLOR][/FONT][/SIZE]”

The “Change NFS Location” link was what I used and it worked perfectly for me FWIW. I’d double check that you followed the directions completely, used the correct paths and set all the permissions correctly. It sounds like, at minimum, you’re really close.

I assume “media/98…AA08/images/fog/Win7.64.PRO” exist and FOG has permissions for the Win7.64.PRO folder?

[FONT=Tahoma][COLOR=#141414]I read somewhere around here that setting the OS for the image as [B]Windows Vista [/B]might allow you to save a single partition Windows 7 image as resizeable but, it didn’t work for me. There was also something about the reason behind multiple partition images not being resizeable (beyond the 100MB Windows 7 one) was simply that they couldn’t assume which partition(s) you would want to grow and hadn’t coded anything into the GUI to allow you to select that.

At any rate, the only was I was able to get a resizeable Windows 7 image was with the 100MB partition as well.[/COLOR][/FONT]

I would guess that the 100MB partition growing to 105MB might be related to the [FONT=Ubuntu][COLOR=#333333][B]FOG_UPLOADRESIZEPCT[/B] setting under[/COLOR][/FONT][B] Other Information > FOG Settings > General Settings. [/B]It’s default setting of 5% seems like it may be non-conicidental in this case.

That’s interesting because I could not get a single partition Windows 7 image successfully saved as resizeable. The [B]Windows Vista[/B]-thing didn’t work I also saw a line in [SIZE=4][B][FONT=monospace][COLOR=#003399]fog_0.32\src\buildroot\package\customize\fog\scripts\bin\fog[/COLOR][/FONT][/B][/SIZE] suggesting that FOG may be hard coded to expect that 100MB partition:

[COLOR=#000000][SIZE=3][FONT=Andale Mono]if [ “$osid” == “5” ][/FONT][/SIZE][/COLOR]
[COLOR=#000000][SIZE=3][FONT=Andale Mono]then[/FONT][/SIZE][/COLOR]
[COLOR=#000000][SIZE=3][FONT=Andale Mono]imgType=“mps”;[/FONT][/SIZE][/COLOR]
[COLOR=#000000][SIZE=3][FONT=Andale Mono]fi[/FONT][/SIZE][/COLOR]

I’ve got no real context for that code yet so, I may be be talking nonsense.

I finally took an image of a fresh install of Windows 7 with the 100MB partition and then copied my existing single-partition Windows 7 installation over the [SIZE=4][B][FONT=monospace][COLOR=#003399]sys.img.000[/COLOR][/FONT][/B][/SIZE] file. I then pushed the image back to the workstation and Repaired the installation from the Windows 7 disk and then saved it again.