release notes mentioning dropped support?

[Paul Gevers]

Hi Kernel team,

I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.

Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

Paul

[Paul Gevers]

Hi Kernel team,

I know everybody is busy, but friendly ping.

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

Paul

[Salvatore Bonaccorso]

Hi,

Post by Paul Gevers
Hi Kernel team,
I know everybody is busy, but friendly ping.

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

Let's explicitly ask the "porters" for arm as listed in
(kernel-teamMAINTAINERS.Debian), Vagrant, Uwe, Roger, anyone from you
can comment on the above on how to document it?

Regards,
Salvatore

[Roger Shimizu]

Hi,

Post by Paul Gevers
Hi Kernel team,
I know everybody is busy, but friendly ping.

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.

for armel, the limitation is by:
https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35

And from the list in that file, below devices are not supported now.
# QNAP TS-119/TS-219: 2097152 - 64 = 2097088
# D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported)
# HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080
# QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080

I guess support for D-Link DNS-323 was dropped since buster, or earlier.

Post by Paul Gevers

Post by Paul Gevers
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

The upgrade of kernel may succeed if /boot still have enough space,
but reboot will fail because of the uboot configuration hard coded in
those hardware.
It's possible to update the uboot configuration, but if something is
wrong, it may brick the device, and no easy way to recover, except you
the device support serial or JTAG, and you have serial or JTAG cable.

Of course, remove some unused built-in module and rebuild own kernel
is always an option.
But it need continuous effort, for stable / security kernel updates.

Cheers,

[Paul Gevers]

Hi Roger,

Thanks for the reply,

Post by Roger Shimizu

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35
And from the list in that file, below devices are not supported now.
# QNAP TS-119/TS-219: 2097152 - 64 = 2097088
# D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported)
# HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080
# QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080
I guess support for D-Link DNS-323 was dropped since buster, or earlier.

I found this part earlier indeed. I was mostly wondering what we did in
the past (maybe nothing) and if we should mention it. Reading below, I
think we should.

Do the other architectures have similar devices where support is
dropped, or is this specific for armel?

Post by Roger Shimizu

Post by Paul Gevers
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

The upgrade of kernel may succeed if /boot still have enough space,
but reboot will fail because of the uboot configuration hard coded in
those hardware.
It's possible to update the uboot configuration, but if something is
wrong, it may brick the device, and no easy way to recover, except you
the device support serial or JTAG, and you have serial or JTAG cable.

Ouch. This sounds bad. And nothing is protecting the user against this?
Wouldn't it be possible/wise to have a check in preinst and abort the
upgrade in such cases? To protect the user from ending in such a state?

Post by Roger Shimizu
Of course, remove some unused built-in module and rebuild own kernel
is always an option.

Good to know. I wasn't sure if the Debian Linux kernel was built lean
with everything available as modules.

Post by Roger Shimizu
But it need continuous effort, for stable / security kernel updates.

Sure.

Paul

[Ben Hutchings]

Post by Roger Shimizu

Hi,

Post by Paul Gevers
Hi Kernel team,
I know everybody is busy, but friendly ping.

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35
And from the list in that file, below devices are not supported now.
# QNAP TS-119/TS-219: 2097152 - 64 = 2097088
# D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported)
# HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080
# QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080
I guess support for D-Link DNS-323 was dropped since buster, or earlier.

Yes, since stretch.

Post by Roger Shimizu

Post by Paul Gevers

Post by Paul Gevers
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

The upgrade of kernel may succeed if /boot still have enough space,
but reboot will fail because of the uboot configuration hard coded in
those hardware.

[...]

My understanding is that these devices load the kernel and initramfs
from fixed partitions on the on-board flash, not from the filesystem.
That's why the limits vary. flash-kernel is responsible for copying
the kernel and initramfs to these partitions. When the kernel is too
large, it will report an error, which should abort the package
installation.

To avoid this, users should keep the buster sources enabled and, before
upgrading, add an APT preferences file containing something like:

Package: linux-image-marvell
Pin: release a=buster
Pin-Priority: 900

(not tested). Obviously this will only work as long as buster is
supported.

Ben.

[Paul Gevers]

Hi all,

Proposed text for the release notes attached.

Post by Ben Hutchings

Post by Roger Shimizu

Post by Paul Gevers
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines#L35
And from the list in that file, below devices are not supported now.
# QNAP TS-119/TS-219: 2097152 - 64 = 2097088
# D-Link DNS-323: 1572864 - 8 - 64 = 1572792 (too small, no longer supported)
# HP Media Vault mv2120: 2097152 - 8 - 64 = 2097080
# QNAP TS-109/TS-209 & TS-409: 2097152 - 8 - 64 = 2097080
I guess support for D-Link DNS-323 was dropped since buster, or earlier.

Yes, since stretch.

Post by Roger Shimizu

Post by Paul Gevers
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?

The upgrade of kernel may succeed if /boot still have enough space,
but reboot will fail because of the uboot configuration hard coded in
those hardware.

[...]
My understanding is that these devices load the kernel and initramfs
from fixed partitions on the on-board flash, not from the filesystem.
That's why the limits vary. flash-kernel is responsible for copying
the kernel and initramfs to these partitions. When the kernel is too>
Ben.
large, it will report an error, which should abort the package
installation.
To avoid this, users should keep the buster sources enabled and, before
Package: linux-image-marvell
Pin: release a=buster
Pin-Priority: 900
(not tested). Obviously this will only work as long as buster is
supported.

