Debian Bookworm rootfs - missing boot-load modules & wasted space

Had to do a fresh install on my third M300 due to some weirdness caused by systemd/sysvinit stuff moving between init systems and back, but I decided to use the new bookworm rootfs from November.

Noticed a few things with the bookworm rootfs:

- There's a number of packages apt reports as "are installed and are no longer required" which seems to take up about 50MB of space. These should be shedded off to make the rootfs bzip smaller. The user will likely do the 'apt autoremove' anyway as instructed, but the fact is, the packages shouldn't have been there from the start if they're not required for the stock installation for minimum size constraints (and dropbox bandwidth!).

- Certain kernel modules are not enabled by default at boot with this new stock rootfs. This includes kirkwood_thermal for the two kirkwood cores that have it, orion_wdt for the orion/kirkwood watchdog timer, and marvell_cesa for hardware crypto. While all three of these are of mixed importance and the system runs without any of them enabled, the fact they're not starting at boot by default is slightly concerning for a universal flattened-device-tree rootfs. I understand they're either missing by accident or by design for memory savings, but a note should be made if it's the latter as some users do use these (especially those with the higher-end kirkwoods with the thermal sensor!) to drop them into /etc/modules to re-enable them.

These are all very minor issues but I haven't seen any posts making note of any of them, and the first point about the 50MB of space that could be saved affects the overall size of the initial image download and load-up.

====

as a closing note, I'm also noticing popularity-contest still isn't installed and enabled by default as it really should be, or there should be a note somewhere to install this optionally instead of just ignoring it. Debian devs and maintainers make note of how many devices on a specific port are reporting in to help bolster whether a port is worth keeping on the official branch or moved back to unofficial aside from any issues with compilation. Given everyone using the kernels from this forum are probably the majority of armel users still left, it'd be a good idea to make mention of it on the rootfs post at the very least (if not included in the rootfs) if we want to see official support in the next couple of major Debian releases. The only distro that still supports armel aside from Debian is Gentoo, and if Debian drops armel, that's all that will be left unless Debian is forked for just-armel or someone bribes Devuan to support armel until it's dropped by the kernel for good.

At time of writing, armel on popcon totals 227 users. I'm sure that only counts a miniscule fraction of the users that have installed any rootfs archives from this forum and the number can be much higher, at least into the 300-350 range by my own estimations (especially taking into account the number of sales of Kace M300s in the past couple years). with the small talk of armel possibly being retired from official with Debian 13, it's indeed crucial to get as many devices on that number count as possible, and it's imperative to either make note of it or enable this as a default package that takes next to nothing for space, and runs on a monthly cron job to anonymously report to Debian about the architecture of the device and which debian-released packages are on the system. Adding this in either as a side note on the rootfs release post or as a preinstalled package in a fixed rootfs is nothing bad and everything good for the sake of the port all kirkwood boxes run on.

I know there's not a whole lot of incentive to roll a new rootfs to fix all of this, but I'm still bringing it up so it doesn't get brought up any closer to the end of the 12.x release lifecycle.


EDIT: I'm aware of the CESA module issues with regard to drive encryption and am monitoring that, so the fact it's not enabled by default right now is a good thing.



Edited 1 time(s). Last edit at 02/23/2024 03:53AM by sudos.

@sudos,

Thanks! all good points. I'll update the release notes to include your recommendation.

BTW,

- Marvell CESA: agreed as your edit said.

- kirkwood_thermal: this module only works with the M300, afaict. Other boxes Kirkwood 88F6282 SoC seems not working properly, perhaps because they have their own method for thermal. So it might also be a good thing not to confuse the users with 2 different thermal monitoring methods. And the 88F6281 and 88F6192 SoC do not support kirkwood_thermal.

=====

I'm not entirely happy with the current rootfs, so I might release a new one with later kernel. I'm still finding a good reason in Debian bookwork later points update to make the effort worthwhile.

=====

According to my statistics, for Kirkwood rootfs, we had > 5,000 downloads for a single release at one point in the past. Over the lifetime of various versions of this rootfs, the total was > 10,000 downloads. But not sure how many were from the same users.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2: 444 downloads as of Feb 23, 2024
Debian-5.13.6-kirkwood-tld-1-rootfs-bodhi.tar.bz2: 1,304 downloads as of Feb 23, 2024

I'm using a free version of bitly so I cannot see much older satistics. And bitly display is misleading when we try to look at the packages history further back in the past (all history click counts are gone for older links).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/24/2024 04:24PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> - kirkwood_thermal: this module only works with
> the M300, afaict. Other boxes Kirkwood 88F6282 SoC
> seems not working properly, perhaps because they
> have their own method for thermal. So it might
> also be a good thing not to confuse the users with
> 2 different thermal monitoring methods. And the
> 88F6281 and 88F6192 SoC do not support
> kirkwood_thermal.

