Yes I realized your intention. But it's bad enough to try to run focussed discourse with "people that know" (also usually intended to be helpful), so when you don't know, just stay out of it... "listen and learn" so to speak.

Perhaps this thread can return to the wall program and how it behaves now versus in ancient times. (see eg post #3 above)

Please check in the Alt-F2 shell if there is a file
/lib/debian-installer-startup.d/S21ventoy-loop
and if so, share its content here.

Is the Ventoy partition on the USB an exfat filesystem with label "Ventoy"?

That is (or used to be) the requirement for a Ventoy based Devuan installation.

check BIOS to avoid "raid" disk control.

Perhaps it says that the ttm_bo_release module has an OOB dma access? At a guess it's a puts call with a non-terminated string...

I'm not really suggesting anything going bad. I am merely emphasizing that the kernel is not involved with any sort of filtering with respect to disk usage determinations.

Perhaps the different kernel package and those that go with it have that smaller footprint, to thus result in the smaller figure. Or sometimes one may forget about cached and trashed files as well as log files in a setup, which would typically result in a larger figure than it could be. If the difference is due to some mistake like that or whatever way, then it's just a mistake. Otherwise there  obviously is a significant aggregated difference in those software collections after installations.

There is also that possibility that the different reporting programs take measures into account the previously weren't included, though I would believe the newer method as more accurate and thus think "less bad" about them, rather than calling them "bad" for computing differently.

The kernel doesn't report disk usage. All raw figures are in filesystem meta data. Use dumpefs and stat to see them (other filesystem types than ext4 may have similar metadata access; there's always hexdump to go crazy with raw data).

There are many metadata number involved, and it's generally difficult to decide for each, whether and how it enters into a usage calculation. Perhaps the reporting program(s) with such calculations have changed? It won't be in the kernel, though.

man man

@Invisible_Pineapple: PLEASE USE "code" blocks for code ... you know: code  ... not c, but "code" ... it says "code" on the button.

There are two methods to use it, 1) is to click the button to make an emptycode block with the input cursor placed within it and then paste the code you want to pase. 2) is to paste first, then select that pasted text and click the code button which in that case will enclose that selected text.

The code but is the one saying "code".

Now I had to do this for you!! (probably not exactly right)

@Uityyy, the thing is, "Devuan" is not an organisation of "managers" waiting for "fly-by juniors" to give tasks to; no offence meant, but that image is kind of the expectation I read into your words.

To involve yourself in the Devuan project is different. It will require that you put yourself forward and take part and interest in the daily discourse (primarily on IRC discussions), and there step up to take on sorting out particular matters as needs and opportuinty arises.

You know and trust yourself I hope, but the key will be to become known and trusted among the Devuan group members, to then eventually be given opportunity for direct contribution to and responsibility for matters then at hand.

Thus: personal engagement to build trust and then eventually contribute towards the commons in the "cloak" of Devuan.

We do see people doing their own thing and publish their works on this forum. That's also good. Those are personal efforts fully driven by themselves, on the side of, rather than by, the Devuan project.

Yes, it's a good thing, and by the looks of it more end-user focussed/supportive than some others like qman and gtkman. I just wanted to read how to use it

It appears the section 7 man page for "man" has been moved into the "groff" package, and changed name to "groff_man". So, with "manpages" and "groff" packages installed, and of course the "man-db" package,  you should have the command man 7 man  providing a good reference manual for writing man pages.

As noted by @chomwitt there is a proliferation in documentation systems. In actual practice, the situation that historically started with :man pages", has been successively aggravated in time by a chain of successive concerted attempts to make "a better help system", through 1, 2 or a few year spurts into new-system setups and tooling, and then simply dropping the ball upon the humongous task of modifying all existing documentation for the new-system approach.

Nowadays there also seems to be effort to break up (or down) "man pages" by collating them split off from their subjects into side packages, and many sorts of destructive actions, that when questioned get motivated by statements like that the man pages are too ugly, too hard to understand or to out-of-date etc.

In any case, in my view it remains essential that software gets documented in respect of how to use it (as well as ideally in terms of design principles, actual implementation choices and even sub system architecture).