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

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

Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems Paul Gevers <elbrus@debian.org> - 2023-09-09 11:20 +0200
    Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems Bastian Blank <waldi@debian.org> - 2023-09-09 12:10 +0200
      Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems "Andrew M.A. Cater" <amacater@einval.com> - 2023-09-09 13:50 +0200
      Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems Domenico Andreoli <cavok@debian.org> - 2023-09-13 07:40 +0200
    Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems Ben Hutchings <benh@debian.org> - 2023-09-10 17:20 +0200
      Re: Releasing linux/6.1.52-1 bookworm-security update without armel  build, Image size problems Domenico Andreoli <cavok@debian.org> - 2023-09-13 08:00 +0200

#80342 — Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems

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

Hi Salvatore,

On 09-09-2023 10:15, Salvatore Bonaccorso wrote:
> but should have been support for armel been
> dropped earlier and should we do it for trixie

The kernel for armel went over some hardware limits before (I was 
affected with my NAS, where I couldn't upgrade the kernel to bullseye as 
documented in the release notes [1]). Is the current situation reaching 
the limit for all armel devices, or "just" for some and are the others 
probably fine for some years to come?

If we're now reaching the final limit and if it was foreseeable that we 
would reach that limit, then yes it would have made sense to drop armel 
*before* the bookworm release, but alas. If the kernel team can't 
support the kernel on armel, than armel shouldn't be a release 
architecture for trixie. If it's only some devices, than we "just" need 
to communicate that clearly.

I don't have a clear advice for the current situation in security and 
the next point release, let's hope you can stretch the situation a bit 
longer. I recall that the kernel package has safety checks in place and 
refuses to *try* to install the kernel if it doesn't fit on the 
hardware. That means that you don't cripple the hardware of affected 
people, but "merely" can't give them security support? I guess it would 
be possible (as long as support lasts; no LTS support) for effected 
systems to run the security supported bullseye kernel.

Paul

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

[toc] | [next] | [standalone]

#80343

Hi

On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> If we're now reaching the final limit and if it was foreseeable that we
> would reach that limit, then yes it would have made sense to drop armel
> *before* the bookworm release, but alas. If the kernel team can't support
> the kernel on armel, than armel shouldn't be a release architecture for
> trixie. If it's only some devices, than we "just" need to communicate that
> clearly.

We have two armel kernel currently:
- "marvell", for some CPU from Marvell, and
- "rpi", for Raspberry Pi 1 and related devices.

The first one is the one with included size limitations, because those
load the kernel from a pre-defined flash partition, whose size can't be
easily changed by the user.  This one is now overflowing for the second
to last documented one in the kernel package config.

The second one is for the original Raspberry Pi 1 type.  There we don't
have any size limits, as the kernel is loaded from a file system.
However those systems contain a ARMv6 CPU.  So our armel port is only
partially usable anyway, as is is built for ARMv4.  There exists with
Raspbian a better suited forked distribution with ARMv6 as target.

So yes there is a small number of devices we can still support with the
armel port, but where we are a bad choice.

Everything newer is ARMv7, supported by the armhf port, or ARMv8,
supported by the arm64 port.

Latest popcon for stable is:

linux-image-marvell: 31
linux-image-rpi: 7

Debian itself does not have any armel hardware.  Everything is done on
armhf or arm64.  Sadly the armhf supporting systems are already in the
progress of drying up.  Even some ARMv8 vendors do not longer include
32bit support.

Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

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

#80346

On Sat, Sep 09, 2023 at 11:42:45AM +0200, Bastian Blank wrote:
> Hi
> 
> On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> > If we're now reaching the final limit and if it was foreseeable that we
> > would reach that limit, then yes it would have made sense to drop armel
> > *before* the bookworm release, but alas. If the kernel team can't support
> > the kernel on armel, than armel shouldn't be a release architecture for
> > trixie. If it's only some devices, than we "just" need to communicate that
> > clearly.
> 
> We have two armel kernel currently:
> - "rpi", for Raspberry Pi 1 and related devices.
> 
> The second one is for the original Raspberry Pi 1 type.  There we don't
> have any size limits, as the kernel is loaded from a file system.
> However those systems contain a ARMv6 CPU.  So our armel port is only
> partially usable anyway, as is is built for ARMv4.  There exists with
> Raspbian a better suited forked distribution with ARMv6 as target.
> 

No - Raspbian contains commercial software now by default. We have to use
Raspberry Pi firmware but Raspberry pi is *not* purely ARM v6 it's ARM v6 with
hardware floating point - and therefore incompatible with Debian and every
other ARM v6 version. Although it is less than optimal, it is still perfectly
supportable by all the packages in armel.

> So yes there is a small number of devices we can still support with the
> armel port, but where we are a bad choice.
> 

See above: note that the Raspberry Pi Zero (original version) is still very
much in production and is 32 bit and ARM v6 hardware floating point. It is
still a prime target for armel - and the number of devices produced is not
small.

