"Commit 901e325f772f "ARM: bugs: add support for per-processor bug
checking" added a new member to struct processor. This structure
is always instantiated in built-in code and the new member is only
used in built-in code. Therefore we can safely add the new member
at the end instead.
Move it to the end and hide it from genksyms. Also hide it when
building modules, to make sure they really don't use it."
This is actually 100% true. Stable is the culmination of the Debian Release Engineering / Testing Freeze process.
In Unstable, packages are promoted from Experimental as I understand it which is a comparatively easy threshold to get past. In Testing, packages are only promoted from Unstable if they 1) don't have any bugs open against them, and 2) there is not a freeze on. 50% of the time (1 year) there is a freeze on.
In Freeze, only bug fixes are promoted to Testing. New features have to take a number.
When the freeze is over, Testing is cut and becomes the new Stable. I might have described some part of this subtly wrong, but this is the Debian release management process in a nutshell. To read more: https://release.debian.org/
In short, "Stable" should be read like stable compound, not like we usually interpret it to mean "doesn't crash" in IT.
It's a side effect of not changing often, that it probably doesn't crash too much. The crashing bugs wouldn't have made it into testing, or through the testing/freeze process. Hopefully, at least.
I personally prefer to run Unstable on my developer machines, because it gets fixes more frequently:
> Security updates are made by the maintainer; they may not be effective on all architectures, and may be delayed. Packages uploaded may not meet release standards, but any breakage is expected to be fixed promptly. Updates are made by maintainers.
>It's a side effect of not changing often, that it probably doesn't crash too much.
I don't think that's true, it's likely that the actual causes of crashes are better known and documented, I don't think there is a particular way you can make a software release be less likely compared to other releases of the same software.
Misleading label to say, e.g. "The horse is unstable." when intending to explain how the horse is outside the stable. (re: Stable == Compound in Debian-speak.)
> "Because when it breaks, it is broken in a stable way."
Hubris.
How can you declare something "stable" if you don't perpetually run tests to verify it is indeed "stable"?
And to state the obvious: certain bugs will lead to instability, non-deterministic, and undefined behavior - that's the very nature of things breaking down.
We do at https://fosdem.org on our custom made video gear. That's 56 boxes in a crucial spot in our operation. We went out of our way to make sure we had plain vanilla mainline Debian stable packaged linux running on the Allwinner A20 based boards that power them, instead of some binary arm kernel with all kinds of issues.
I'm sure it's small, but at least a few of us are here. Also worth noting is that (most) Raspberry Pi (an ARM SBC) users are indirectly Debian users too. (and I'm a Pi user as well)
There's just about zero chance that this bug would make it into raspbian stable, though, since they are always at least several months behind debian-stable on AMD64.
I have 10 Raspberry Pi's with Debian Stretch and Jessie - the Raspbian variant. I updated a "sacrificial" Pi and rebooted without error.. this time!
Package: linux-libc-dev
Version: 4.9.82-1+deb9u3+rpi1
Priority: optional
Section: devel
Source: linux-4.9
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Installed-Size: 4,466 kB
Provides: linux-kernel-headers
Homepage: https://www.kernel.org/
Download-Size: 1,300 kB
APT-Manual-Installed: no
APT-Sources: http://raspbian.raspberrypi.org/raspbian stretch/main
armhf Packages Description: Linux support headers for userspace
development This package provides userspaces headers from the Linux
kernel. These headers are used by the installed headers for GNU libc
and other system libraries.
As others have mentioned, Raspbian kernel updates are delayed behind the Debian ones. The linked bug report states it was introduced between 4.9.135-1 and 4.9.144-1 (of linux-image-4.9.0).
I use 2 Olimex A20 Micro with Debian stable as personal servers (Web, Email, Backup).
One of them had already installed the toxic update via unattended-upgrades.
Fortunately I did not configure automatic reboot.
So I had the chance to read about the issue here on Hacker News and reinstall the old version:
I'm glad I can. It's a known, trusted distribution I've been using since 2001 on my main PC. It runs my personal web server since 2013 on a Cuibeboard and it works well. I've got a stable system which I'm familiar with, plus automatic updates, no binary blobs, vanilla kernel and all.
I can't think of a better solution if the SBC is supported. What would you recommend as an alternative?
I do, at least for some personal projects. They're more than capable enough for many tasks, and cheap enough to be willing to just grab another if you have a quick task.
love this note on it:
"Sure, maybe. I've suggested kernelci as a useful thing to help here, but we really need to be testing kernels complete with all the Debian patches to..."
so does that mean they test the kernel but not their own patches to it? seems silly :D
The problem patch is in http://deb.debian.org/debian/pool/main/l/linux/linux_4.9.144... (I think)
"Commit 901e325f772f "ARM: bugs: add support for per-processor bug checking" added a new member to struct processor. This structure is always instantiated in built-in code and the new member is only used in built-in code. Therefore we can safely add the new member at the end instead.
Move it to the end and hide it from genksyms. Also hide it when building modules, to make sure they really don't use it."