Is this normal?



  • 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?



  • @Tom Elliott, post: 44164, member: 7271 said:

    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.

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


  • Senior Developer

    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.


  • Moderator

    @Uncle Frank, post: 44161, member: 28116 said:

    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… ;)

    Personally, I want a kernel that will work with EVERYTHING.

    UEFI & BIOS mixed environments scares the crap out of me, honestly.


  • Developer

    @Tom Elliott, post: 44160, member: 7271 said:

    It’s not in the init. I build them directly in the kernel.
    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… ;)


  • Senior Developer

    It’s not in the init. I build them directly in the kernel.


  • Developer

    @Tom Elliott, post: 44146, member: 7271 said:

    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.
    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…


  • Moderator

    Probably not… might make you dizzy seeing all that code fly by though… and throwing up on a computer wouldn’t be good.
    ;-)



  • @Tom Elliott, post: 44146, member: 7271 said:

    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.

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


  • Senior Developer

    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.


  • Senior Developer

    YAY!

    Information. It is somewhat related to the nic, but not in the lack of ability, but rather a missing firmware.



  • @Mark Pickard, post: 44143, member: 609 said:

    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:

    >"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
    >```
    and then 3 second later:
    

    r8169 0000:03:00.0 eth0: link up
    Sending DHCP requests .

    and the it starts the imaging process.

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

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



  • @Uncle Frank, post: 44142, member: 28116 said:

    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:

    >...
                            $kernelArgsArray = array(
                                    "mac=$mac",
                                    "ftp=$ftp",
                                    "storage=$storage",
                                    "storageip=$storageip",
                                    "web=$this->web",
                                    "osid=$osid",
                                    "loglevel=4",
                                    "consoleblank=0",
                                    "irqpoll",
    ...
    >```
    Change 'loglevel=7' and add another line just after that called 'debug'...
    


    “loglevel=7”,
    “debug”,

    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.

    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:

    "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
    

    and then 3 second later:

    
    r8169  0000:03:00.0 eth0:  link up
    Sending DHCP requests .
    
    

    and the it starts the imaging process.

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


  • Developer

    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:

    ...
                            $kernelArgsArray = array(
                                    "mac=$mac",
                                    "ftp=$ftp",
                                    "storage=$storage",
                                    "storageip=$storageip",
                                    "web=$this->web",
                                    "osid=$osid",
                                    "loglevel=4",
                                    "consoleblank=0",
                                    "irqpoll",
    ...
    

    Change ‘loglevel=7’ and add another line just after that called ‘debug’…

    ...
                                    "loglevel=7",
                                    "debug",
    ...
    

    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.



  • 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.


  • Senior Developer

    Are you running 1.2.0 or 0.32?



  • @Uncle Frank, post: 44138, member: 28116 said:

    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!

    >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 *
    >```
     
    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!
     
     
     
    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.

  • Developer

    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!

    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 *
    

    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!



  • @Tom Elliott, post: 44128, member: 7271 said:

    I guess I don’t know what you mean. It has nothing to do with pxelinux.0 or ipxe.

    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.


  • Senior Developer

    I guess I don’t know what you mean. It has nothing to do with pxelinux.0 or ipxe.


Log in to reply
 

457
Online

38717
Users

10545
Topics

99838
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.