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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature