Why? (Really, hear me out.)

[killemov]

I currently run Bullseye with a Buster kernel on ye olde QNAP TS119. And after having a kernel clusterf*ck of my own design (kernel in flash older than kernel on disk) I started to wonder if having the kernel image in flash is absolutely necessary.

The kernel is expected to keep growing in size and eventually it won't fit in the resized mtdblock anymore anyway. I also had the experience in the past that (unchanged) images were flashed waaay to often. (I had it triggered when simply doing a minor upgrade of Python 2.x.) The kernel in flash is also not self-contained like the QNAP firmware itself. (At least the old version as I only used it for a short period many years ago.) It still needs the kernel modules on disk. Meanwhile the /boot area appears to be used only for staging when building new flash files.

So why not go the way of the Odroid and flash Petitboot instead of a patched kernel? (mkimage and injecting dtb) Looking at some image sizes the total is always less than 9M. That is for an arm64 Odroid HC4, a stripped armel build is expected to be way smaller.

And even if you could flash a Bullseye, or larger, kernel or go with Petitboot instead ... Is it worth it in terms of performance and security?

[amouiche]

Hi.

There are plently of possible solutions. U-boot is even able to directly load files from an IDE device of from some filesystems So a solution could also to  used this kind of features. But:

• the current uboot firmware doesn't seem to be able to look into all SATA ports
• uboot scripts (bootcmd env variable) is limited in features
• we don't want to change the uboot image to avoid any brick

Having a 2nd stage bootloader based on a simple linux + kexec (like petitboot) is also a nice and flexible solution. This 2nd stage bootloader fitting in Flash, searching for final linux image in any possible mountable filesystems with a /boot directory (for example)...I did that in the past (very long time ago)

BUT, all those solution are requiring some dev time which is not negligeable for an "end of life" device like QNAP. That's why I developped the resizing script as a "quick win" to be able to flash the standard bullseye image without involving myself too much in it.

Anyway, Petitboot & co are really great  project to dig into ARM linux booting internals. This is not waste of time at all ! But this is an area I already covered for professionally, and I have unfortunately plenty other personal projects to deal with currently.

Regards, Arnaud

On Mon, 2022-11-14 at 07:51 -0800, killemov wrote:

I currently run Bullseye with a Buster kernel on ye olde QNAP TS119. And after having a kernel clusterfck of my own design (kernel in flash older than kernel on disk) I started to wonder if having the kernel image in flash is absolutely necessary. The kernel is expected to keep growing in size and eventually it won't fit in the resized mtdblock anymore anyway. I also had the experience in the past that (unchanged) images were flashed waaay to often. (I had it triggered when simply doing a minor upgrade of Python 2.x.) The kernel in flash is also not self-contained like the QNAP firmware itself. (At least the old version as I only used it for a short period many years ago.) It still needs the kernel modules on disk. Meanwhile the /boot area appears to be used only for staging when building new flash files. So why not go the way of the Odroid and flash Petitboot instead of a patched kernel? (mkimage and injecting dtb) Looking at some image sizes the total is always less than 9M. That is for an arm64 Odroid HC4, a stripped armel build is expected to be way smaller. And even if you could flash a Bullseye, or larger, kernel or go with Petitboot instead ... Is it worth it in terms of performance and security? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.**>

[killemov]

Positive feedback but ...

And even if you could flash a Bullseye, or larger, kernel or go with Petitboot instead ... Is it worth it in terms of performance and security?

[amouiche]

On Wed, 2022-11-16 at 06:06 -0800, killemov wrote:

Positive feedback but ...

And even if you could flash a Bullseye, or larger, kernel or go with Petitboot instead ... Is it worth it in terms of performance and security? What can be expect from a "up to date" kernel...

• Performance: no, don't expect better raid / samba / nfs throughput 

• Security: yes, bugs and doors are fixed. But this is not as scary as long as your NAS is not reachable from internet .

• bug fix : yes/no.   As far as I'm concerned, I don't experience bugs with my QNAP so no reason to bother. Updating the kernel may on contrary include new bugs. That's why I'm always careful when the kernel+initrd is upgraded during a "apt upgrade". I always backup my MTD first... in case... Yet, I'm using BTRFS on my NAS (mainly for snapshot feature), and I will be happy to have potential bugs fixed, even if I don't experience them.

• features: It may be true in few years, especially once systemd will require a newer kernel than the buster's one. But otherwise, most of the standard NAS daemons should work correctly with a old kernel.

Personally, I do kernel upgrades "on principle" because I fell they must be in phase with the rest of the Debian Userland packages. But I agree that a Buster kernel + bulleseye (or next debian )) Userland will continue to work correctly for lot of years to come.

Arnaud

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.*** m>