On Sat, 2021-06-12 at 03:01 +0900, Roger Shimizu wrote: > On Fri, Jun 11, 2021 at 1:22 PM Salvatore Bonaccorso <car...@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.
signature.asc
Description: This is a digitally signed message part
