Posts made by Mark Pickard

Dunno how helpful this will be but I captured the two different magic packets with WireShark from the H81M-A PC.

From Fog - doesn’t work:

From gWakeOnLan - does work:

That’s a good question. I went back and looked at it again just to double check. The default is to send the WOL to 255.255.255.255 which works (wakes up the machine). Just for the heck of it I tried the actual broadcast address of of my subnet - 10.25.37.255 (it’s a subnet with 510 hosts 10.25.36.0 - 10.25.37.254 with a subnet mask of 255.255.254.0) In gWakeOnLan both 255.255.255.255 and 10.25.37.255 wake up the machine.

Not Found
The requested URL /fog/status/wol.php was not found on this server.

As I mentioned in my original post:

wol.php in the browser (http://fogip/fog/wol/wol.php?wakeonlan=xx:xx:xx:xx:xx:xx) works for the DG41RQ PCs but not the H81M-A PCs.

WOL is enabled on my H81M-A PCs.

I can manually wake the H81M-A PCs from the Fog server using gWakeOnLan. (And it works on a Windows PC from another subnet using a script.)

No, not familiar with it.

Don’t think my problem is subnets since the Fog server and the client PCs are on the same subnet.

Fog SVN 3726 on Ubuntu 12.04

All PCs and Fog server are on the same subnet.

WOL from Fog works on my Intel DG41RQ PCs but doesn’t work with my Asus H81M-A PCs.

I can manually wake the H81M-A PCs from the Fog server using gWakeOnLan. (And it works on a Windows PC from another subnet using a script.)

wol.php in the browser (http://fogip/fog/wol/wol.php?wakeonlan=xx:xx:xx:xx:xx:xx) works for the DG41RQ PCs but not the H81M-A PCs.

Any ideas?

Believe I found a typo in HostManagementPage.class line 1206.

Was having trouble importing clients from CSV. Saw “PHP Fatal error: Call to undefined method HostManagementPage::nice_data()” in HostManagementPage.class line 1206. Apparently should be “nice_date()” instead of "nice_data(). Once I changed that the CSV import started working again.

[quote=“Tom Elliott, post: 44164, member: 7271”]If you’re running SVN, the kernel’s are now updated on the Sourceforge sites. All you’ll need to do is re-run the installer. The 3.19.1 kernel has been updated. Next up is to build the 3.19.2 drivers.[/quote]

Awesome! Flies right through it now. Thank you so much for your help.

[quote=“Tom Elliott, post: 44146, member: 7271”]I mean no harm with that, I just need to add the file to the compiler.

Hopefully doing that will fix the slow issue you’re seeing.[/quote]

That would be great! No harm in leaving the debugging on in the mean time is there?

[quote=“Mark Pickard, post: 44143, member: 609”]On the DG41RQ about 10 seconds in it hangs at the message “Switched to clocksource tsc” Right before that there are several lines about the mouse and keyboard. At 60 seconds I get:
[code]"r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rt18168d-1.fw (-12)
r8169 0000:03:00.0 eth0: link down
r8169 0000:03:00.0 eth0: link down[/code]
and then 3 second later:
[code]
r8169 0000:03:00.0 eth0: link up
Sending DHCP requests .
[/code]
and the it starts the imaging process.

I’ll try it on the H81M-A and report back.[/quote]

Same messages at the same time for the H81M-A.

[quote=“Uncle Frank, post: 44142, member: 28116”]Was just a dirty hack anyway. So I guess we are back to the inital question of why does the kernel sit and wait for so long?? Right now I can only think of turning on kernel debugging to see where it takes so long. Open /var/www/fog/lib/fog/BootMenu.class.php, jump to line 435:
[CODE]…
$kernelArgsArray = array(
“mac=$mac”,
“ftp=$ftp”,
“storage=$storage”,
“storageip=$storageip”,
“web=$this->web”,
“osid=$osid”,
“loglevel=4”,
“consoleblank=0”,
“irqpoll”,
…[/CODE]
Change ‘loglevel=7’ and add another line just after that called ‘debug’…
[CODE]…
“loglevel=7”,
“debug”,
…[/CODE]
Schedule a task for the client and see the kernel messages scrolling past. Probably best to take a video or picture so you can check later on.[/quote]

On the DG41RQ about 10 seconds in it hangs at the message “Switched to clocksource tsc” Right before that there are several lines about the mouse and keyboard. At 60 seconds I get:
[code]"r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rt18168d-1.fw (-12)
r8169 0000:03:00.0 eth0: link down
r8169 0000:03:00.0 eth0: link down[/code]
and then 3 second later:
[code]
r8169 0000:03:00.0 eth0: link up
Sending DHCP requests .
[/code]
and the it starts the imaging process.

I’ll try it on the H81M-A and report back.

My current production system is a clean install of 1.2.

I had been running 0.32 for the past couple of years. That one was still up on the network.

[quote=“Uncle Frank, post: 44138, member: 28116”]Kernels are placed in /var/www/fog/service/ipxe/ in FOG 1.2.0. Backup those, download the old FOG version and give it a try…
This is untested, think twice before following this blindly!
[CODE]cd /tmp
wget http://downloads.sourceforge.net/project/freeghost/FOG/fog_0.32/fog_0.32.tar.gz
tar xzf fog_0.32.tar.gz
find fog_0.32 -name “bzImage”
…<path-to-bzImage>…
cd /var/www/fog/service/ipxe
sudo mkdir kernel_backup
sudo mv bzImage* init*.xz kernel_backup
sudo cp /tmp/fog_0.32/<path-to-bzImage>/bzImage* .
sudo cp /tmp/fog_0.32/<path-to-bzImage>/init*.gz .
sudo chown www-data:www-data *[/CODE]

You might have to change /var/www/fog/lib/fog/BootMenu.class.php to match filenames… I am very interested to hear if you can get this to work. It might cause other trouble, so be warned![/quote]

Gave it a shot. Here’s what happened:

Grabbed the 0.32 bzImage and init.gz and put them in /var/www/fog/service/ipxe after backing up the originals. Changed the owner to fog and the group to www-data since that’s how the previous files were set. PXE booted the H81M-A system and it hung so I switched to the DG41RQ. That one rebooted with some kind of PXE error (too fast to see).

I went back and started looking at paths. In the FOG configuration settings I changed FOG_PXE_BOOT_IMAGE to init.gz. That worked to some extent. Got to the menu after the PXE boot but it still hung for about 60 seconds before getting there. Tried an imaging task which looked like it was going to work but when I turned my head the next thing i knew it was rebooting and I was left without an OS. Next I went to my old 0.32 server which is still up and grabbed bzImage and init.gz. This time it went right through without the 60 second pause but the imaging task still didn’t work.

Don’t know if it’s worth pursuing but that was interesting.

[quote=“Tom Elliott, post: 44128, member: 7271”]I guess I don’t know what you mean. It has nothing to do with pxelinux.0 or ipxe.[/quote]

I guess I don’t know what I’m talking about either.

On the old server (FOG 0.32) the DG41RQ systems didn’t experience the long wait that I see with FOG 1.2. You say the linux kernel is loading and has to detect the drivers. Is there a way to use the kernel from 0.32? Don’t know if that’s even a valid question since I don’t know enough about linux.

[quote=“Tom Elliott, post: 44120, member: 7271”]I highly doubt it’s the NIC causing the “slowdown”.

This behavior IS normal, but not in the sense you’re really thinking about it. You’re, seemingly, thinking it’s specific to a particular item, in actuality it’s specific to the entirety of the system.

The bzImage (linux kernel) is loading and has to detect the drivers it needs to load for the system it’s operating on. Sometimes things are faster than others. Considering I build my kernels to be as “generic” as possible, there may be some systems that take a while to load especially when compared to other systems. I don’t know why some systems boot faster than others with this, but it does seem to stem around different Motherboards and chipsets.

Hopefully this makes sense and gives some insight as to what the “issue” is, but it’s not something I know of how to fix neatly. You could build your own kernels to only have the drivers needed for your systems. In this method, you would likely see a massive improvement in loading times too, but it would mean you have to be cognizant of new systems coming under you management. Meaning you would need to stay on top of updating the drivers to maintain relevance for your environment.[/quote]

My old FOG server running 0.32 was pretty snappy using pxelinux.0 on the DG41RQ systems. Is there any way to use that on 1.2?

Fog 1.2 with TFTP files from SVN 3112
Ubuntu 12.04

Fog is working (creating/deploying images and snapins) but after PXE booting it seems to take longer than I would expect to get to the point where an imaging task starts. Once it gets to the screen with /bzImage… ok and /init.xz… ok the screen flashes black for a second and comes back. Then it sits there and waits for approximately 1 minute (it’s usually 64-65 seconds depending on when I start the stop watch). After that it goes on its way and does what it’s supposed to.

It also does this if I choose something from the PXE menu like host registration although then it goes past the /bzImage… ok and /init.xz… ok to a blank screen. But like clock work it continues after 65 seconds or so.

I’m using undionly.kkpxe because that gets me past iPXE initialising devices quicker.

Have tried it on two different models although they’re both RealTeks:

Intel DG41RQ - RealTek 8111B/8111C/8111D
Asus H81M-A - Realtek 8111G

Having just written that it gave me an idea. I pulled out my trusty Dell Latitude D820 and PXE booted to the menu and chose Client Information. It pulled it up in about 5 seconds. So I guess I answered my own question. No, it’s not normal.

Next question: how can I fix it on the RealTek NICs?

[quote=“Mark Pickard, post: 44113, member: 609”]I hate to try to break a working server but since it’s a vm I guess it’s not a big deal - just take a snapshot before I do it. So…for the greater good…I’m off to try to crash my server. :)[/quote]

Installed phpmyadmin and webmin on my working vm after taking a snapshot. Signed in to both to confirm that they’re working. In the FOG web interface I went to FOG Configuration | Active Directory Defaults (this is one of the areas that made it stop working before). I made some changes and then clicked the Save Changes button…and of course it works without any problem. Went down to the TFTP section (which was where it crashed the very first time) and made some changes. Hit the Save Changes button - no problem.

Couple of observations:
1.) This vm Ubuntu install (12.04) has current updates installed. My first two that crashed did not.
2.) Don’t know if the order of install makes any difference (phpmyadmin before webmin or vice versa).