On this, still shouldn't matter, if the module is loaded and there's not hardware to make use of it, it'll just not load at boot time with this specific module I believe. other boxes with the Armada 310 shoved in do also have this, but they're far and few. I believe there's at least one NAS device with it as well? one of the dual-SATA models, can't remember which one off the top of my head. on that one I think there's definitely a thermal probe on the board for the fans to ramp up and down, but it's invisible to the system and only controls the exhaust fan. but given the SoC is not heatsunk to anything but the motherboard through the BGA balls, it relies on active cooling across the SoC's integrated sink cap to keep cool, very poor thermal design indeed. in the same way, it's like how I needed to add a huge thermal gap pad to the kirkwood in the Pogo v4 to the steel weight below the board in order to keep that cool, otherwise it would go into thermal run-away and lock up under heavy (synthetic) load as a webserver and IRC server leaf.

Would also like to recommend adding cpufrequtils as an added package to the updated rootfs, or as a note to have the user add it in if the user wants to enable frequency scaling for more power savings (and thermal management) on supported SoCs. Most have the ability to downclock as low as 400MHz at idle (Pogo V4 for instance, with said thermal issues) and the default settings without any configuration is more than enough to keep the power draw down. This takes up about 164KB of space installed and will also not enable itself if the SoC doesn't support it.

sudos Wrote:
> as a closing note, I'm also noticing
> popularity-contest still isn't installed
> and enabled by default ....
>
> At time of writing, armel on popcon totals 227
> users. I'm sure that only counts a miniscule
> fraction of the users that have installed any
> rootfs archives from this forum and the number can
> be much higher, at least into the 300-350 range by
> my own estimations (especially taking into account
> the number of sales of Kace M300s in the past
> couple years). ....

I wasn't even aware of popcon, but I immediately installed it on 5 devices (1x RPi, 2x P4 & 2x M300), and will be looking at the other boxen I have to get it set on those.

Thanks for pointing that out! That's why I read these posts - I actually learn something!

> - kirkwood_thermal: this module only works with the M300

I missed this pointer - how do I load/enable this module on my M300?

dhargens,

> > - kirkwood_thermal: this module only works with
> the M300
>
> I missed this pointer - how do I load/enable this
> module on my M300?

It should already be running. Check it:

lsmod

if not running then

modprobe kirkwood_thermal

And then you can print out the CPU temperature info (Celcius x 1000) from hwmon sysfs:

cat /sys/class/hwmon/hwmon0/temp1_input

To get it running during boot, add it to /etc/modules-load.d/modules.conf.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/24/2024 01:06AM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> dhargens,
>
> > > - kirkwood_thermal: this module only works
> with
> > the M300
> >
> > I missed this pointer - how do I load/enable
> this
> > module on my M300?
>
> It should already be running. Check it:
>

> lsmod
>

> if not running then
>

> modprobe kirkwood_thermal
>

>
> And then you can print out the CPU temperature
> info (Celcius x 1000) from hwmon sysfs:
>

> cat /sys/class/hwmon/hwmon0/temp1_input
>

>
> To get it running during boot, add it to
> /etc/modules-load.d/modules.conf.

and, once it's enabled, you can also alternatively use the lm-sensors package from apt.

as printed out from the M300 running my owntone library:

steve@fujiwara:~$ sensors
kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1:        +34.5°C

This corresponds to the Armada 310 SoC temperature only. Remember that the SoC is sinked to a rather large steel plate inside, and steel is a very bad thermal conductor. The SoC in the Pogo V4 easily saturates the thick steel weight inside when sinked to it as mine has been for the past decade. I pulled it out just now and with cpufrequtils *not* installed, I'm getting 50C on the bottom of the unit with an infrared thermometer I trust the readout of, booting from the current 12.4 rootfs off a flash drive. the M300 in turn should be reading about 44-52C off the sensor in a stock unmodified unit, and much lower (like mine) if you replace the thermal pad with a like-thickness copper shim.

in fact, I barely ever check the temps after said mod. the shim does such a good job that it's become a non-issue to check, but I still do check it once in a while out of curiosity once the seasons start changing.



Edited 1 time(s). Last edit at 02/24/2024 03:59AM by sudos.

sudos,

> On this, still shouldn't matter, if the module is
> loaded and there's not hardware to make use of it,

It should load automatically in the current rootfs. I'll double check.

OTOH, this module should be blacklisted in the Zyxel NAS 325 (also a Marvell 6282 SoC). This box does not use kirkwood_thermal and giving out wrong temperature when querried.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote
bodhi
> On this, still shouldn't matter, if the module is
> loaded and there's not hardware to make use of it,

It should load automatically in the current rootfs. I'll double check.

OTOH, this module should be blacklisted in the Zyxel NAS 325 (also a Marvell 6282 SoC). This box does not use kirkwood_thermal and giving out wrong temperature when querried.

It's all coming back to me now. For M300 kirkwood_thermal, there is no need to do anything. It will run automatically, because it is in the device tree specification. For other Kirkwood SoC boxes such as the Pogo V4, Sheevaplug,... the module is not loaded at all.

Furthermore, to avoid confusion, I had to backlist it on the Zyxel NSA325 as mentioned above. The NSA325 box uses i2cget to read CPU temperature.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/25/2024 03:29AM by bodhi.