The small linux problem thread

[Shadowbane]

My first mistake was not updating my KDE Neon in over a year. I have just started using my computer about a week ago. My second mistake was when I used PKcon update to update KDE Neon, I did not see there was some dependencies that failed to update or could not find. Third mistake was when some application did not run right, I did a full distribution upgrade which caused my problems with Nvidia graphic cards. I probably could have work out my issues, but it was faster to just nuke my harddrive and install Kubuntu 24.04. Now I won’t have to worry about Wayland for about 5 years hopefully Wayland and Nvidia graphic card issues will be fixed by then.

[Trooper_ish]

@Shadowbane

not updating my KDE Neon in over a year.

[mild reeeing noises escape…]

@Shadowbane

I have just started using my computer about a week ago

Oh, it’s been siting waiting for a year, not in use slowly getting more and more outdated…

my bad bud

[Shadowbane]

That is right I had not used it in almost a year. Had eye surgery last september, then after the surgeries I got hit with severe depression. All I did until a week ago was eat, sleep and watch TV.

[Trooper_ish]

seee… now, a hit of [working] linux, may have cured all that depression! /s

okay, I make light of the worlds widest spread ailment, and the struggle those inflicted are.

I’m glad you are giving linux a good try now!

some people, just give up and go back to windows!

[MazeFrame]

@Trooper_ish

German layout for normal use, and US layout, becuae US style is easier for coding?

Exactly this.

[regulareel]

Got it running as you wanted?

[MazeFrame]

Yep.

Took a little more trial & error than I would like to admit, but works now.

[mihawk90]

I just stumbled on something that boggles me a bit…
I wanted to list a directory, with filesizes for each file. Of course ls -l shows this, and ls -lh makes it have sensible sizes.
However, I was wondering if there was a way to show only the size since I don’t care about the rest.

There is ls -s, however, that shows entirely different numbers that make no sense to me:

 ls -l | grep pyload.log
-rw-rw-r--+ 1  568  568 4889847 Jun 25 11:09 pyload.log
-rw-rw-r--+ 1  568  568 5242711 Jun 23 14:45 pyload.log.1
-rw-rw-r--+ 1  568  568 5224327 Jun 15 00:47 pyload.log.10
-rw-rw-r--+ 1  568  568 5242694 Jun 22 05:03 pyload.log.2
-rw-rw-r--+ 1  568  568 5242554 Jun 20 23:54 pyload.log.3
-rw-rw-r--+ 1  568  568 5242671 Jun 19 20:31 pyload.log.4
-rw-rw-r--+ 1  568  568 5242698 Jun 18 12:33 pyload.log.5
-rw-rw-r--+ 1  568  568 5242700 Jun 17 00:21 pyload.log.6
-rw-rw-r--+ 1  568  568 5228782 Jun 16 01:08 pyload.log.7
-rw-rw-r--+ 1  568  568 5234738 Jun 15 16:51 pyload.log.8
-rw-rw-r--+ 1  568  568 5232659 Jun 15 08:35 pyload.log.9
 ls -s | grep pyload.log
 553 pyload.log
 685 pyload.log.1
1693 pyload.log.10
 525 pyload.log.2
 457 pyload.log.3
1297 pyload.log.4
 489 pyload.log.5
1021 pyload.log.6
1865 pyload.log.7
1757 pyload.log.8
1741 pyload.log.9

Now, the files are indeed 5MB each (pyload caps them at 5MB by default), but what exactly is the point of -s then?
Manual says:

-s, --size
print the allocated size of each file, in blocks

But given that all files (except the first because it’s still being written to) are the same size, it would mean that each file uses differently sized blocks? So how is -s useful in any way…?

[Trooper_ish]

Can one use the tool du for this?

Not sure about a whole folder listed tho
[Edit: I have used it on single files, and on a folder itself, not the files individually inside a directory]

[mihawk90]

@Trooper_ish

Can one use the tool du for this?

du is showing what ls -s is showing:

 du * | grep pyload.log
589     pyload.log
685     pyload.log.1
1693    pyload.log.10
525     pyload.log.2
457     pyload.log.3
1297    pyload.log.4
489     pyload.log.5
1021    pyload.log.6
1865    pyload.log.7
1757    pyload.log.8
1741    pyload.log.9

