[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: