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
Spent a fair bit debugging something. Came down to my DTB being out of sync. The lack of hash prefix should've warned me sooner.
The issue is that the dtb is not copied with anything generation specific in the filename. The builder assumes the file is CA-addressed by parent store path, to avoid redundant copies. However, it also assumes it can make this path by taking basename of the specified file.
This is file for initrd/kernel since they are second level in the derivation. However, this can't be assumed, and/or isn't true for the DTB.
I would just send a PR but I can't think of a super easy/clean way to do this. The current approach (of assuming the depth of the file) is not great, IMO, but nicely avoids hashing the individual files, etc. Using a regex or chopping the /nix/store prefix is not viable.
The only idea I have -- use a regex to just capture the first instead of a b32 looking hash and hope that's good enough. I can do this depending on vibes.
Steps To Reproduce
Steps to reproduce the behavior:
1.have two generation
2. have bug in older gen
2. delete dtb from wherever it gets put (esp mount point or xbootldr), just to prove
3. re-install, which re-creates files for all generations, oldest first
boot, notice old dtb, realize it lacks hash, realize this is fundamentally problematic.
Describe the bug
Spent a fair bit debugging something. Came down to my DTB being out of sync. The lack of hash prefix should've warned me sooner.
The issue is that the dtb is not copied with anything generation specific in the filename. The builder assumes the file is CA-addressed by parent store path, to avoid redundant copies. However, it also assumes it can make this path by taking basename of the specified file.
This is file for initrd/kernel since they are second level in the derivation. However, this can't be assumed, and/or isn't true for the DTB.
I would just send a PR but I can't think of a super easy/clean way to do this. The current approach (of assuming the depth of the file) is not great, IMO, but nicely avoids hashing the individual files, etc. Using a regex or chopping the
/nix/store
prefix is not viable.The only idea I have -- use a regex to just capture the first instead of a b32 looking hash and hope that's good enough. I can do this depending on vibes.
Steps To Reproduce
Steps to reproduce the behavior:
1.have two generation
2. have bug in older gen
2. delete dtb from wherever it gets put (esp mount point or xbootldr), just to prove
3. re-install, which re-creates files for all generations, oldest first
boot, notice old dtb, realize it lacks hash, realize this is fundamentally problematic.
cc: @jmbaur @ElvishJerricco
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result.Add a 👍 reaction to issues you find important.
The text was updated successfully, but these errors were encountered: