Kernel 6.1.0-50 for daedalus got a bug it seems...

greenjeans · Yesterday 19:05:56

Went to update the Vuu-do mini yesterday, it was using 6.1.0-49. Some 40+ updates including the new kernel. (linux-image-amd64 (6.1.174-1) to 6.1.176-1)

After installing I first noticed the issue in my conky display, it was underreporting disk space used by about 400 mb with the new kernel. Running df -h showed the same issue. It's a fact that this system installed is about ~2.7 gb or a little less, yet it's showing 2.27 gb in conky (fs_used) and 2.3 from the df command.

Seems it must be the kernel as the other updates don't seem to have anything to do with it. (mostly imagemagick, python, mesa, image and compression libraries).

Wonder what happened? Did it get some rust on it, lol?

fsmithred · Yesterday 21:02:24

I'm not seeing much difference in df output with 6.1.0-48 vs. 6.1.0-50 and also 7.1.3 in freia. Only about 1-2mb difference. Try it without the '-h'.

/dev/mapper/root_fs		199450960 137851664  6.1.0-50
/dev/mapper/root_fs		199450960 137850896  6.1.0-48
/dev/mapper/sda4_crypt	        199450960 137853112  7.x

/dev/sda5			29367400  24062932  6.1.0-50
/dev/sda5			29367400  24062712  6.1.0-48
/dev/sda5			29367400  24060396  7.1.3

Altoid · Yesterday 21:12:10

Hello:

greenjeans wrote:

... yet it's showing 2.27 gb in conky (fs_used) and 2.3 from the df command.

Me thinks [df -h] is rounding out.
Maybe there is a switch to make it give you decimal numbers?

I haven't found anything save using a script to parse.

This is on [Daedalus] after the last large update / upgrade:

$
uname -a
Linux devuan 6.1.0-50-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.176-1 (2026-07-02) x86_64 GNU/Linux
$

$ df -h
Filesystem      Size  Used Avail Use% Mounted on                             
/dev/sda1        40G  9.9G   30G  26% /                 # conky reports 9.86GiB / 39.1GiB 
/dev/sda5       705M   26M  626M   4% /var/log          # conky reports 25.8MiB / 704MiB
/dev/sda6        68G   31G   37G  46% /home             # conky reports 30.5GiB / 67.3GiB    
/dev/sdb2        67G   38G   25G  61% /media/1TB/TS     # conky reports 37.8GiB / 66.2GiB
/dev/sdb1       849G  701G  107G  87% /media/1TB/IMG    # conky reports 700GiB / 849GiB
$

Just found this:
https://computingforgeeks.com/check-dis … -with-duf/