As I own one of the unsupported devices, I intend to check if this works
as intended and I'll not push the change until confirmed. If I'm really
brave, I'll even check that flash-kernel errors out in the right way.

Paul

[Justin B Rye]

+ <section id="no-longer-supported-hardware">
+ <title>Hardware that's no longer supported</title>

The contraction "that's" seems out of place in a title - probably we
should just use:

<title>No longer supported hardware</title>

+ <para>
+ Due to hardware limitations, it's no longer viable for Debian
+ to build the <literal>Linux</literal> kernel supporting a
+ number of armel based devices that were supported in

This sounds as if it's talking about one kernel supporting multiple
armel-based devices; if it means one kernel per device, that's plural.

Due to hardware limitations, it's no longer viable for Debian
to build the <literal>Linux</literal> kernels supporting a
number of armel-based devices that were supported in
buster. The unsupported devices are:

Or maybe:

For a number of armel-based devices that were supported in
buster, it is no longer viable for Debian to build the
required <literal>Linux</literal> kernels, due to hardware

+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ QNAP TS-109/TS-209, TS-119/TS-219 and TS-409
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ HP Media Vault mv2120
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Users of those platforms that wish to upgrade to bullseye
+ nevertheless should keep the buster APT sources enabled and,
+ before upgrading, add an APT preferences file containing

Users of these platforms who wish to upgrade to bullseye
nevertheless should keep the buster APT sources enabled, and
before upgrading should add an APT preferences file containing
something like:

(Or maybe as two sentences, "Before upgrading they should...")

+ <programlisting>
+Package: linux-image-marvell
+Pin: release a=buster
+Pin-Priority: 900
+ </programlisting>
+ Obviously, the security support for this configuration will
+ end with the End Of Life of buster.

Obviously, the security support for this configuration will
only last until buster's End Of Life.

+ </para>
+ </section>
</section>
</chapter>
--
2.30.2

[Ben Hutchings]

Post by Justin B Rye

+ <section id="no-longer-supported-hardware">
+ <title>Hardware that's no longer supported</title>

The contraction "that's" seems out of place in a title - probably we
         <title>No longer supported hardware</title>

That would correctly be spelt with hyphens:

No-longer-supported hardware

Post by Justin B Rye

+ <para>
+ Due to hardware limitations, it's no longer viable for Debian
+ to build the <literal>Linux</literal> kernel supporting a
+ number of armel based devices that were supported in

This sounds as if it's talking about one kernel supporting multiple
armel-based devices; if it means one kernel per device, that's plural.

We've used only a single kernel flavour (marvell) for these devices
since before the stretch release.


[...]

Post by Justin B Rye

+ Users of those platforms that wish to upgrade to bullseye
+ nevertheless should keep the buster APT sources enabled and,
+ before upgrading, add an APT preferences file containing

Users of these platforms who wish to upgrade to bullseye
        nevertheless should keep the buster APT sources enabled, and
before upgrading should add an APT preferences file containing
(Or maybe as two sentences, "Before upgrading they should...")

Also we should not say "something like" since that suggests that some
system-specific adjustment is needed. I originally included those
words because I hadn't tested this configuration, but Paul said he
will.

Post by Justin B Rye

+ <programlisting>
+Package: linux-image-marvell
+Pin: release a=buster
+Pin-Priority: 900
+ </programlisting>
+ Obviously, the security support for this configuration will
+ end with the End Of Life of buster.

Obviously, the security support for this configuration will
only last until buster's End Of Life.

We (generally) shouldn't say "obviously" in documentation - if we
bothered to document it, it must not be that obvious.

Ben.

[Paul Gevers]

Hi,

+ <programlisting>
+Package: linux-image-marvell
+Pin: release a=buster
+Pin-Priority: 900
+ </programlisting>

My system is upgrading as I write this, at least one bug found. The pin
line should read:
Pin: release n=buster

Paul

[Paul Gevers]

Hi Kernel team,

Last release I sent out the message below and in the end we included
something [1] in the Release Notes mentioning dropped support. Is there
something like that worth mentioning this time around?

Paul

[1]
https://www.debian.org/releases/bullseye/armel/release-notes/ch-information.en.html#no-longer-supported-hardware

Post by Paul Gevers
Hi Kernel team,
I happen to own a QNAP (armel) and I spotted in the changelog that it's
not going to be supported in bullseye. I was wondering, is that
something that should be mentioned in the release notes? Obviously I
don't mean because I own it, but I'm betting that support for particular
hardware pieces has been dropped in the past too. I don't recall
something like that in the buster release notes, but even if we didn't
do it in the past, now could be a good moment to start if we think we
should add it.
Either way, I was wondering what would happen if I try to upgrade such a
device. I'm *assuming* that the linux package would detect that the
image is too big, but what would that leave me? A fully upgraded system
with an old kernel, or is there any detection before any upgrade
happens? For owners of such devices, is their only option to stay at
buster? E.g. is there any chance in building a smaller custom kernel
with less options enabled or is that impossible because nearly
everything is build as module?
Paul