I've fixed the most mistakes I made via shellcheck, but not all.
That's a judgment you ofc have to make yourself, but I normally assume that shellcheck is right and I'm not.
Quote
the fixed version of the script is exchanged now in comment #5 to not blow up this thread.
Why not in #1? That's the easiest to find. If you want to keep it in #5, then link to it in #1?
Quote
* just a bad habit or in my fingers using rm with "-r".
I'm not a fan of using -f 'by default' either, but it's easier to make the case where that is warranted
Quote
I couldn't find something "potentially catastrophic";
I delete at three points in the script, always bundled with a true of the prev. command, e.g. cd ~/.update && rm -f *;
that should be fine, cause if nothing is to update there shouldn't be anything in ~/.update (left from me).
Oh, you'd be surprised in all the ways a 'seemingly' simple script can fail. See Bugs in Hello World to see how the simplest program 'of all times' can fail 
Over time I've learned to create the ThisShouldNeverHappenException class (in Java) and you'd be surprised how many times that got triggered :-O
I don't know about busybox's rm applet, but the 'standard' rm program added a check that rm -rf wasn't executed from '/' and errors out (unless you add an explicit parameter to override that) even though the user specified '-f' (force)! Too many people ran that command 'accidentally' from the wrong dir and thereby completely wiping out their system. Unrecoverable.
It's good that you thought about defensive programming 
Quote
also I work in /tmp what is a) cleaned via reboot and b) I delete what I downloaded there
* 'mktemp'
there is a variant using tmpfile with a process number at the end in bash (in sh too ?)
currently can't remember hwo it extactly called ...
You use wildcard ('*') instead of explicitly named file(s) (or directories), so you may be using/removing more then you expect(ed). If other programs/addons use /tmp too, you may be breaking their operations.
I used mktemp as that is available on LE, but IIRC (on my Debian Sid box) its use is actually deprecated. The goal is to create a temporary file (or directory) yourself, work with that file/directory and when done, clean/remove that file/directory (explicitly, thus no use of wildcards). Which function is used to create to temporary file/directory, is not important.
Quote
* script runs on LE here with #!/bin/bash
Yep and that works.
But if you check the script with tools like shellcheck, then it verifies it against the actual bash program, which isn't what's used on LE. Changing the shebang to #!/bin/dash (the default non-interactive shell on Debian (based?) systems) may be useful too as it may reveal issues when it would be run under that shell. Even though you have no intention to actually run it against dash, it could improve the quality of your script nonetheless.
Quote
* functions
I usually do use them esp. when I need to run parts of the script more then once
That's indeed the most common reason to use functions.
Another reason is to make the code better structured and (thereby) readable. I think that's a worthwhile goal in itself, but it also makes it easier for others to review the script
When code is in the 'global namespace' it gets run no matter what, including after an error occurred which is probably not what you want. When code is put into functions, that code is only executed when explicitly called.
And that call can be guarded/surrounded by various test/if-statements.
If your code is structured like this:
setup_working_dir() {}
check_for_update() {}
download_update() {}
verify_downloaded_update() {}
install_update() {}
cleanup_working_dir() {}
Then the code in the 'global namespace' would then just be calling those functions, guarded by checks.
Very readable and code only gets executed when all the preconditions are met.
There are (ofc) multiple ways to do that, but this (structure) is what I prefer. YMMV.
Quote
extend the script with more hardware types ... [like RPi]
You may want to take into account that people could be using a 512MB or 1GB SD card on which downloads fail because of -ENOSPACE
HTH
