rpi-update
rpi-update copied to clipboard
check kernel version and issue warning if necessary
Fixes #178 for real this time
The problem is the NOTICE.md mechanism is a general purpose scheme for warning about any change that may cause issues - not just for the 4.0 kernel.
The correct solution is for WARNING.md to include a git hash for the first update that requires the warning. E.g. a line like `HASH: abcdef0123456789abcdef`` Call this hash W. The last rpi-update hash in in /boot/.firmware_revision. Call this U. The latest hash you are updating to is L.
Then, if U < W && L >= W you display the warning.
How to achieve this when hashes are not incremental?
This repo is committed to linearly (without rebases/merges) so the date of the hashes should be in order. If you run with JUST_CHECK=1 it prints a list of commits since you last updated. Grepping that for the HASH listed in NOTICE.md should say if you are including the WARNING commit.
I have updated the script so it can compare commit hashes. Also added HASH to NOTICE.md in rpi-firmware repo.
Looks promising. Can you handle the case where HASH is not present in NOTICE.md (I think you should get the warning unconditionally) Can you handle the case where /boot/.firmware_revision is not present (treat LOCAL_HASH date as very old).
@shrx any chance you would update this to @popcornmix spec so it can be merged?
@shrx it would be cool if you had the time to make the small changes so this PR could be merged.
Sorry, I completely forgot about this. Will have a look at what needs to be done.
@Ruffio @popcornmix I think everything is in order now, it should handle the case where HASH is not present in NOTICE.md and where /boot/.firmware_revision is not present.
Currently we have a dependency on curl but not wget, and this PR adds a dependency on wget. Is is possible to switch to using curl for get_hash_date?
@popcornmix can you check now? I removed the offending spaces (hopefully all) and switched to curl.
Should the curl include -L?
I think we needed to add that to all other uses as github sometimes redirects responses.
It can't hurt, I guess.
@popcornmix is this good to go? I guess that the "add -L to curl in all other places" should be performed in another PR?
With the current NOTICE.md file, we discard the first line of the message. I suspect we want to use NOTICE when NOTICE_HASH_EXISTS=true and FULL_NOTICE when NOTICE_HASH_EXISTS=false.
@popcornmix merge?
@shrx any chance you would do the last changes so we can get this PR merged? It would be awsome to get it in place. Think about it
@lurch @popcornmix ready to merge?
@popcornmix ready to merge?
@popcornmix ready to merge?
@shrx any chance you would update this PR?
@Ruffio what needs updating?
@shrx Have you read @lurch comments and observations? It also looks like there is a conflict to be resolved.
@shrx is this still relevant?