(and can’t be formatted with -h)

edit:
actually, seems -b gives the filesize back:

du * -b | grep pyload.log
4958712 pyload.log
5242711 pyload.log.1
5224327 pyload.log.10
5242694 pyload.log.2
5242554 pyload.log.3
5242671 pyload.log.4
5242698 pyload.log.5
5242700 pyload.log.6
5228782 pyload.log.7
5234738 pyload.log.8
5232659 pyload.log.9

And with -h:

 du * -bh | grep pyload.log
4.8M    pyload.log
5.0M    pyload.log.1
5.0M    pyload.log.10
5.0M    pyload.log.2
5.0M    pyload.log.3
5.0M    pyload.log.4
5.0M    pyload.log.5
5.0M    pyload.log.6
5.0M    pyload.log.7
5.0M    pyload.log.8
5.0M    pyload.log.9

Still wondering what the point of seeing “blocks” is though when apparently the block size differs… or the usage within each block, however which way that works.

[wertigon]

Well… Another option would be ls -hs I suppose.

Another thing that I tend to use all the time is du -hs to get the exact filesize of a specific file.

As for showing the amount of blocks, that was useful in the beginning of UNIX, but now the block size is more or less irrelevant except for very niche use cases.

[Trooper_ish]

it’s a bit mad to me.
i alias la as ls -lash for what seems easier to parse for me

a quick quak, infers:

Disk usage is the amount of space that can’t be used for something else because your file is occupying that space.

In most cases, the apparent size is smaller than the disk usage because the disk usage counts the full size of the last (partial) block of the file, and apparent size only counts the data that’s in that last block.

from linux - Why is the output of `du` often so different from `du -b`? - Stack Overflow

with the next post going further into block boundries

[mihawk90]

@wertigon

Well… Another option would be ls -hs I suppose.

Except no. That was the first thing I used and why I was stumped in the first place. I just dropped the -h in the first post to make it more clear.
It just takes the block numbers and divides them by 1000:

 ls -sh | grep pyload.log
 589K pyload.log
 685K pyload.log.1
 1.7M pyload.log.10
 525K pyload.log.2
 457K pyload.log.3
 1.3M pyload.log.4
 489K pyload.log.5
1021K pyload.log.6
 1.9M pyload.log.7
 1.8M pyload.log.8
 1.7M pyload.log.9

@Trooper_ish

i alias la as ls -lash for what seems easier to parse for me

That just adds the non-sensible block-size to the -l output

@Trooper_ish

In most cases, the apparent size is smaller than the disk usage because the disk usage counts the full size of the last (partial) block of the file, and apparent size only counts the data that’s in that last block.

That’s what I meant earlier with

or the usage within each block, however which way that works.

But that explanation doesn’t explain the wildly different numbers on my output. It would mean that every file occupies wildly different percentages within each block, which again makes that number meaningless. i.e. I can’t infer an actual filesize from the block usage when every block is used at a different rate.
So let’s assume a block is 4K each, that would mean some files are using almost every block fully, and others only a third of each block.

[jlittle]

ls -lh | awk '{printf "%5s %s\n", $5, $9}'

[Molly]

I recently picked up a second monitor, and since then I’m having some odd issues that feel like n-key rollover stops working on my keyboard. It only happens if the monitor is active (i.e. ‘join displays’). if I set it to single display it stops - doesn’t matter which display. Issue has persisted when keyboard and mouse are plugged into new monitor’s USB hub, old monitor’s USB hub, and directly into the PC itself. I also tried another keyboard thinking maybe the switches were wearing out, but that part hasn’t mattered either. The issue also happens under both X11 and Wayland, and isn’t game specific (does it in FFXIV and in Helldivers 2 for sure, haven’t tried others yet).

To reproduce it is somewhat inconsistent, at least with gameplay. I can dance around on WASD for a while (2-15sec) until it stops moving. I’ve tried a couple of web-based NKRO tests and can’t get it to break there, though.

