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?
Hi Kernel team,
I know everybody is busy, but friendly ping.
On 24-05-2021 06:55, Paul Gevers wrote:
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?
Hi,
On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote:
Hi Kernel team,
I know everybody is busy, but friendly ping.
On 24-05-2021 06:55, Paul Gevers wrote:
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?
On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
On 24-05-2021 06:55, Paul Gevers wrote:
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.
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.
On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
Hi,
On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote:
Hi Kernel team,
I know everybody is busy, but friendly ping.
On 24-05-2021 06:55, Paul Gevers wrote:
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.
[...]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.
On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote:
On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
On Thu, Jun 10, 2021 at 11:32:23AM +0200, Paul Gevers wrote:
On 24-05-2021 06:55, Paul Gevers wrote:
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.
Yes, since stretch.
[...]
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 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.
+ <section id="no-longer-supported-hardware">
+ <title>Hardware that's no longer supported</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
+ buster. The unsupported devices are:
+ </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
+ something like:
+ <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.
+ </para>
+ </section>
</section>
</chapter>
--
2.30.2
Paul Gevers wrote:
+ <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
+ buster. The unsupported devices are:
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.
+ 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
+ something like:
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.
+ <programlisting>
+Package: linux-image-marvell
+Pin: release a=buster
+Pin-Priority: 900
+ </programlisting>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 342 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:22:15 |
| Calls: | 7,552 |
| Calls today: | 8 |
| Files: | 12,730 |
| Messages: | 5,652,768 |