Categories

  • 12k Topics
    114k Posts
    J

    Hello,

    We have a Windows 11 image that we are deploying to Geekom A6 Mini PCs
    I captured and deployed the image successfully from the first FOG server onto three of these Geekoms at this site.

    I’m following this wiki post > https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually#Image_Definitions
    We have a second FOG server running at a different site, I used NFS to copy the folder of this image over to the /images directory on the second FOG server. Then, I exported the image definitions to a CSV from the FOG GUI and imported that into the second FOG server.
    I confirmed that the owner/group permissions of the directory match the permissions on the original FOG server.

    The image appeared in the FOG GUI of the second server, and I was able to run a Deploy task.
    The deploy completes, but when the machine restarts, Windows fails to boot, “Your device ran into a problem and couldn’t be repaired.”

    I’ve tried deploying it three times, to the same PC over at this second site.

    Is there anything I’m missing?

    FOG Server 1 - Version 1.5.5, bzImage/bzImage32 version 6.12.35
    FOG Server 2 - Version 1.5.9, bzImage/bzImage32 version 6.12.35

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    K

    @toalalife Hi there! Sorry for the late reply. I’ve been on holiday and I forgot to check up on this. That is interesting. There are a couple of things I can think of to double check/try off the top of my head.

    That particular error happens when iPXE can’t execute the binary, usually because either an architecture mismatch (e.g arm64 on x64) or because secboot fails to verify. Given that disabling secboot fixes it, I’m leaning towards that. (https://ipxe.org/err/2e0080)

    So I would say you should double check that your kernel is signed. If you’ve updated them you’ll have to resign the kernel to ensure it keeps working.

    The other would be to double check that the shim command is being invoked at some point prior to boot.php being chained. There’s a none zero chance that if you’ve updated FOG, it may have overwritten the modified default.ipxe

    Other than that, if you could try and record the boot process I’d be happy to take a look and see if I can spot anything out of the ordinary, I’m also happy to take a look at your kernel or any ipxe scripts etc if you want me to double check if they’re signed or bootable.

    As a final note, I don’t think I see iPXE loading the initrd.xz file there, which contains the ram filesystem that FOG uses on boot. I could be misremembering the boot process (I can’t recall if it’s normal for it to not do that if the bzImage fails to verify, or if it loads it prior to bzImage), but if that’s failing to load it might also be worth checking that out, though it shouldn’t have to be signed!

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    M

    Okay - So what killled this installation was the fact a 1.5.9 csv load was imported into my 1.5.10.1698 FOG - this killed a bunch of features and I eded up having to reinstall.

124

Online

12.6k

Users

17.5k

Topics

156.4k

Posts