-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Answer 1: No, MerlinAU itself does not perform backups. However, it does save the firmware update file on the USB before flashing. We recommend using BACKUPMON for comprehensive backup solutions. Found on Github here and SNBForums here.
MerlinAU integrates with BACKUPMON to ensure data is backed up before any firmware update. Ensure BACKUPMON is installed for backups.
Question 2: Does it upgrade to the same firmware version I have on ROG models, or does it default to the non-ROG version?
Answer 2: MerlinAU now defaults to the Pure (non-ROG/TUF) UI for all ROG or TUF models.
For both ROG and TUF models, the firmware always starts with the "Pure" version, but the option to select between TUF, ROG, or Pure builds is always available in the Advanced Options menu for all TUF and ROG models regardless of actual firmware availability. During the first interactive flash attempt, you will be prompted to choose which firmware build you’d like to use. If you don’t make a selection during this interactive process—or if the flash attempt is non-interactive—the system defaults to the Pure firmware. Additionally, if you select a TUF or ROG UI and that specific version is unavailable, the system will revert to using the default Pure UI.
Answer 3: Yes, MerlinAU includes a built-in self-update function.
Answer 4: Email notifications can be configured via the "em" option called "email settings" in AMTM. MerlinAU will send Email notifications when a new firmware update version is available, at the start and completion of flashing, if the firmware does not match the SHA256 file signature, and when high-risk phrases are found in change logs.
Answer 5: MerlinAU manages manual reboots, including a 3-minute wait for the firmware upload and flash auto-reboot, and initiates a reboot if the router hasn't restarted within the last 3 minutes.
Answer 6: Yes, RMerlin has reviewed the project and approved the use of the curl method. Found here
Answer 7: MerlinAU treats Alpha/Beta releases as lower priority, updating to official releases when available, but allows manual control over this feature.
Answer 8: Yes, each node requires the MerlinAU installed individually for updates.
Answer 9: MerlinAU includes an 'Update Check Schedule' via a cron job and Postponement days options, allowing users to avoid updates during inconvenient times. Additionally, users can fine-tune the update check schedule using the cron job setting found in the "Advanced Options" Menu, providing further flexibility in managing firmware updates. Please reference crontab.guru for cron examples.
Please also reference question 22 in this FAQ for cron schedule limitations.
Question 10: What failsafes are in place for automated updates, especially concerning router crashes?
Answer 10: MerlinAU uses the same update process as manual updates, however, it includes memory management, checksum verification, and log file verification. It recommends using BACKUPMON for backups before flashing firmware updates.
Answer 11: MerlinAU implements passive changelog verification to identify potential issues and gives users the option to pause firmware flashes for a thorough review. This changelog verification allows the script to cancel when run as a cron as it identifies the following high-risk phrases:
- features are disabled
- factory default reset
- break backward compatibility
- must be manually
- strongly recommended
The script will pause until run interactively and the flash is approved. Otherwise the changelog feature can be disabled under advanced options. Users are reminded to review change logs independently and thoroughly. The changelog verification can also be pre-approved before the expected runtime. More information below in Question 12.
Answer 12: The new pre-approval feature notifies you immediately when an update with high-risk phrases is detected. You’ll receive an email if email notifications are enabled, and a menu option will appear in MerlinAU to approve or block the update as a visual indicator the script will be blocked until approved. By default, updates with high-risk phrases are always blocked. You can approve the update to let it proceed as a cron job or handle it manually when running interactively. This allows you to manage the changelog check safely and efficiently before the update is scheduled.
Answer 13: Yes, it’s now possible to automatically update the MerlinAU script using the “au” option from the Advanced Options menu. When enabled, MerlinAU will check for new releases daily and automatically download and apply updates without user intervention. The CRON job for script updates is scheduled to run 15 minutes before the firmware update check CRON, ensuring you receive the latest improvements as soon as possible.
Answer 14: MerlinAU verifies the firmware file's integrity before updating and halts the process if discrepancies are found, notifying the user. If the firmware file's checksum doesn't match, MerlinAU halts the update process and sends an email notification.
Answer 15: Yes, it stops all Entware services and removes any third party cron jobs before safely ejecting the USB drive and proceeding with the firmware flash.
Answer 16: In the event of a worst-case scenario where your router is not functioning as expected and standard troubleshooting steps have not resolved the issue, the first step is to perform a Factory Defaults Reset.
This can be done by using the reset or WPS button on the router, instead of through the graphical user interface (GUI). If a factory reset does not resolve the problem, the next step is to use the ASUS Rescue Tool for a recovery operation on the router. https://www.asus.com/ca-en/support/faq/1000814/
This process is designed to restore your router to a functional state by reinstalling the firmware, ensuring that your device can return to normal operation.
Answer 17: No, MerlinAU addon is designed with a focus on safety and stability, ensuring that only stable firmware versions that have completed beta testing are automatically flashed onto your router.
This design choice prevents the automatic update to beta firmware, ensuring that your router maintains a stable and secure operation. Users seeking to experiment with beta firmware must manually download and install these versions.
Answer 18: The MerlinAU script is not compatible with most AC class routers and will not attempt to update due to safety concerns associated with single partition systems. Furthermore, most AC class routers are on End-of-Life support and not expected to receive further updates.
Discussion found here
Question 19: What happens if a second newer firmware is released during the postponement period? Does the postponement restart?
Answer 19: Yes, if a newer firmware version is released during the postponement period, MerlinAU restarts the postponement period. The script automatically sends an update notification with the latest version details and date, ensuring that the newest firmware is always prioritized for download, and postponement is re-applied accordingly if a newer update is detected within the original postpone window.
Answer 20: Yes, you have the option to bypass a particular update or temporarily halt all update checks on MerlinAU by selecting option 3 from the Main Menu. This action deactivates the update check feature until re-enabled, preventing any attempts to apply updates. Should you later decide that you wish to install a more recent firmware version, simply reactivate the update checks in MerlinAU, and it will prioritize downloading the latest firmware available at that time.
Answer 21: Yes, for installations without a USB, the zip files are immediately cleaned up post-extraction from the zip file. However, for USB installations, the zip files are not instantly removed but are instead overwritten on each run on the USB. The firmware file is unzipped locally into the home folder for flashing, regardless of the method. The firmware file itself is deleted from the home directory in the reboot post-flash.
Question 22: Why is my scheduled cron job not triggering at the expected times? Are there limitations to the cron job schedules?
Answer 22: Yes, there are specific limitations to how cron jobs can be scheduled, especially concerning firmware (F/W) updates.
Minimum Interval:
We require that cron jobs are never set to execute more frequently than every 15 minutes (e.g., */15 * * * *). This is due to the MerlinAU lock file, which ensures that updates occur without interruption by releasing the lock only after 10 minutes have passed.
Minute Parameter Restrictions:
The updated system enforces that the minute field in cron schedules must be set to exact numbers rather than intervals. This means you cannot use step values like */10 or 0/10 for minutes. For example:
Valid Schedules:
- 0,15,30,45 * * * * (Runs at every quarter hour)
- 15 * * * * (Runs at the 15th minute of every hour)
Invalid Schedules:
- */10 * * * * (Every 10 minutes)
- 0/10 * * * * (Every 10 minutes starting at minute 0)
This restriction prevents novice users from setting up cron schedules that, while syntactically correct on some systems, are not suitable for F/W updates. For instance, scheduling a job to run every 30 minutes (*/30 * * * *) is not permitted.
Alternative Scheduling Method:
Instead of using interval-based scheduling, set the cron job to run at specific times. For example, if you want a task to run 15 minutes into the future, you can set the cron schedule with the HOUR and MINUTE parameters accordingly. Suppose the current time is 10:50 PM; you can schedule the cron job to run at 11:05 PM by setting:
- 5 23 * * *
Recommendation: Always ensure your cron job schedules adhere to these constraints to avoid issues with triggering. We highly recommend reviewing your cron job schedule settings with crontab.guru to ensure they are correctly configured for the router's embedded cron daemon.
For more detailed examples and discussions, refer to this forum thread.
Answer 23: No, at this time MerlinAU does not flash the mesh nodes from the primary router.
It does however check any AiMesh nodes for updates available and sends an email summary for any updates found for the nodes. You still need MerlinAU for each node you wish to auto-update. The "AiMesh Nodes" menu will be disabled on anything but the primary router.
Answer 24: Yes, Gnuton is supported as of version 1.3.0 of MerlinAU and version 388.8_2 and above with Gnuton firmware. You will need to manually update to 388.8_2 for MerlinAU to function correctly.
Answer 25: Yes, however keep in mind that MerlinAU may quit pre-maturely if the SSH connection is terminated before the flash is started. The recommended method would be to set the cron job schedule to when you want the flash to run and logout of SSH. This allows the script to run in non-interactive mode.
To help with this situation, as of version 1.2.7 an 'Advanced Options' toggle was included to keep Tailscale/ZeroTier VPN connections ALIVE while flashing as long as possible. Keep in mind this option is DISABLED by default, only enable it if you require Tailscale/ZeroTier VPN services to remain active while flashing. When enabled, MerlinAU will skip shutting down those specific services to keep a remote interactive SSH session open until the flash has started.
Question 26: How do I manage configuration changes when using the new WebUI alongside the shell script CLI menu in MerlinAU v1.4.0?
Answer 26: In version 1.4.0, the new WebUI page offers most of the shell script’s features — but not all. If you find a feature missing in the WebUI, please refer to the shell script CLI menu. It’s important to note that the WebUI and the script CLI menu should not be used concurrently to make configuration changes because they are not designed to dynamically synchronize configuration changes in real-time.
If you do have both user interfaces open and make changes in the WebUI, the best way to update the CLI menus is by using the new key combination:
<Ctrl-R> + <Ctrl-L> + <Enter>
This “reload & refresh” sequence ensures that the concurrently running script CLI menus accurately reflect any configuration changes made from the WebGUI. Any discrepancies between the two interfaces while running simultaneously should be resolved using the above key sequence rather than expecting automatic synchronization to occur. And, of course, if you exit and relaunch the shell script the configuration changes will be reflected automatically.