• I am having trouble with the HP Probook Imaging and also sometimes with PXE. It does the boot piece and loads the FOG menu, but after choosing the “Deploy Image” and putting the username and password, you have to hit enter 4 more times for it to exit that screen and then it goes into debug mode with “1. Reboot” being the top option.

    I imagine it is due to the hardware or the NIC. The NIC is the realtek, but I can’t find the exact model number. I am using the latest kernel (5.6.18) and have tried several others and it does the same thing. I can deploy an image from FOG and it will image at 10Mb/min which puts the image around 16 hours to download. There is definitely something wrong. I know I can probably use a USB-C to ethernet adapter, but I would rather use the onboard.

    Any help would be awesome.

  • I’ve been having the same issue with the G8 ProBooks and have finally got one to image throught the NIC however I’ve been through many steps so I followed this guide
    I then re-downloaded & re-installed FogProject from github.
    PXE is noticably faster and so far so good.
    Whether compiling and copying the ipxe worked or whether it was the re-install or a bit of both I cannot say.

  • @george1421 The USB drive piece didn’t work, but the Enabling of VMD did work to get the speed. The only gotcha is that you have to turn it off right after the image is done or you will get a BSOD with “Inaccessible Boot Device”.

    I updated the iPXE to the latest version and that fixed some of the initial issue with weirdness, but still, when I go to “Deploy Image” and put in the username and pw, I have to go through that and hit enter 6 times until it exits that menu. Then I get the following screen on the laptop

    2021-12-23 09-09-39.jpeg

    It looks like some sort of debug screen?

  • Moderator

    @chris-whiteley Look at Sebastian’s post from the other thread. See if the two “hacks” seem to mask the slowness issue. I have seen other posts in the forum regarding slowness with the G8 models. (This is from memory, so take it as that), in the firmware there is something about vtm or vtmd, or something like that. If you disabled it imaging started to work better.

    That still doesn’t solve the ipxe entering password and having to hit enter several times to end up at some reboot screen. I think that is a different matter. But the password and until bzImage is launched is under the control of iPXE so it probably wouldn’t hurt updating iPXE either. I have a tutorial on that. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

  • @george1421 On the post you put, I just tried to image with the VMD enabled and that worked. The biggest thing is that I had to disable it after the image came down.

  • @george1421 I did end up XX-ing out the IP address. I guess I really didn’t need to and it was on the correct subnet.

    I checked the /var/log directory and all it had was a “messages”, not a “syslog”, so I have put that below.

    #grep -i firmware /var/log/messages
    Dec 23 08:20:58 fogclient user.notice kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

    The NIC that is being booted from the is the internal NIC

  • Moderator

    @chris-whiteley Ok this moves us a bit forward in debugging. I see you have 2 intel nics built into this system. One is a wifi adapter and the other is an I219-V based nic. That nic has been in the linux kernel since 5.5 so that should have been supported with the older kernel you had.

    did you X out the actual IP address with the ip a s command? Its OK if you did, I just need to know if it returned a valid IP address for your subnet.

    grep -i firmware /var/syslog well I totally messed up that one. I forgot the log directory. its grep -i firmware /var/log/syslog But if it picked up an ip address I don’t think the issue is firmware driver for the nic, but lets check.

    The last question is where did realtek come from. Is that a usb based nic you are using?

    Quick google-fu on the forum found this. Its not the same model, but is same generation: https://forums.fogproject.org/post/144640

  • @george1421 Thanks george for the help!

    Here is what got returned:

    #lspci -nn | grep -i net
    00:14.3 Network controller [0280]: Intel Corporation Device [8086:a0f0] (rev 20)
    00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:15fc] (rev 20)

    The other command didn’t work, either with /var/syslog or /var/messages. When I did a “ls” for that /var/ directory it came up with: cache, empty, lib, lock, log, run, spool, tmp, www. I tried doing “log”, but it returned nothing.

    Here is the output for ip a s

    2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
        link/ether e0:70:ea:a6:29:b1 brd ff:ff:ff:ff:ff:ff
        inet X.X.X.X/21 brd X.X.215.255 scope global enp0s31f6
        valid_lft forever preferred_lft forever

    Thanks again

  • Moderator

    @chris-whiteley Ok so you’ve tried 5.10.x series. What we would like you to do is this:

    1. If you have not done so, [manually] register this computer with FOG.
    2. Schedule a debug capture/deploy with this computer.
    3. At the fos linux command prompt key in
      lspci -nn | grep -i net
      grep -i firmware /var/syslog (I think its syslog, could be messages I don’t remember off the top of my head)
      ip a s (to confirm the nic has an IP address)
    4. Post the results here so we can see what the hardware nic is doing.

  • @sebastian-roth Thanks for the response. I tried all of the 5.10.x kernels as well. I exhausted the list. I couldn’t remember off the top of my head what the very latest was.

    I will try to update to the latest version of ipxe and see if that fixes the first part of the booting process.

    I will still need help with the imaging portion though. Is there any sort of debugging/checking I can do as far as the slow imaging?

  • Moderator

    @chris-whiteley Be aware that what you describe in one post are most probably different things. The FOG boot menu is handled by iPXE. You can update that to the very latest version using the following instructions: https://docs.fogproject.org/en/latest/reference/compile_ipxe_binaries.html

    Now the slow deployment is definitely not caused by the same component (iPXE) but by the Linux kernel or (less probably) the FOS init used.

    I am using the latest kernel (5.6.18)

    This is surely not the latest kernel. We moved on to the 5.10.x series some months ago. Either use the FOG web UI kernel updater or manually download here: https://github.com/FOGProject/fos/releases/