Is this normal?
-
Fog 1.2 with TFTP files from SVN 3112
Ubuntu 12.04Fog 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 8111GHaving 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?
-
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=“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?
-
I guess I don’t know what you mean. It has nothing to do with pxelinux.0 or ipxe.
-
[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.
-
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=“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.
-
Are you running 1.2.0 or 0.32?
-
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.
-
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=“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.
-
[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.
-
YAY!
Information. It is somewhat related to the nic, but not in the lack of ability, but rather a missing firmware.
-
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=“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?
-
Probably not… might make you dizzy seeing all that code fly by though… and throwing up on a computer wouldn’t be good.
-
[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]
Sure but how many firmware files do we add to the initrd? Most are for WLAN adapters which we don’t use with FOG (so far). But there are also a couple for normal ethernet adapters… -
It’s not in the init. I build them directly in the kernel.
-
[quote=“Tom Elliott, post: 44160, member: 7271”]It’s not in the init. I build them directly in the kernel.[/quote]
Not much difference. Makes the kernel bigger and bigger. But probably better then having a lot of people waiting for a minute for no reason… -
[quote=“Uncle Frank, post: 44161, member: 28116”]Not much difference. Makes the kernel bigger and bigger. But probably better then having a lot of people waiting for a minute for no reason… ;)[/quote]
Personally, I want a kernel that will work with EVERYTHING.
UEFI & BIOS mixed environments scares the crap out of me, honestly.
