You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cache root images on the device to avoid repeated transfers during reinstalls #7
When reinstalling Omarchy on my iPad 6th generation (Wi-Fi/J71b), the installer transfers the entire compressed root image over USB each time, even when I am installing the same build.
The image in my recent install was approximately 1,048.5 MiB, transferring at around 5.3 MiB/s. Repeating that transfer adds a noticeable wait when retrying an installation or testing the same image.
Proposed improvement
Cache the compressed root image on the existing Linux-data partition and reuse it for subsequent installations when its checksum matches the selected image.
The cache should live outside the installation directory, so replacing /omarchy does not remove it. This should not require an additional partition or changes to the partition layout.
Expected behavior
On the first installation, transfer the image normally and retain a complete cached copy.
On subsequent installations of the same image, verify the cached copy against the expected checksum and extract it locally instead of transferring it again.
If the selected image has changed, or the cached copy is missing, incomplete or corrupt, transfer the full image again.
Keep the cache across replacement of /omarchy, and make it clear in the progress output when a cached image is being used.
Scope
This is a request for whole-image caching, not delta updates or an in-place system upgrade. Full transfers for different builds are fine, and local verification and extraction would still be necessary.
The goal is simply to avoid repeatedly transferring an unchanged image. This would likely require device-side support in hardware and corresponding cache negotiation in the host CLI.
No problem! The idea came up while troubleshooting touchscreen stalls on my iPad. The main benefit I see is being able to build a test image once and do several clean installs from it, whether that’s reproducing an intermittent install/first-boot problem or checking the same PR a few times.
It would also be handy for getting back to a known baseline after experimenting with packages, software and settings. That makes it easier to check whether a problem is in the build or something changed on the installed system.
Beyond that, it could help with testing CLI/installer changes against a fixed rootfs, creating a second clean installation in another directory, and retrying an install if something fails after the image has been cached. Device-specific setup would still run as usual, and the same approach could work for both Omarchy and minimal-linux.
Wi-Fi transfers sound great! That would speed up sending new images, while caching would avoid transferring the same image again.
I’ve started working on this in my forks: It keeps one verified image on the existing Linux partition, outside the install directory, so no extra partition is needed. CI passes, but iPad testing is still to do. Wanted to flag the work so we don’t duplicate it!
Omarchy #5: a small test-only adjustment for the additional capacity check.
The first install transferred and cached the image. Subsequent installs reused it without another root-image transfer, both when replacing the existing installation and when installing into another directory. All reached system readiness, and the extraction progress updated throughout.
The best displayed local extraction rate was 16.6 MiB/s for the roughly 1 GiB image. I haven’t measured the full installation time yet.
Happy to hear what you think, especially with the boot-layout changes you’re working on.
Thanks again for the implementation and the testing on your iPad 6. The CLI, hardware and Omarchy PRs it was built on were closed when those repositories were merged into orchard, and the install path is being replaced by the new installer, so we're not planning root-image caching in its current form.
If you still need repeatable installs of the same image with the new installer, you're welcome to think about how caching would fit there and propose it in a new issue. Closing this one for now.
Activity
henrikklee commentedon Oct 27, 2026
Thanks for the Resize APFS PR!
Will look into the caching. Currently working on a new boot layout with device side auto discovery of installations to reduce dependency on host.
Will also add WiFi as transfer which will speed up rootfs loading vs USB A.
What's your use case for repeated reinstallations of the same rootfs?
stuart902 commentedon Oct 27, 2026
No problem! The idea came up while troubleshooting touchscreen stalls on my iPad. The main benefit I see is being able to build a test image once and do several clean installs from it, whether that’s reproducing an intermittent install/first-boot problem or checking the same PR a few times.
It would also be handy for getting back to a known baseline after experimenting with packages, software and settings. That makes it easier to check whether a problem is in the build or something changed on the installed system.
Beyond that, it could help with testing CLI/installer changes against a fixed rootfs, creating a second clean installation in another directory, and retrying an install if something fails after the image has been cached. Device-specific setup would still run as usual, and the same approach could work for both Omarchy and minimal-linux.
Wi-Fi transfers sound great! That would speed up sending new images, while caching would avoid transferring the same image again.
I’ve started working on this in my forks: It keeps one verified image on the existing Linux partition, outside the install directory, so no extra partition is needed. CI passes, but iPad testing is still to do. Wanted to flag the work so we don’t duplicate it!
stuart902 commentedon Oct 28, 2026
Quick update: I’ve opened the implementation PRs and tested it on my iPad 6 Wi-Fi:
The first install transferred and cached the image. Subsequent installs reused it without another root-image transfer, both when replacing the existing installation and when installing into another directory. All reached system readiness, and the extraction progress updated throughout.
The best displayed local extraction rate was 16.6 MiB/s for the roughly 1 GiB image. I haven’t measured the full installation time yet.
Happy to hear what you think, especially with the boot-layout changes you’re working on.
henrikklee commentedon Nov 3, 2026
Thanks again for the implementation and the testing on your iPad 6. The CLI, hardware and Omarchy PRs it was built on were closed when those repositories were merged into orchard, and the install path is being replaced by the new installer, so we're not planning root-image caching in its current form.
If you still need repeatable installs of the same image with the new installer, you're welcome to think about how caching would fit there and propose it in a new issue. Closing this one for now.