Re: release notes mentioning dropped support?
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 On 24-05-2021 06:55, Paul Gevers wrote: 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 OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
wOn Mon, 2021-06-14 at 06:25 +0100, Justin B Rye wrote: > Paul Gevers wrote: > > + > > + Hardware that's no longer supported > > The contraction "that's" seems out of place in a title - probably we > should just use: > > No longer supported hardware > That would correctly be spelt with hyphens: No-longer-supported hardware > > + > > + Due to hardware limitations, it's no longer viable for Debian > > + to build the Linux 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. We've used only a single kernel flavour (marvell) for these devices since before the stretch release. [...] > > + 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...") 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. > > > + > > +Package: linux-image-marvell > > +Pin: release a=buster > > +Pin-Priority: 900 > > + > > + 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. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
Paul Gevers wrote: > + > + Hardware that's no longer supported The contraction "that's" seems out of place in a title - probably we should just use: No longer supported hardware > + > + Due to hardware limitations, it's no longer viable for Debian > + to build the Linux 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. Due to hardware limitations, it's no longer viable for Debian to build the Linux 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 Linux kernels, due to hardware limitations. The unsupported devices are: > + > + > + > + > + QNAP TS-109/TS-209, TS-119/TS-219 and TS-409 > + > + > + > + > + HP Media Vault mv2120 > + > + > + > + > + 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...") > + > +Package: linux-image-marvell > +Pin: release a=buster > +Pin-Priority: 900 > + > + 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. > + > + > > > -- > 2.30.2 > -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Re: release notes mentioning dropped support?
Hi all, Proposed text for the release notes attached. On 11-06-2021 21:47, Ben Hutchings wrote: > On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: >> On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso >> 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. 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 From a58174c17ad3b6cdb19f4e908428f0b0e8bf53c3 Mon Sep 17 00:00:00 2001 From: Paul Gevers Date: Sun, 13 Jun 2021 21:30:33 +0200 Subject: [PATCH] issues.dbk: unsupported armel hardware --- en/issues.dbk | 34 ++ 1 file changed, 34 insertions(+) diff --git a/en/issues.dbk b/en/issues.dbk index 805a15be..01184f9a 100644 --- a/en/issues.dbk +++ b/en/issues.dbk @@ -775,5 +775,39 @@ Environment=SYSTEMD_SULOGIN_FORCE=1 + + Hardware that's no longer supported + + Due to hardware limitations, it's no longer viable for Debian + to build the Linux kernel supporting a + number of armel based devices that were supported in + buster. The unsupported devices are: + + + + + QNAP TS-109/TS-209, TS-119/TS-219 and TS-409 + + + + + HP Media Vault mv2120 + + + + + 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: + +Package: linux-image-marvell +Pin: release a=buster +Pin-Priority: 900 + + Obviously, the security support for this configuration will + end with the End Of Life of buster. + + -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > 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. 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 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. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: release notes mentioning dropped support?
Hi Roger, Thanks for the reply, On 11-06-2021 20:01, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso > 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. 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? 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? > 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. > But it need continuous effort, for stable / security kernel updates. Sure. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: release notes mentioning dropped support?
On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso 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. 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, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: release notes mentioning dropped support?
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? 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
Re: release notes mentioning dropped support?
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? Paul OpenPGP_signature Description: OpenPGP digital signature
release notes mentioning dropped support?
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 OpenPGP_signature Description: OpenPGP digital signature