> Everything newer is ARMv7, supported by the armhf port, or ARMv8,
> supported by the arm64 port.
> 
> Latest popcon for stable is:
> 
> linux-image-marvell: 31
> linux-image-rpi: 7
> 
> Debian itself does not have any armel hardware.  Everything is done on
> armhf or arm64.  Sadly the armhf supporting systems are already in the
> progress of drying up.  Even some ARMv8 vendors do not longer include
> 32bit support.
> 

This is, unfortunately, the case. I'm not sure where our sd card images
are built but the Raspberry Pi iamges are built from Gunnar Wolf's scripts
primarily for everything prior to RPi4.

All best, as ever, 

Andy

[amacater@debian.org]

> Bastian
> 
> -- 
> Each kiss is as the first.
> 		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
> 		   stardate 4842.6
> 

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

#80413

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

On Sun, Sep 10, 2023 at 10:55:49AM +0800, Paul Wise wrote:
> On Sat, 2023-09-09 at 11:42 +0200, Bastian Blank wrote:
> 
> > The first one is the one with included size limitations, because those
> > load the kernel from a pre-defined flash partition, whose size can't be
> > easily changed by the user.  This one is now overflowing for the second
> > to last documented one in the kernel package config.
> 
> Seems like this would be solvable by writing a bootloader to the flash
> partition that would be able to load Linux from a normal filesystem?

Yes, if the support for the given device is mainlined.

I doubt this is the case for my QNAP though, would not dare to try.

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

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

#80364

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

On Sat, 2023-09-09 at 11:13 +0200, Paul Gevers wrote:
> Hi Salvatore,
> 
> On 09-09-2023 10:15, Salvatore Bonaccorso wrote:
> > but should have been support for armel been
> > dropped earlier and should we do it for trixie
> 
> The kernel for armel went over some hardware limits before (I was 
> affected with my NAS, where I couldn't upgrade the kernel to bullseye as 
> documented in the release notes [1]). Is the current situation reaching 
> the limit for all armel devices, or "just" for some and are the others 
> probably fine for some years to come?

The issue exists with many devices supported by the "marvell" flavour.
We also have an "rpi" flavour for armel that supports Raspberry Pi
models with Arm v6 CPUs, and that doesn't have any size limits that
we've needed to worry about yet.

> If we're now reaching the final limit and if it was foreseeable that we 
> would reach that limit, then yes it would have made sense to drop armel 
> *before* the bookworm release, but alas. If the kernel team can't 
> support the kernel on armel, than armel shouldn't be a release 
> architecture for trixie. If it's only some devices, than we "just" need 
> to communicate that clearly.
[...]

I would be quite happy to drop the "marvell" flavour for trixie.  The
size limits are a recurring problem, and the supported SoCs and devices
seem to have been out of production for a long time.  In contrast, the
Raspberry Pi models with v6 CPUs are still in production.

(I do have my doubts as to whether it will be possible to continue
supporting a useful user-space for armel, but I certainly can't speak
authoritatively about that.)

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

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

#80416

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

On Sun, Sep 10, 2023 at 05:13:52PM +0200, Ben Hutchings wrote:
> On Sat, 2023-09-09 at 11:13 +0200, Paul Gevers wrote:
> > Hi Salvatore,
> > 
> > On 09-09-2023 10:15, Salvatore Bonaccorso wrote:
> > > but should have been support for armel been
> > > dropped earlier and should we do it for trixie
> > 
> > The kernel for armel went over some hardware limits before (I was 
> > affected with my NAS, where I couldn't upgrade the kernel to bullseye as 
> > documented in the release notes [1]). Is the current situation reaching 
> > the limit for all armel devices, or "just" for some and are the others 
> > probably fine for some years to come?
> 
> The issue exists with many devices supported by the "marvell" flavour.
> We also have an "rpi" flavour for armel that supports Raspberry Pi
> models with Arm v6 CPUs, and that doesn't have any size limits that
> we've needed to worry about yet.

I happily delayed the issue by changing the layout of the mtd partitions
of my QNAP with a nice script [0]. It's able to handle a good number
of models and I think it's a great solution for the short/medium term.

> > If we're now reaching the final limit and if it was foreseeable that we 
> > would reach that limit, then yes it would have made sense to drop armel 
> > *before* the bookworm release, but alas. If the kernel team can't 
> > support the kernel on armel, than armel shouldn't be a release 
> > architecture for trixie. If it's only some devices, than we "just" need 
> > to communicate that clearly.
> [...]
> 
> I would be quite happy to drop the "marvell" flavour for trixie.  The
> size limits are a recurring problem, and the supported SoCs and devices
> seem to have been out of production for a long time.  In contrast, the
> Raspberry Pi models with v6 CPUs are still in production.

I would find reasonable if trixie dropped "marvell" flavor. The bell
for the armel QNAP devices has been warning for years already, anybody
caring of their data should move it somewhere else.

> (I do have my doubts as to whether it will be possible to continue
> supporting a useful user-space for armel, but I certainly can't speak
> authoritatively about that.)
> 
> Ben.
> 
> -- 
> Ben Hutchings - Debian developer, member of kernel, installer and LTS
> teams

[0] https://github.com/amouiche/qnap_mtd_resize_for_bullseye

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

[toc] | [prev] | [standalone]

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

csiph-web