Gotta love seemingly unrepeatable bugs.

[quote=“Uncle Frank, post: 44104, member: 28116”]Thanks for reporting back although I am not happy that at least two people had an issue with this but we are unable to find out why! I have phpmyadmin installed on all my FOG servers so I suspect it to not be the problem. And I’d really wonder if webmin plays a role in this either. But could you still install webmin just to make sure??[/quote]

I hate to try to break a working server but since it’s a vm I guess it’s not a big deal - just take a snapshot before I do it. So…for the greater good…I’m off to try to crash my server.

[quote=“Uncle Frank, post: 43753, member: 28116”]Make sure you always have phpmyadmin installed and you’ll be back in the game…

Can you reproduce this again?? Install phpmyadmin (if not installed already), make changes to your settings till you get locked off. Let yourself in again and try again… We need to reproduce the error to be able to fin a fix![/quote]

I’ve been using my new setup in the vm without any problems. Have made several changes to the settings without issue. So no, I haven’t been able to reproduce it. But, two things I did not install on the new vm were phpmyadmin and webmin - didn’t need them since I can easily access the server directly through VMware. Don’t know if one of them is maybe the culprit.

[quote=“Uncle Frank, post: 43740, member: 28116”]Alright, I think I found it! It’s one single setting in the ‘globalSettings’ table…

Go to phpmyadmin, select ‘fog’ database, then ‘globalSettings’, find the value with ID ‘106’ and name ‘FOG_INACTIVITY_TIMEOUT’. I guess it is set to ‘fog’ (at least it was in the dump). Change it to ‘1’ (one) and you should be able to login again…

The rest is up to Tom I am afraid as I don’t know the web interface enough to see where this could happen. You said that it happended twice when you changed settings… Maybe Tom has an idea!?

But I am still wondering why this is only happening to you?! So many people out there using it and I’ve never seen anyone reporting this. How come??[/quote]

That’s it! Bonus points for Uncle Frank!! Changed the FOG_INACTIVITY_TIMEOUT value to a 1 and got right in.

Yes, both times this has happened (on two separate installations) I was changing settings on the FOG configuration page at /fog/management/index.php?node=about&sub=settings. Once it was AD settings and the other it was TFTP settings. As soon as I hit the “Save Changes” button it booted me back to the sign in page and from that point I could never sign back in. Previous to that I had changed other settings without any problems. And on my latest install (in a VM) I’ve been changing settings without issue too.

Uncle Frank, thanks for the help and for sticking with me on this.

Tom, any idea why this happened and how do I make sure it doesn’t happen on my latest VM install?