linux: make main update script slightly more robust

On #249636 I had to manually run the updaters for hardened & libre kernels.
The cause was that `update-rt.sh` suddenly broke. Because I didn't want to
inhibit other kernel updates because of a rather niche variant, I decided to
move forward temporarily and take care of it later.

One issue was that the script failed silently, i.e. I only saw that the
script terminated early from my prompt. This is fixed now by making each
niche kernel updater print its exit code code if it failed. Also, errors
are allowed, i.e. a broken `update-rt.sh` doesn't block
`hardened/update.py` etc..

The issue itself is rather simple. When I updated the kernels in #249636,
the sha256sums.asc for rt kernels[1] looked like this:

    199bbb0cdb97ead22732473b95c8b2e8da62dfd71bde2339163119fb537a2b7c  patch-6.1.38-rt13-rc1.patch.gz
    a1af54f6987e96de06cad0a3226c5b5a992b60df084a904b6b94ea247fb46027  patch-6.1.38-rt13-rc1.patch.xz
    7bb68561787e46e3c433d9b514373ce368d587ac459b91df41934e70280d008f  patches-6.1.38-rt13-rc1.tar.gz
    ee65336dd6ae0be398796e7b75291918811a23e10121dc09bd84b244b12402fa  patches-6.1.38-rt13-rc1.tar.xz

However, the script itself skips any RC versions of the realtime
patches, so no releases were usable and the script failed. It's probably
possible to use the overview over all releases instead[2], however
that'd complicate the script notably. Anyways, since RT kernels don't
bump to each patch-level release, I don't think it hurts too much if
such an update is slightly more delayed. However if we want to fix this, I'd prefer
this to be fixed by folks who care more about rt kernels than I do.

[1] https://kernel.org/pub/linux/kernel/projects/rt/6.1/sha256sums.asc
[2] https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/6.1/older/sha256sums.asc

0 files changed, 0 insertions, 0 deletions