HDD led on the case is blinking constantly, at least twice per second, like a beacon. The blinking starts immediately after logging in, not in the login screen, and never stops. Other disk activity shows up as a normal blinking so at least that is working normally.
I tried iotop but didn’t learn anything useful. System monitor didn’t show anything interesting either.
How do I find out what is causing the pulsing? It bothers me because I don’t know what causes it. This behavior has been ongoing for, idk, couple of years now? I did an OS reinstall several months back and I could swear the blinking stopped but now it is back again.
I have an up-to-date Tumbleweed installation on a fast NVMe SSD, luks encrypted btrfs on root partition and encrypted xfs on home, no apparent problems with the system. Nothing special installed.
Hi, welcome
What is the DE used? KDE, GNOME, XFCE?
KDE. Naturally forgot to mention it…
That could be the baloo file indexer. Try this
balooctl6 stop
rm -rf ~/.config/baloo*
rm -rf ~/.local/share/baloo
balooctl6 start
This will rebuild the index and definitely will cause blinking for a while, depending at the size of your disk(s), but should not continue blinking.
Yep - baloo is certainly a possibility.
I discovered baloo was causing the issue (CPU and disk) using a system monitor (obvious). There were [documented bug] issues with baloo a while back, and supposedly corrected.
Anyway, I disabled baloo … for me, it offers zero advantages, especially considering its [constant excessive] disk and CPU usage.
baloo claims there is no argument stop so I used disable instead. I deleted everything and then enabled again. It didn’t stop the blinking at any point and re-indexing everything was apparently instantaneous. Previously there was 100 000 files, now is says 165 000 files and Indexer state is idle.
The blinking continues.
I would install the sysstat package and run:
> pidstat -d 5
Linux 7.1.8-1-default (chief) 2026-08-26 _x86_64_ (8 CPU)
21:12:27 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
21:12:32 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
21:12:37 1000 2925 0.00 157.60 92.00 0 firefox
21:12:37 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
21:12:42 1000 2925 0.00 4.00 0.00 0 firefox
21:12:42 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
21:12:47 1000 2925 0.00 92.00 92.00 0 firefox
Installed the package and ran the command. Gives no information, just the line that has UID, PID and the rest, nothing under it.
However, Firefox shows up as expected if I have it running.
I’m starting to think this is some sort of ghost phenomenon with my particular motherboard and Tumbleweed, or a curse, or something similar.
I have to test this with another computer at some point.
So, if you kill Firefox does the LED stop blinking?
No, I meant that when opening applications the led light blinks periodically, randomly, as you would expect. Firefox was just an example.
The led blinks constantly like a beacon, whether there are programs running or not (other than background services).
The blinking starts when logging in and stops after logging out.
Please show:
lsblk -f
cat /etc/fstab
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
└─nvme0n1p1 crypto_LUKS 1 db579cb8-f440-4353-9927-662da2aa457f
└─cr_hdd_PELIT xfs f0ec07c8-8fc6-4cfc-967a-17d3c3b76f15 1009,8G 47% /hdd/PELIT
nvme1n1
├─nvme1n1p1 vfat FAT32 636A-4427 110,9M 78% /boot/efi
├─nvme1n1p2 crypto_LUKS 2 c8e70ec1-3182-4f32-81a4-4fe7b69a3c45
│ └─cr_root btrfs 0ab64641-c4b5-487e-b837-5364d58eb1f9 26,9G 55% /var
│ /opt
│ /root
│ /srv
│ /usr/local
│ /.snapshots
│ /
└─nvme1n1p3 crypto_LUKS 1 f658c579-055c-4eeb-a245-264c083dbbd7
└─cr-auto-2 xfs 112fd52c-292a-41a8-9548-54dba91ac143 913,2G 50% /home
cat /etc/fstab
/dev/mapper/cr_root / btrfs defaults 0 0
UUID=0ab64641-c4b5-487e-b837-5364d58eb1f9 /var btrfs subvol=/@/var 0 0
UUID=0ab64641-c4b5-487e-b837-5364d58eb1f9 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=0ab64641-c4b5-487e-b837-5364d58eb1f9 /srv btrfs subvol=/@/srv 0 0
UUID=0ab64641-c4b5-487e-b837-5364d58eb1f9 /root btrfs subvol=/@/root 0 0
UUID=0ab64641-c4b5-487e-b837-5364d58eb1f9 /opt btrfs subvol=/@/opt 0 0
/dev/mapper/cr-auto-2 /home xfs defaults 0 0
UUID=636A-4427 /boot/efi vfat utf8,dmask=0077 0 2
/dev/mapper/cr_root /.snapshots btrfs subvol=/@/.snapshots 0 0
/dev/mapper/cr_hdd_PELIT /hdd/PELIT xfs nofail 0 2
I have mounted traditionally, since times before electricity, my personal data storages in a not-permitted and to-be-frowned-upon path of /hdd for my personal sanity. I yearn simplicity which is wasted effort these days, especially with computers.
My “tradition” haven’t caused any problems ever.
On this current system I have two NVMe SSDs: the one with root and home partitions and another that has only games (partition named PELIT).
I tested removing the PELIT SSD but it had no effect on the blinking.
Mod edit: fix code tags.
IMHO there is nothing odd with blinking.
Login, open a terminal and start top. Press “f”, navigate to the ioWop line, press spacebar, press “s”, then navigate to ioRop and press spacebar; press ESC.
Now you see processes sorted by ioWop, or I/O Write Operations; you should see that plasmashell is doing a few I/O ops per second, that’s your basic blinking with nothing running, just one user logged in to the graphical desktop.
Open Firefox and you will see several I/O ops per second, that’s increased blinking.
If you really want one blink per 30 seconds or so, exit the graphical session, login to a VT (for instance CTRL+ALT+F4) and just watch. If you simply start top you should see that top itself does 1 I/O op per second or so, so 1 blink every 1-2 seconds?
Since disk operations are cached, not every single I/O translates to actual reading or writing to disk, but the experiment above should give a feeling of what is going on.
Good catch, Bruno. My 2 latest laptops have no “HDD LED”, so noting blinks 
. But, the old ASUS has and guess what?
- Boot → login, continuous blinking
- Wait ~1 minute, almost none
- Login, do nothing, with all defaults as per install, blinker-de-blinker-de-blink
Should have thought this way before.
Yes, old ASUS here too 
Aside from the other things, have a look at
ls /sys/class/leds/and check for reference to the hdd led- Let 's say it is called hdd-led, then do
cat /sys/class/leds/hdd-led/trigger
What does that say?
pidstat also shows that and it is for me less than once per 20 seconds.
Give that this are NVMe’s my solution would be to physically disconnect the LED.
Or a bit of black insulation tape on the front of the box. 
A systemd-unit to disbable it through echo "none" > /sys/class/leds/<led-name-here>trigger should work. Confirmed by a friend who owns a perturbed gaming computer that was convinced it was a christmas-tree.
After changing the update interval of top it indeed was clear to me that there are constant operations, like plasmashell and kwin_wayland.
What bothered me was this particular computer is the only one out of many I have seen this behavior in.
Well, my point was not to prevent the blinking but to understand what caused it. I’m sure there is a lesson hidden in there, somewhere.
Thank you everyone for help.