SOLVED Kernel update behind proxy & Problems with fixparts

  • Hi there,

    since I am experiencing problems capturing a system with fog 1.5.4 (see screenshot), I read here ( to do a kernel update for fog, which could solve this problem.


    Now I went to the page in the GUI, where kernel-updates can be done, but there are no kernels offered (having waited for long time).


    I guess, this is maybe because the fog server is behind a proxy-server.
    How can I tell fog to use the proxy?

  • @Sebastian-Roth & @george1421
    Thank you for your help. Updated the kernel and inits the way you described it. Now the capture works.
    Installed 1.5.4 on august 9th, as far as I can see.

  • Senior Developer

    @Tywyn Did you install FOG 1.5.4 about two month ago? There was an issue with fixparts back then [ref].

    I’d advise you to manually update kernel and inits.

    cd /var/www/html/fog/service/ipxe
    mkdir backup
    mv bzImage* init* backup/
    chown apache:apache bzImage* init*

    The last command might be different depending on the Linux OS you have. This should be correct for Ubuntu/Debian. Try chown httpd:httpd bzImage* init* if you are on CentOS/Fedora.

  • @Sebastian-Roth

    Back from vacation. Sorry for my late reply.

    Tried it again. It seems, that fixparts is not in /usr/sbin.
    So, is the kernel-update the thing I have to do? If yes:
    I am not a experienced user of fog, so: Can I break something?

    Is Kernel - 4.18.3 TomElliot 64 the one to choose?

    So I have to download it and where exactly do I have to put it?

    One more question for my understanding: I captured other PCs without problems. If the fixparts is missing in the image, why was I able to capture the other PC-models? Or is fixparts only needed in debug mode?

    Thanx for your help!

  • Senior Developer

    @Tywyn Could you try debug mode again. You should have fixparts there: /usr/sbin/fixparts /dev/sda

    We actually had an issue with a missing fixparts binary two months ago but that should only be the case if you installed FOG 1.5.4 around that time.

  • Could some admin please change the subject of this thread to “Kernel update behind proxy & Problems with fixparts” ? Thank you 🙂

  • @george1421
    Well, in total we have 3 different models of computers with Windows 10, Fujitsu, HP and Bluechip.
    Bluechip and Fujitsu can be captured meanwhile without problems.

    Reinstalled the HP with the default partition layout that comes with windows 10. There are 2 partitions. One with 549MB, system reserved, the other one is for C:.
    EFI is disabled.

    During boot I see this error-message. Dunno whether it is relevant:

    [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)

    Capture still fails with (sorry for the bad quality):

    Your suggested debug steps are still not working, since fixparts is obviously not in the image.

  • Moderator

    @Tywyn said in Kernel update behind proxy:

    I did try a debug capture, but the fixparts command

    Interesting since fixparts should be in the FOS image. Either way we’ll wait until you update this thread.

  • Will reinstall the OS on the host now and see, whether I can capture then … Results will be posted here on monday

  • @george1421
    Ok … as you say, there may be something screwed up with the partitions: I usually installed Windows 7 on one partition, because I thought, this would be needed for the resizability when capturing images with fog.

    As far as I can see, Windows 10 comes along with 3-4 partitions and the way to reduce it to one partition like I did on win 7 does not work here. I reduced it to 2 Partition. I assume that this may cause the trouble, or?

    I did try a debug capture, but the fixparts command is not in the dirs mentioned in the PATH-env variable. In which directory should it be?

  • Moderator

    @Tywyn said in Kernel update behind proxy:

    Actually I wanted to capture. Is the debuy capture procedure the same as you described it for the debug deploy task?

    For this part you could do a capture or deploy. The key is to get to the linux command prompt. Run the command and then delete the task on the FOG UI, then schedule your new capture task. It is a bit concerning if you have this error on capture. We’ve seen this when the disk was gpt to start with then reformatted as mbr. And typically when you go to deploy an image mbr type there are bits of gpt information left behind which causes this error. In your case you are capturing the image… this may be something new.

    Now I can tell you that you upgraded to the latest kernel, you will probably want to downgrade to 4.15.2 if you experience 3-4 minute delay when deploying your image when creating the disk partitions.

  • @george1421 Thank you.
    Found the proxy setting - works.

    You were writing about a debug deploy.
    Actually I wanted to capture. Is the debuy capture procedure the same as you described it for the debug deploy task?

  • Moderator

    I feel you have two issues here.

    1. There is something wrong with the disk structure that is causing fixparts to fail.
    2. For kernel updates and such behind a proxy. There is a fog setting that allows you to configure a proxy setting. Go to the FOG Configuration Settings. press the expand all and then search for proxy.

    For the fixparts issue. Go back and schedule a deploy again but select the option for debug deploy. PXE boot the target computer again. After several enter key presses you will be dropped to a linux command prompt. Now key in fixparts /dev/sda This may not fix the parts, but it will allow you to see the output of the command for more detailed info.