4 ms·

Sad to see support for QNAP dropped in the kernel packages for armel, presumably because the vmlinuz kernel is 500kb too large for the default flash partition.

by 0x0 5y ago

zozbot234 5y ago
This issue will also hit many mobile/embedded devices in the future where the kernel has to be flashed separately from the main installed system. (Debian does provide a flash-kernel workflow for this purpose.) The general solution is to use a separate bootloader (even Linux itself can be used as a bootloader via kexec), though this can involve a bit of wasted space.
- 0x0 5y ago
  Fingers crossed a solution could be found during the lifetime of debian11. The entire distro is ready for armel, such a shame that 500kb of missing flash partition space holds it back :-/ I saw one of the bugreports had a message talking about using a different flash partition but it involved a lot of scary uboot hex memory addresses, which without a serial console could be a quick way to make a brick...
  - ripdog 5y ago
    I don't know anything specific about your situation, so I'm sorry for sticking my nose in here, but isn't this a case where you just need to compile your own kernel with a bare minimum of modules for your hardware? Surely that would save 500kb.
    - 0x0 5y ago
      I'll have to look into it. I was hoping to ride the official marvell kernel binaries because building from custom sources on armel would be a great inconvenience. Also not sure I'll be able to find 500kb to cut that the debian people couldn't carve out. I would have thought these QNAP devices would make out a large percentage of the armel install base. Grateful that armel is still officially supported, just crazy that 500kb of missing default flash partitions is blocking access to the dozens of gigabytes of official debian armel goodness.
puzzlingcaptcha 5y ago
Was it really just partition size? I vaguely remember Buster cutting support for armel below ARMv5T and the Kirkwood SoC was not quite making it.
- 0x0 5y ago
  The release notes say you can pin the debian10 kernel* and upgrade everything else. So my impression is 500kb of flash is the only blocker * and then you're on your own for security and compatibility issues
- cbmuser 5y ago
  Yes, the baseline for “armel” is ARMv5T. But IIRC we made the switch already for Buster.

Sad to see support for QNAP dropped in the kernel packages for armel, presumably because the vmlinuz kernel is 500kb too large for the default flash partition.

by 0x0 5y ago

Sad to see support for QNAP dropped in the kernel packages for armel, presumably because the vmlinuz kernel is 500kb too large for the default flash partition.

zozbot234 5y ago

This issue will also hit many mobile/embedded devices in the future where the kernel has to be flashed separately from the main installed system. (Debian does provide a flash-kernel workflow for this purpose.) The general solution is to use a separate bootloader (even Linux itself can be used as a bootloader via kexec), though this can involve a bit of wasted space.

0x0 5y ago
Fingers crossed a solution could be found during the lifetime of debian11. The entire distro is ready for armel, such a shame that 500kb of missing flash partition space holds it back :-/ I saw one of the bugreports had a message talking about using a different flash partition but it involved a lot of scary uboot hex memory addresses, which without a serial console could be a quick way to make a brick...
- ripdog 5y ago
  I don't know anything specific about your situation, so I'm sorry for sticking my nose in here, but isn't this a case where you just need to compile your own kernel with a bare minimum of modules for your hardware? Surely that would save 500kb.
  - 0x0 5y ago
    I'll have to look into it. I was hoping to ride the official marvell kernel binaries because building from custom sources on armel would be a great inconvenience. Also not sure I'll be able to find 500kb to cut that the debian people couldn't carve out. I would have thought these QNAP devices would make out a large percentage of the armel install base. Grateful that armel is still officially supported, just crazy that 500kb of missing default flash partitions is blocking access to the dozens of gigabytes of official debian armel goodness.

puzzlingcaptcha 5y ago

Was it really just partition size? I vaguely remember Buster cutting support for armel below ARMv5T and the Kirkwood SoC was not quite making it.

0x0 5y ago
The release notes say you can pin the debian10 kernel* and upgrade everything else. So my impression is 500kb of flash is the only blocker * and then you're on your own for security and compatibility issues
cbmuser 5y ago
Yes, the baseline for “armel” is ARMv5T. But IIRC we made the switch already for Buster.