# duf
╭───────────────────────────────────────────────────────────────────────────────────────────────╮
│ 8 local devices                                                                               │
├────────────────┬────────┬────────┬────────┬───────────────────────────────┬──────┬────────────┤
│ MOUNTED ON     │   SIZE │   USED │  AVAIL │              USE%             │ TYPE │ FILESYSTEM │
├────────────────┼────────┼────────┼────────┼───────────────────────────────┼──────┼────────────┤
│ /              │  39.1G │   9.9G │  29.1G │ [#####...............]  25.2% │ ext4 │ /dev/sda1  │
│ /home          │  67.3G │  30.5G │  36.8G │ [#########...........]  45.3% │ ext4 │ /dev/sda6  │
│ /media/1TB/IMG │ 848.5G │ 700.3G │ 106.4G │ [################....]  82.5% │ ext4 │ /dev/sdb1  │
│ /media/1TB/TS  │  66.2G │  38.2G │  24.6G │ [###########.........]  57.7% │ ext4 │ /dev/sdb2  │
│ /media/300GBIT │ 273.9G │ 143.4G │ 116.5G │ [##########..........]  52.4% │ ext4 │ /dev/sdf1  │
│ /media/storage │ 273.9G │ 146.3G │ 113.7G │ [##########..........]  53.4% │ ext4 │ /dev/sdd1  │
│ /media/stuff   │  66.7G │  20.6G │  42.7G │ [######..............]  30.9% │ ext4 │ /dev/sde1  │
│ /var/log       │ 704.3M │  25.8M │ 626.0M │ [....................]   3.7% │ ext4 │ /dev/sda5  │
╰────────────────┴────────┴────────┴────────┴───────────────────────────────┴──────┴────────────╯
╭───────────────────────────────────────────────────────────────────────────────────────────────────╮
│ 6 special devices                                                                                 │
├────────────────┬────────┬────────┬────────┬───────────────────────────────┬──────────┬────────────┤
│ MOUNTED ON     │   SIZE │   USED │  AVAIL │              USE%             │ TYPE     │ FILESYSTEM │
├────────────────┼────────┼────────┼────────┼───────────────────────────────┼──────────┼────────────┤
│ /dev           │   3.8G │     0B │   3.8G │                               │ devtmpfs │ udev       │
│ /dev/shm       │   2.1G │     0B │   2.1G │                               │ tmpfs    │ tmpfs      │
│ /run           │ 787.5M │ 808.0K │ 786.7M │ [....................]   0.1% │ tmpfs    │ tmpfs      │
│ /run/lock      │   5.0M │   8.0K │   5.0M │ [....................]   0.2% │ tmpfs    │ tmpfs      │
│ /run/user/1000 │ 787.5M │   8.0K │ 787.5M │ [....................]   0.0% │ tmpfs    │ tmpfs      │
│ /sys/fs/cgroup │   3.8G │     0B │   3.8G │                               │ tmpfs    │ cgroup     │
╰────────────────┴────────┴────────┴────────┴───────────────────────────────┴──────────┴────────────╯
#

Screen output is in decimals, colour and apparently configurable.
Niiiice ...

Best,

A.

Edit:
Fixed [/dev/sdb1] and [/dev/sdb2] that had printout swapped.

Last edited by Altoid (Yesterday 22:25:37)

greenjeans · Yesterday 22:05:45

Trust me it's there. And i've used every command imaginable, df, du, dumpe2fs etc.

Possibly something in my hardware as always, but I have two other partitions on 49 and they are reporting correctly while the 50 partition is stating that it's 400 mb less than what it really is. This system has been in maintenance mode for months as it's stable and works as intended, so i've just been doing updates when there's a kernel update and/or important security updates. At those times I do a little tweaking and sometimes add a little, this time I added VuuMan and the Lightdm settings editor, less than a mb but it should have added to the total. It's been stable at around 2.65-2.7 gb's for some 8 months and was at 2.66 before the updates.

In the file manager on any of the partitions you can right-click and choose "properties" and it simple adds up all the files and sizes and they are all reporting that it's around 2.7 gb. I ran Refracta-snapshot and it firsts makes a copy of the running system and the total of that is reflected in the terminal it's running in, and it also says 2.7 gb.

EDIT: Oh forgot to mention, the snapshot I ran came out to be exactly the same size plus a couple of kb, as the last snapshot I did before I swapped in the new kernel. If the system really was 400 mb smaller is should have resulted in around 120-140 mb smaller iso. It's the same size.

There is nothing I did during updates that could have possibly saved me 400 mb, lol, i'll post the log of what I did. This is a bug of some kind.

Commit Log for Sat Jul 11 17:32:27 2026

Upgraded the following packages:
imagemagick (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
imagemagick-6-common (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
imagemagick-6.q16 (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
libcaca0 (0.99.beta20-3) to 0.99.beta20-3+deb12u1
libcurl3-gnutls (7.88.1-10+deb12u14) to 7.88.1-10+deb12u15
libcurl4 (7.88.1-10+deb12u14) to 7.88.1-10+deb12u15
libegl-mesa0 (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libgbm1 (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libgif7 (5.2.1-2.5) to 5.2.1-2.5+deb12u1
libgl1-mesa-dri (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libglapi-mesa (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libglx-mesa0 (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libgraphite2-3 (1.3.14-1) to 1.3.14-1+deb12u1
libhtml-parser-perl (3.81-1) to 3.81-1+deb12u1
libhttp-daemon-perl (6.16-1) to 6.16-1+deb13u1~deb12u1
libinput-bin (1.22.1-1) to 1.22.1-1+deb12u1
libinput10 (1.22.1-1) to 1.22.1-1+deb12u1
liblzma5 (5.4.1-1) to 5.4.1-1+deb12u1
libmagickcore-6.q16-6 (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
libmagickcore-6.q16-6-extra (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
libmagickwand-6.q16-6 (8:6.9.11.60+dfsg-1.6+deb12u10) to 8:6.9.11.60+dfsg-1.6+deb12u11
libpoppler-glib8 (22.12.0-2+deb12u1) to 22.12.0-2+deb12u2
libpoppler126 (22.12.0-2+deb12u1) to 22.12.0-2+deb12u2
libpython3.11 (3.11.2-6+deb12u7) to 3.11.2-6+deb12u8
libpython3.11-minimal (3.11.2-6+deb12u7) to 3.11.2-6+deb12u8
libpython3.11-stdlib (3.11.2-6+deb12u7) to 3.11.2-6+deb12u8
librabbitmq4 (0.11.0-1+deb12u1) to 0.11.0-1+deb12u2
libssl3 (3.0.20-1~deb12u1) to 3.0.20-1~deb12u2
libxatracker2 (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
libxml2 (2.9.14+dfsg-1.3~deb12u5) to 2.9.14+dfsg-1.3~deb12u6
linux-base (4.9) to 4.12.1~deb12u1
linux-image-amd64 (6.1.174-1) to 6.1.176-1
mesa-va-drivers (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
mesa-vdpau-drivers (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
mesa-vulkan-drivers (22.3.6-1+deb12u1) to 22.3.6-1+deb12u2
openssl (3.0.20-1~deb12u1) to 3.0.20-1~deb12u2
p7zip (16.02+really25.01+dfsg-0+deb12u1) to 16.02+really26.01+dfsg-0+deb12u1
p7zip-full (16.02+really25.01+dfsg-0+deb12u1) to 16.02+really26.01+dfsg-0+deb12u1
poppler-utils (22.12.0-2+deb12u1) to 22.12.0-2+deb12u2
python3-urllib3 (1.26.12-1+deb12u3) to 1.26.12-1+deb12u4
python3.11 (3.11.2-6+deb12u7) to 3.11.2-6+deb12u8
python3.11-minimal (3.11.2-6+deb12u7) to 3.11.2-6+deb12u8
rsync (3.2.7-1+deb12u5) to 3.2.7-1+deb12u6
wireless-regdb (2026.02.04-1~deb12u1) to 2026.05.30-1~deb12u1
xz-utils (5.4.1-1) to 5.4.1-1+deb12u1

Installed the following packages:
lightdm-gtk-greeter-settings (1.2.2-5)
linux-image-6.1.0-50-amd64 (6.1.176-1)

Commit Log for Sat Jul 11 18:06:17 2026

Completely removed the following packages:
linux-image-6.1.0-49-amd64

Last edited by greenjeans (Yesterday 22:13:16)

greenjeans · Yesterday 22:26:27

The size is right about the size of the kernel itself...maybe they changed the way it reports disk usage to omit the kernel itself from the total. I was up last night until 2:00 a.m testing, and resumed doing so earlier today to rule out anything else.

ralph.ronnquist · Yesterday 23:46:02

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.

greenjeans · Today 01:30:43

The kernel doesn't report disk usage. All raw figures are in filesystem meta data

That's the thing, the superblock where that metadata is stored is reporting wrong seemingly. And calculating wrong, and reporting wrong. Have tried dumpe2fs and stat, and they're not reporting anything more than what's been written in that metadata, which is wrong. The kernel is doing this.

ralph.ronnquist · Today 03:06:03

That thought, that "The kernel is doing this", is were you are wrong. The metadata is the bit pattern stored on disk. and there is no kernel "filtering" in between happening. I'm not sure why you want to persist with that thought, but you are of course free to do it.

blackhole · Today 07:39:41

Here you have presented the scenario along with your theorised cause and there's really nothing there in the way of useful data. Perhaps you lost some cache or similar data from /tmp in the course of a reboot after a kernel upgrade? Were any packages removed? Who can say? One can only speculate. If it were a kernel bug, you could easy have proven / eliminated that yourself by booting from the previous kernel...

Last edited by blackhole (Today 07:40:40)

greenjeans · Today 13:02:49

Ralph:

That thought, that "The kernel is doing this", is were you are wrong. The metadata is the bit pattern stored on disk. and there is no kernel "filtering" in between happening. I'm not sure why you want to persist with that thought, but you are of course free to do it.

So you're suggesting all those reporting tools went bad at once somehow? I'm open to suggestion here Ralph, but that seems a little implausible, what on that list of upgrades do you suppose might have caused it if not the kernel?

blackhole:

Were any packages removed? Who can say? One can only speculate

I can say and I don't need to speculate, I provided a list of them above, did you read it before you posted this?

If it were a kernel bug, you could easy have proven / eliminated that yourself by booting from the previous kernel...

I have the exact same system sitting on the partition next to it using the older kernel, not sure what more gems of assumption you have laying around, but they're not helping.

ralph.ronnquist · Today 14:40:21

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.

greenjeans · Today 15:24:34

I don't even use a trash can and if I did it would get emptied I assure you before rolling up an iso, even though Snapshot truncates some log files, I still go into /var/log and manually rotate them all and delete old ones, /var/log is always at about 130k before I run the snapshot on the mini system. The depths I go to before I make a run are in fact a little shocking to some, cleaning the caches and backups, old status and diversions files in dpkg, lintian overrides, locales, translations, histories, synaptic etc. I know this file system well.

I find it hard to believe that it was previously reporting incorrect sizes for the last 2 years and somehow just now corrected that, I did briefly consider that.

There's no way those packages that got updated are 400 mb less than their predecessors. And still I am left with the fact that some methods are reporting 2.3 gb, and others are reporting 2.7 gb. And the two different isos ran from those systems are identical in size.

If the kernel didn't create that data that df is referencing, then what does create it?

Just trying to get some data here before I run through the whole process of re-installing the earlier version then doing the updates for a third time. I haven't filed a bug report yet because I want to be thorough about it. But if this is indeed a bug, it could be bad if a user is maxing out their disk space but being told they have room yet, this is why I couldn't just let it slide, if it happened to you would you not go to some effort to find out why and maybe warn folks?

chris2be8 · Today 16:20:23

Try mounting one of the 49 partitions on the 50 partition and see what the 50 partition says about it as well as itself (keep a copy of the output with a note saying what was looking at what). Then reboot into that 49 partition, mount the 50 partition on it and see what 49 says about them.

That should tell you if it's the software or it was the disk contents that changed.

If you want to be really sure mount a third partition read-only on both partitions and compare what they say about it.

I'd also compare df -h with df -k and df -i in all cases (the more data you have the better).

blackhole · Today 16:56:04

Or cut out the drama, get the previous kernel and boot from that. Also install the latest stable kernel and boot from that - compare the results...

If you were to report a bug, those are the kind of steps which would be expected as a bare minimum.

greenjeans · Today 18:04:34

Chirs2be8 - Thanks, but have already done that numerous times.

Blackhole - Already done that too. "drama", lol, that's too rich coming from you.

Did all that last night into the wee hours of the morning. Not sure what it takes to convince y'all that I have quadruple checked and tested in multiple ways. It's simply a fact that it's 2.7 gb in size, not 2.3 gb. df is reporting wrong and so is dumpe2fs for whatever reason.

But if the concensus is that it's not an issue then I won't bother reporting it. I'll wait on updates until the next kernel update and see what happens then.

The officially official Devuan Forum!

#1 Yesterday 19:05:56

Kernel 6.1.0-50 for daedalus got a bug it seems...

#2 Yesterday 21:02:24

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#3 Yesterday 21:12:10

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#4 Yesterday 22:05:45

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#5 Yesterday 22:26:27

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#6 Yesterday 23:46:02

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#7 Today 01:30:43

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#8 Today 03:06:03

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#9 Today 07:39:41

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#10 Today 13:02:49

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#11 Today 14:40:21

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#12 Today 15:24:34

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#13 Today 16:20:23

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#14 Today 16:56:04

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

#15 Today 18:04:34

Re: Kernel 6.1.0-50 for daedalus got a bug it seems...

Board footer