Fix setup on OS 3.27+ (hashtab) and 3.28+ (AppLoad hooks)#3
Conversation
On Paper Pro OS 3.27+, AppLoad hard-crashes xochitl when the Qt resource hashtab is missing. remagic setup treated the rebuild as best-effort and often skipped it (upstream rebuild_hashtable is interactive; timeout(1) is not available on device). On OS 3.28+, upstream AppLoad v0.5.3 hooks no longer match the UI tree, causing a separate panic even when the hashtab is present. - Add a non-interactive hashtab rebuild (setup, shell installer, rebuild-hashtab) - Skip starting xovi when the rebuild fails (avoids silent crash-reboot loops) - Extend doctor to report hashtab presence and whether xovi is loaded - Bundle a 3.28-compatible appload.so (from rm-appload PR #59) for OS 3.28+ Fixes MaximeRivest#2 Co-authored-by: Cursor <cursoragent@cursor.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a99f90ec2b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| echo "Hashtab rebuild failed." >&2 | ||
| echo "--- last log lines ---" >&2 | ||
| tail -30 "$log" 2>/dev/null >&2 || true | ||
| exit 1 |
There was a problem hiding this comment.
If the rebuild times out or xochitl exits before writing the hashtab, this failure path returns after the script has already run systemctl stop xochitl and killed any remaining process, and cmdSetup then skips /home/root/xovi/start when hashtabOK is false. That leaves the tablet with no running xochitl/UI until the user reboots or manually starts it; the duplicated scripts/rebuild-hashtab.sh has the same failure path. Please start stock xochitl (or otherwise restore the prior UI state) before exiting with failure.
Useful? React with 👍 / 👎.
1 participant
Summary
Paper Pro users on recent reMarkable OS versions hit two separate failures during
remagic setupthat both look like “AppLoad never appears” but have different root causes:OS 3.27+ — missing Qt hashtab. AppLoad depends on
qt-resource-rebuilder, which needs a per-OS-version hashtab file. Without it, xochitl crash-loops and the device reboots, wiping xovi’s volatile systemd overrides. Setup used to print “AppLoad works without it” and continue — that message is wrong on 3.27+.OS 3.28+ — stale AppLoad UI hooks. Even with a valid hashtab, upstream AppLoad v0.5.3 panics because its QML hook targets moved in 3.28 (
Couldn't resolve the hashed identifier … required by AppLoad hooks in main UI). Rebuilding the hashtab alone cannot fix this; a newerappload.sois required (asivery/rm-appload#59).This PR fixes both paths in remagic.
Changes
Qt hashtab (3.27+)
timeout … rebuild_hashtable </dev/nullstep with a non-interactive rebuild that backgrounds xochitl, polls a log file, and verifies the hashtab on disk (notimeout(1)dependency, no interactivereadprompt).remagic rebuild-hashtabfor post-update recovery.scripts/rebuild-hashtab.shandscripts/03-install-xovi.sh.remagic doctorto check for the hashtab file and whetherxovi.sois mapped into the running xochitl process.AppLoad on OS 3.28+
appload.sobuilt from rm-appload PR #59, while still pulling runtime shims from the official v0.5.3 zip.cli/embedded/(.gitignoreupdated accordingly).Test plan
Tested on a reMarkable Paper Pro (Ferrari), OS 3.28.0.162, USB + SSH:
remagic rebuild-hashtabcompletes and writes/home/root/xovi/exthome/qt-resource-rebuilder/hashtabappload.so,/home/root/xovi/startloads xovi without panic[qmldiff]: Loaded external AppLoad hooks in main UIstore,riddle) are listedCloses #2
Made with Cursor