Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @Jeremy Stop the dd approach - it’s what’s breaking the disk, not the Pi.

    Those .img files are not raw dumps. They’re zstd-compressed partclone streams;
    check any of them and you’ll see the zstd magic 28 b5 2f fd in the first four
    bytes. So dd’ing d1p1.img onto /dev/sda1 writes compressed bytes straight onto
    the partition, which is exactly why the firmware then can’t read it as FAT.
    That’s also why partclone.restore told you it wasn’t a partclone image - it was
    looking at the zstd wrapper. FOS does this at funcs.sh:847:

    zstdmt -dc /images/Raspberry/d1p1.img | partclone.restore --ignore_crc -O /dev/sda1 -N -f 1

    One per partition. If the image was captured with a gzip format instead, swap
    zstdmt for pigz -dc.

    The MBR is wrong too. d1.mbr isn’t one sector - we capture everything up to the
    first partition, capped at 1MiB, so it’s usually 2048 sectors. Your count=1
    threw away everything between the boot sector and the first partition. Drop the
    count entirely and let it write the whole file:

    dd if=/images/Raspberry/d1.mbr of=/dev/sda bs=512

    Now the more useful finding. “Fatal Error: Unknown request type :: Null” is
    FOS telling you $type arrived empty, and that’s the same problem as your
    missing osid - your bootargs are being truncated before FOS ever reads them. It
    isn’t the kernel: arm64’s COMMAND_LINE_SIZE is 2048, the same as x86, and the
    bootargs line you posted is 233 characters. Look at U-Boot’s own command and
    console buffer instead, that’s where the ceiling is on your setup.

    Which gets to the real limitation, and I’d rather be straight about it: FOG’s
    server has no U-Boot support at all. boot.php emits iPXE, and nothing generates
    a boot.scr, delivers a DTB, or builds arguments for a non-iPXE client. Every
    variable you’re hand-assembling is one the server would normally hand the
    client, and doing it by hand is why the ordering and length problems are yours
    to fight.

    Two ways forward. Keep hand-rolling U-Boot, in which case use the two commands
    above and keep bootargs minimal. Or put UEFI firmware on the Pi (pftf/RPi4) so
    it PXE-boots into iPXE like any other machine and the server drives the whole
    thing - that’s the route that already works today, and it’s where native
    support would build from.

    Capture works, which is the half that was broken. Deploy needs the server side
    to exist.

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

    @Tom-Elliott
    Something isn’t working well for me.
    I can’t get iPXE menu when secureboot is enable and secureboot/snponly-shimx64.efi is set.

    On a Lenovo ThinkPad E16 Gen 1, I only have this :
    9b9dee1d-92da-4baf-9afc-0e60d4f74b01-image.png

    I acces on iPXE menu a Lenovo ThinkBook 15-IIL but yet I think MOK.DER isn’t registering well even with an usb key connected formatted in fat32 with the 3 files.
    94105339-cff4-4e2f-a839-eb0977c8c936-vlcsnap-2026-08-26-09h50m19s364.png https://streamable.com/v6wyus

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

    @Valer I think we need to understand what this plugin is doing.

    CSS isn’t something we’ve allowed to be injectable though it could be.

    You can still use your own CSS but that’s more at the FOG Configuration -> FOG Setting -> FOG_THEME, but you would need to put it on your server in a location you type the path too here.

    https://docs.fogproject.org/en/latest/development/plugin-development

    This is a good toolkit for understanding how to build your own plugin.

81

Online

12.7k

Users

17.6k

Topics

157.0k

Posts