Custom builds have different checksums

I had a bona fide reason to re-build a custom system upgrader (to v25.12.0) for my Linksys WRT1900ACS v1. Using the same settings and same list of packages the build completed without errors or warnings (as did the original build) but I was suprised to discover the checksums didn’t match.

Why is that? Is it as simple as the presence of a timestamp?

PS: I promise I’m not wasting time and resources on your build systems!

Packages could be different, too (depending on what system you're using).

To be clear, is this your own build environment or OpenWrt's?

A bona fide reason to keep building the same image...interesting.

This is using the OpenWRT firmware build system at https://firmware-selector.openwrt.org

Using the same list of packages. I checked the packages I was adding for my custom build and they seem to have the same release numbers. Perhaps other packages have been updated within the same overall release. I don’t know whether the OpenWRT project does that.

Bona fide reason? The device was at a remote site and I forgot to bring the upgrade I’d built the night before so I built it again and then noticed the checksums were different. I didn’t proceed and have been thinking about the situation. I meant to indicated that I was just repeatedly hitting the site rebuilding upgrades.

does everything inside both images have the same time stamp ?

a time stamp diff is enough to make the images have different checksums.

2 Likes

Like frollic says, even a simple time stamp change of a single file is enough to change the checksum. By default the build system aims for repeatability, by adjusting file timestamps to a epoch time (SOURCE_DATE_EPOCH).

Depending on your build process, there may be intentional deviations. For example, I write the exact build start date/time and the git repo status info to a file included in the image, unique for each build.

Ps. Similarly, the config option to "add info about build config" (= list of packages included) means that a new file about the package list is generated for the new build, and I am not sure if that file's timestamp is adjusted to the epoch time. Possibly.

2 Likes

But the ASU server grabs the latest packages from the rolling deliveries, so builds even minutes apart might get different package binaries...

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.