Snapmaker U1 stock firmware restores printer.cfg on reboot, removing ace.cfg include and breaking multiACE startup

[kayohenriquemd]

Describe the bug

On Snapmaker U1 stock firmware, multiACE installs successfully and works correctly until the printer performs a full reboot or power cycle.

After reboot, Snapmaker restores printer.cfg from its stock configuration and removes:

[include extended/ace.cfg]

The multiACE Python files remain installed, but ace.cfg is no longer included. Klipper then fails to start normally because the ace configuration object is missing.

I reproduced this behavior on:

• Snapmaker stock firmware 1.6.0
• Snapmaker stock firmware 2.0.0.205_20260914173503

I traced the issue to the Snapmaker boot script:

/etc/init.d/S48setup-lava-env

Its prepare_printer_data() function restores changed configuration files from:

/home/lava/origin_printer_data/config/

unless either of these files exists:

/oem/printer_data/.fluidd
/oem/.factory

Creating:

touch /oem/printer_data/.fluidd

prevents Snapmaker from restoring printer.cfg during boot.

After creating .fluidd, adding the multiACE include back once, and rebooting, the include persisted, Klipper started Idle, and multiACE loaded normally.

---

To Reproduce

1. Start with a Snapmaker U1 running stock firmware.
2. Enable Root Access / SSH.
3. Create:

touch /oem/.debug

4. Install multiACE normally:

bash /tmp/multiace/install_multiace.sh
bash /tmp/multiace/install_multiace.sh --install-web

5. Confirm the installer added:

[include extended/ace.cfg]

6. Confirm ace.cfg exists:

ls -la /home/lava/printer_data/config/extended/ace.cfg

7. Reboot the printer.

8. After reboot, run:

grep -nF '[include extended/ace.cfg]' /home/lava/printer_data/config/printer.cfg

9. The command returns no result, even though both of these still exist:

/home/lava/printer_data/config/extended/ace.cfg
/oem/.debug

10. Klipper fails to start normally because the multiACE-modified Python files are active, but the [ace] configuration is no longer being loaded.

Manually adding the include again:

sed -i '1i [include extended/ace.cfg]\n' /home/lava/printer_data/config/printer.cfg

followed by:

FIRMWARE_RESTART

restores normal operation.

The issue is reproducible after a full reboot or power cycle.

---

Expected behavior

After multiACE is installed successfully, a normal reboot or power loss should not remove:

[include extended/ace.cfg]

multiACE should remain functional after reboot without requiring the user to manually edit printer.cfg and perform a FIRMWARE_RESTART.

Ideally, the installer could detect Snapmaker's config-sync behavior and either:

• create /oem/printer_data/.fluidd when appropriate, or
• document that .fluidd is required for configuration persistence.

If the installer creates .fluidd, it may be useful to track that it created the file so the uninstaller does not blindly remove a .fluidd that already existed for another reason.

---

Screenshots

I can provide screenshots of the Klipper startup error if helpful.

The relevant behavior is:

Before reboot

[include extended/ace.cfg]

is present.

After reboot

grep -nF '[include extended/ace.cfg]' /home/lava/printer_data/config/printer.cfg

returns no result.

After applying the workaround

touch /oem/printer_data/.fluidd

the include survives reboot and Klipper starts normally.

---

Desktop

• OS: macOS
• Terminal / SSH: used for installation and troubleshooting
• Browser: Chrome
• multiACE Web UI: accessed through the printer's local IP

---

Smartphone

Not applicable.

---

Additional context

Printer

Snapmaker U1

Snapmaker firmware

2.0.0.205_20260914173503

The same persistence issue was also observed previously on firmware:

1.6.0

multiACE

v1.00.1b "Resupply Run"
build=f026fc15
bundle status: MATCH

ACE

Anycubic ACE Pro V1
firmware V1.3.863

After applying the workaround and rebooting:

[multiACE] v1.00.1b "Resupply Run" build=f026fc15
[multiACE] bundle: expected=573fa61 actual=573fa61 [MATCH]
[multiACE] Active ACE: 1 of 1
ACE 1 [v1] - Anycubic Color Engine Pro fw V1.3.863 << ACTIVE

Klipper starts Idle automatically and multiACE works normally.

---

Root cause

The relevant Snapmaker boot script is:

/etc/init.d/S48setup-lava-env

Its prepare_printer_data() function contains logic equivalent to:

if [ -f "/oem/printer_data/.fluidd" ] || [ -f "/oem/.factory" ]; then
    log "printer configuration is writable, skip config sync"
else
    ...
    if ! cmp -s "$file" "$oem_file"; then
        log "restore changed config file $filename"
        cp -f "$file" "$oem_file"
    fi
fi

Without either:

/oem/printer_data/.fluidd

or:

/oem/.factory

Snapmaker compares the stock configuration with:

/oem/printer_data/config/

and restores changed files during boot, including printer.cfg.

That removes the multiACE include.

---

Workaround tested successfully

Create:

touch /oem/printer_data/.fluidd

Then restore the include once:

[include extended/ace.cfg]

After this, the include persists across a full reboot and the printer starts normally.

I confirmed after reboot that:

grep -nF '[include extended/ace.cfg]' /home/lava/printer_data/config/printer.cfg

still returns the include, Klipper starts Idle, and multiACE reconnects successfully.

---

Thanks for developing multiACE.

I am running an ACE Pro V1 on the Snapmaker U1 in Head Mode, and after getting the setup stable I successfully completed a print with approximately 130 swaps between three ACE filaments.

I wanted to report this because fixing or documenting the reboot persistence behavior could make the stock-firmware installation much more robust.

[decay71]

Hi, thanks for the report..must be a stock regression again, i test it on paxx most of the time.

I'll look into this and release a patch!