We have a small issue with one of the new types. Any tips on how to get a matching hash for Proposal: 130082 - ICP Dashboard ? Thank you. BTW link in proposal summary is broken and the replica check script gives different hash.
Hi @ZackDS ,
Thanks for checking this proposal. I tried running the verification and got the following output:
##### GUESTOS SHA256SUMS #####
/tmp/tmp.dWYRLt9MvF/ic/artifacts/icos/guestos /tmp/tmp.dWYRLt9MvF/ic
019237d2db9c1729a828dcd91cd2a42e8d6e71bcef59755e1d3f948f169062c5 *disk-img.tar.gz
81ea9e1c0d87ee54d92c27603d4b1499683d59b88859c5a3d826f0fc4dc9c101 *disk-img.tar.zst
df32223f115060ad43f75f2a6184559c47b2adec74bd5a900ff8ea2ed047472a *update-img-test.tar.gz
93b4ef855760e95f5c06e4a29b81bb09918863e8b3d51ecc58bc48816899e899 *update-img-test.tar.zst
198caa41fcda5295e5e7dd4b3ceded8350a9dbc0bd6c3b6f8b1620d618872723 *update-img.tar.gz
c47b6907062a50a988131972be464ff7a49c1b10157f089acdc97ec450460e54 *update-img.tar.zst
/tmp/tmp.dWYRLt9MvF/ic
##### HOSTOS SHA256SUMS #####
/tmp/tmp.dWYRLt9MvF/ic/artifacts/icos/hostos /tmp/tmp.dWYRLt9MvF/ic
ff00506878dd593593edc743354fd8439d9b5fe1d044e7db53f185c15874f851 *disk-img.tar.gz
6eb23c7ba907207bbd86f5176ac8d96543c54cde4e60005120993fb540de896f *disk-img.tar.zst
09651da1bdf44903e1e70d276d3b042d70f06a913a2b64c0661719289321ed91 *update-img-test.tar.gz
e295fb28d6ed6577de6ff3310828feeb4d2ae6dc2663716ac38faa7975e601ac *update-img-test.tar.zst
9a9723222628b4b7591fb9a8397dd7ba2751edc0db9a6cd5a527832b70193204 *update-img.tar.gz
e16853e079a38b7ca16bdff4e4b4ef27b1ab0cfefdf125a620b5449a15c798c5 *update-img.tar.zst
/tmp/tmp.dWYRLt9MvF/ic
##### SETUPOS SHA256SUMS #####
/tmp/tmp.dWYRLt9MvF/ic/artifacts/icos/setupos /tmp/tmp.dWYRLt9MvF/ic
156b53a375942c69cafbf2d7706016fafbff4dabcbc1dd1e1ac19b839fe725c9 *disk-img.tar.gz
e794fa7f6b440b3dedf7b5714b05d79abaf5f5bf4b7ecb06bb491ca4f62462c4 *disk-img.tar.zst
/tmp/tmp.dWYRLt9MvF/ic
Build complete for revision ec35ebd252d4ffb151d2cfceba3a86c4fb87c6d6
2024/05/24 | 18:24:06 | 1716575046 [+] Built IC-OS successfully
2024/05/24 | 18:24:15 | 1716575055 [+] Check hash of locally built artifact matches the one fetched from the proposal/CDN
2024/05/24 | 18:24:15 | 1716575055 [+] Verification successful for GuestOS!
2024/05/24 | 18:24:15 | 1716575055 [+] The shasum for GuestOS from the artifact built locally and the one fetched from the proposal/CDN match:
Local = 198caa41fcda5295e5e7dd4b3ceded8350a9dbc0bd6c3b6f8b1620d618872723
CDN = 198caa41fcda5295e5e7dd4b3ceded8350a9dbc0bd6c3b6f8b1620d618872723
2024/05/24 | 18:24:15 | 1716575055 [+] Verification successful for HostOS!
2024/05/24 | 18:24:15 | 1716575055 [+] The shasum for HostOS from the artifact built locally and the one fetched from the proposal/CDN match:
Local = e16853e079a38b7ca16bdff4e4b4ef27b1ab0cfefdf125a620b5449a15c798c5
CDN = e16853e079a38b7ca16bdff4e4b4ef27b1ab0cfefdf125a620b5449a15c798c5
2024/05/24 | 18:24:15 | 1716575055 [+] Verification successful for SetupOS!
2024/05/24 | 18:24:15 | 1716575055 [+] The shasum for SetupOS from the artifact built locally and the one fetched from the proposal/CDN match:
Local = 156b53a375942c69cafbf2d7706016fafbff4dabcbc1dd1e1ac19b839fe725c9
CDN = 156b53a375942c69cafbf2d7706016fafbff4dabcbc1dd1e1ac19b839fe725c9
2024/05/24 | 18:24:15 | 1716575055 [+] All images are validated successfully
And the proposal payload is
{
hostos_version_to_elect:"ec35ebd252d4ffb151d2cfceba3a86c4fb87c6d6"
hostos_versions_to_unelect:[]
release_package_sha256_hex:"9a9723222628b4b7591fb9a8397dd7ba2751edc0db9a6cd5a527832b70193204"
release_package_urls:[
0:"https://download.dfinity.systems/ic/ec35ebd252d4ffb151d2cfceba3a86c4fb87c6d6/host-os/update-img/update-img.tar.gz"
1:"https://download.dfinity.network/ic/ec35ebd252d4ffb151d2cfceba3a86c4fb87c6d6/host-os/update-img/update-img.tar.gz"
]
}
So I do not observe any contradiction.
I agree that the link is broken; looks like it was supposed to be
https://github.com/dfinity/ic/tree/release-2024-05-22_23-01-base
but due to a typo it was published as (note the +base at the end)
https://github.com/dfinity/ic/tree/release-2024-05-22_23-01+base
Please let us know if you have further concerns.
2 Likes
Thank you for the quick response, you are right after checking again we only looked at the end of the script. My / our bad. Got used to looking for GuestOS matches we only screen capture the end and there it matches the .tar.zst for HostOS, indeed looking up the .tar.gz matches the payload.(that should have been clear if we paid more attention to details such as the listed url). Maybe this could be made clear in future proposals either by changing the script or specify the file hash to be checked ? Thanks again.
2 Likes
Hi Arshavir,
By now, am sure the “repro-check.sh” script will need to be updated to accommodate the new hostos edge case (with the -p flag).
If the script is run with proposal id as input, it reaches this step where it expects a “replica_version_to_elect” field:
(Link: ic/gitlab-ci/tools/repro-check.sh at d1504fc4265703c5c6a73098732a4256ea8ff6bf · dfinity/ic · GitHub)
But the Host OS proposal has a specific field of “hostos_version_to_elect” and not the “replica” one. Proof: https://ic-api.internetcomputer.org/api/v3/proposals/130082
Think we need a fix where either the field is changed to a more simple “version_to_elect”, or an if that chooses the right key depending on the type of proposal.
Kindly let us know what is possible 
Thanks,
Tiago
3 Likes
Since there were several questions posted in this thread by reviewers on the CodeGov team, I’m cross linking our final summary report…
1 Like
Thanks @ZackDS, @tiago89 for your diligence and suggestions.
Let’s discuss these in the other thread suggested by @wpb , as the current thread has a different topic.
1 Like
Quick update regarding ic-js / nns-js.
The version 5.2.0-next-2024-08-19 now includes the consistently-named topics and NNS function names, as per the table above.
2 Likes