Is this normal?
-
[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.
-
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=“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.
