Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #71841 > unrolled thread

release notes mentioning dropped support?

Back to article view | Back to linux.debian.kernel

Contents

  release notes mentioning dropped support? Paul Gevers <elbrus@debian.org> - 2021-05-24 07:00 +0200
    Re: release notes mentioning dropped support? Paul Gevers <elbrus@debian.org> - 2021-06-10 11:40 +0200
      Re: release notes mentioning dropped support? Salvatore Bonaccorso <carnil@debian.org> - 2021-06-11 06:30 +0200
        Re: release notes mentioning dropped support? Roger Shimizu <rogershimizu@gmail.com> - 2021-06-11 20:20 +0200
          Re: release notes mentioning dropped support? Paul Gevers <elbrus@debian.org> - 2021-06-11 20:50 +0200
          Re: release notes mentioning dropped support? Ben Hutchings <ben@decadent.org.uk> - 2021-06-11 21:50 +0200
            Re: release notes mentioning dropped support? Paul Gevers <elbrus@debian.org> - 2021-06-13 21:40 +0200
              Re: release notes mentioning dropped support? Justin B Rye <justin.byam.rye@gmail.com> - 2021-06-14 07:30 +0200
                Re: release notes mentioning dropped support? Ben Hutchings <ben@decadent.org.uk> - 2021-06-16 02:40 +0200
    Re: release notes mentioning dropped support? Paul Gevers <elbrus@debian.org> - 2023-06-04 22:10 +0200

#71841 — release notes mentioning dropped support?

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#72153

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#72157

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

[toc] | [prev] | [next] | [standalone]

#72158

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.
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

[toc] | [prev] | [next] | [standalone]

#72159

[Multipart message — attachments visible in raw view] — view raw

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 <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.

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

[toc] | [prev] | [next] | [standalone]

#72160

[Multipart message — attachments visible in raw view] — view raw

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:
> > 
> > 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.

[toc] | [prev] | [next] | [standalone]

#72182

[Multipart message — attachments visible in raw view] — view raw

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 <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.

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

[toc] | [prev] | [next] | [standalone]

#72184

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.

  	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
	limitations. 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:

	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
> 





-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package

[toc] | [prev] | [next] | [standalone]

#72200

[Multipart message — attachments visible in raw view] — view raw

wOn Mon, 2021-06-14 at 06:25 +0100, Justin B Rye wrote:
> 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>
> 

That would correctly be spelt with hyphens:

    No-longer-supported hardware

> > +      <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.

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.

> 
> > +	<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.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

[toc] | [prev] | [next] | [standalone]

#79225

[Multipart message — attachments visible in raw view] — view raw

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
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web