Environment:
OS: Pop!_OS 22.04 LTS on Kernel 6.9.3
WM/DE: tried with X11 and Wayland in Gnome, and under COSMIC
Keyboards: ZSA Moonlander and a MSFT Natural 4000.
Screens: Dell U3419W and LG 27GR83Q
Perf plan is on performance, and USB is not set to go to sleep when I checked with powertop.

'lsusb' from single display active

Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 26ce:01a2 ASRock LED Controller
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 0bda:4027 Realtek Semiconductor Corp. LG Monitor HP MIC
Bus 001 Device 007: ID 043e:9a39 LG Electronics USA, Inc. LG Monitor Controls
Bus 001 Device 009: ID 3297:1969 ZSA Moonlander Mark I
Bus 001 Device 006: ID 046d:c539 Logitech, Inc. USB Receiver
Bus 001 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 011: ID 0a12:1243 Cambridge Silicon Radio, Ltd Audioengine HD3
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 0e8d:0608 MediaTek Inc. Wireless_Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

'lsusb' when both displays active

Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 26ce:01a2 ASRock LED Controller
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 0bda:4027 Realtek Semiconductor Corp. LG Monitor HP MIC
Bus 001 Device 007: ID 043e:9a39 LG Electronics USA, Inc. LG Monitor Controls
Bus 001 Device 009: ID 3297:1969 ZSA Moonlander Mark I
Bus 001 Device 006: ID 046d:c539 Logitech, Inc. USB Receiver
Bus 001 Device 005: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 011: ID 0a12:1243 Cambridge Silicon Radio, Ltd Audioengine HD3
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 0e8d:0608 MediaTek Inc. Wireless_Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Not sure what else to look at, or even necessarily what to search for to try and figure this out. Most of the search results pull up other multi-monitor issues (adaptive sync not working, scaling issues, refresh rate split being a problem, etc.).

[mihawk90]

Can someone help me read/understand dig output…?

I installed pi-hole on my NAS yesterday cause I wanted to try it out. Set the DNS on my PC (my ISP router doesn’t have any kind of DHCP config outside the IP range), rebooted, and I can tell it’s active:

 nmcli device show | grep DNS
IP4.DNS[1]:                             192.168.0.157
IP4.DNS[2]:                             1.1.1.1
IP4.DNS[3]:                             1.0.0.1
IP6.DNS[1]:                             2a02:810a:ac0:2454:aaa1:59ff:fec0:ab8d
IP6.DNS[2]:                             2606:4700:4700::1111
IP6.DNS[3]:                             2606:4700:4700::1001

192~ is my NAS, the other two Cloudflare of course. I wanted to keep them as a backup in case the pi-hole container has issues or the NAS is dead or… whatever.

Anyway, I grabbed some random domains on pi-hole’s default blocklist, and most of them I could reach (there were some that already redirected or were actually non-existent). So I was wondering what’s happening.

Here’s just one example:

 dig www.psclicks.com

; <<>> DiG 9.18.26 <<>> www.psclicks.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18453
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.psclicks.com.              IN      A

;; ANSWER SECTION:
www.psclicks.com.       159     IN      CNAME   psclicks.com.
psclicks.com.           159     IN      A       15.197.142.173
psclicks.com.           159     IN      A       3.33.152.147

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jun 27 19:16:35 CEST 2024
;; MSG SIZE  rcvd: 91

From what I can tell, it doesn’t tell me which DNS it got a response from… the pi-hole dashboard doesn’t show any requests made either, even though it should be my primary DNS (and is reachable). It’s certainly not a local DNS cache since I have never been on that domain. So… what’s happening?

On a related note I’m not quite sure what this 127.0.0.53 at the bottom is…

[Trooper_ish]

I like to use nslookup to try out different dns servers, because you can change on the fly, and test without committing the change to the OS.

[profdecoy]

The 127.0.0.53 is your local systemd resolved service responding to the request. You can see that by checking /etc/resolv.conf, and using resolvectl will show you more detail on your local config.

For your dig command if you add +trace to it, it’ll show exactly which dns server it used to complete the query and where it got its answer from.

[profdecoy]

You can do that with dig by using dig @<dns server> host.to.look.up

nslookup is convenient, but dig is a pretty powerful tool for troubleshooting dns.

[Trooper_ish]

Then just change the @server each time?

Huh, fair enough, and good to know