EndeavourOS and Zorin OS

[GreyGeek]

By far the best KDE neon forum is this one :-)
Neon and Kubuntu are in fact so similar, 99% of what applies to one, applies to the other.

I also think 99% of GG's "problems" are simply Wine-related. I always found a fresh install of Wine problematic at best.
It doesn't matter if you just copy all your stuff to ~/.wine. The core install will give you plenty of problems on its own.

Well, I'll admit my bias and agree that this IS the best Linux forum on the web. Discussion participants are treated with more mutual respect here than on many of the other forums. I haven't seen a "RTFM" reply on this forum. Our only problem, IMO, is the occasional drive-by shooter ranting about his problems and blaming everything and everyone else for them. I also like that it is family friendly, i.e., vulgarity is usually non-existent or very minimal.

I've come to the same conclusion about wine, but I suspect it's a mix between wine and the newer kernels, in addition to not being able to download KB files from MS servers that are no longer operation, which was a statement in the log file.

During the Neon install procedure I used mc to move massive amounts of data from my @Data subvolume to my home accounts. I saw that because on my first attempt to install neon, after all my data was moved over, I was doing minor clean up chores and installing files and programs not in my Data subvolume. During the last file install I got a failure to install msg claiming I was out of SSD space.

Sure enough, using "btrfs filesystem usage /" showed that the used space almost equaled the allocated space, leaving not enough to install the app. Strangely, I saw no slowdown in system of Dolphin browsing speed before, or after that event took place. I dorked but the only advice I found was to remove a few snapshots to free up room. I hadn't made any snapshots, so I couldn't remove any. I decided to reinstall, since it doesn't take that much time, and to not install so much so fast. That seemed to work. Presently this is how it looks:

~$ sudo btrfs filesystem usage /
[sudo] password for jerry:
Overall:
Device size: 465.75GiB
Device allocated: 112.04GiB
Device unallocated: 353.71GiB
Device missing: 0.00B
Used: 111.21GiB
Free (estimated): 354.28GiB (min: 354.28GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 176.55MiB (used: 0.00B)

Data,single: Size:111.01GiB, Used:110.44GiB (99.49%)
/dev/sda1 111.01GiB

Metadata,single: Size:1.00GiB, Used:786.44MiB (76.80%)
/dev/sda1 1.00GiB

System,single: Size:32.00MiB, Used:16.00KiB (0.05%)
/dev/sda1 32.00MiB

Unallocated:
/dev/sda1 353.71GiB

Using the balance and fstrim commands I got the used data space down to 84% but as you can see it's climbed back up. Kubuntu 20.04 never behaved that way. But, as long as the unallocated space keeps keeps climbing toward the device size I'm not worrying about it.

EDIT:
I do my incremental backups to a second SSD, which contains only snapshots. My script keeps the number of snapshots to 5, adding a new one and deleting the oldest one. In the last three years I have never run a usage, balance or fstrim on that SSD. My first usage run showed 80% of allocated was used. I did the usual incremental balance command for -d and -m and then run fstrim on it. A usage command after the balance and fstrim showed that 99.93% of the allocated space was used, which is losing a LOT of space.

In fact, I believe that btrfs is broken under Neon.

root@jerry-aspirev3771:~# btrfs balance start -dusage=50 /backup
Done, had to relocate 0 out of 107 chunks
root@jerry-aspirev3771:~# btrfs balance start -dusage=60 /backup
Done, had to relocate 0 out of 107 chunks
root@jerry-aspirev3771:~# btrfs balance start -dusage=70 /backup
Done, had to relocate 0 out of 107 chunks
root@jerry-aspirev3771:~# btrfs balance start -dusage=75 /backup
Done, had to relocate 0 out of 107 chunks
root@jerry-aspirev3771:~# btrfs balance start -dusage=80 /backup
ERROR: error during balancing '/backup': No such file or directory
There may be more info in syslog - try dmesg | tail

root@jerry-aspirev3771:~# dmesg | tail
[21418.654676] BTRFS info (device sdc1): balance: start -dusage=60
[21418.654796] BTRFS info (device sdc1): balance: ended with status: 0
[21428.154196] BTRFS info (device sdc1): balance: start -dusage=70
[21428.154310] BTRFS info (device sdc1): balance: ended with status: 0
[21440.840946] BTRFS info (device sdc1): balance: start -dusage=75
[21440.841059] BTRFS info (device sdc1): balance: ended with status: 0
[21452.616948] BTRFS info (device sdc1): balance: start -dusage=80
[21452.617110] BTRFS info (device sdc1): relocating block group 149272133632 flags data
[21459.292824] BTRFS info (device sdc1): found 1801 extents, stage: move data extents
[21459.483804] BTRFS info (device sdc1): balance: ended with status: -2

So BTRFS lost track of /backup.
The drive /backup is on generally ran around 80% usage. Running balance or fstrim on it caused the allocated space to drop considerably.

This is the first time since I begin using BTRFS about 5 years ago that I'm having problems with it.
I'm going to continue to run it and see how things go, but I already know that a reinstall is coming soon.

[Don B. Cilly]

I've come to the same conclusion about wine, but I suspect it's a mix between wine and the newer kernels,

Wine has always been a mess to install. Well, at least for the past few years

[GreyGeek]

I reformatted my /backup SSD and sent a copy of my @202109141730 snapshot to it. Here are the before and after usage statements.

root@jerry-aspirev3771:~# btrfs fi usage /backup
Overall:
Device size: 465.76GiB
Device allocated: 20.00MiB
Device unallocated: 465.74GiB
Device missing: 0.00B
Used: 128.00KiB
Free (estimated): 465.75GiB (min: 465.75GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 3.25MiB (used: 0.00B)

Data,single: Size:8.00MiB, Used:0.00B (0.00%)
/dev/sdc1 8.00MiB

Metadata,single: Size:8.00MiB, Used:112.00KiB (1.37%)
/dev/sdc1 8.00MiB

System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
/dev/sdc1 4.00MiB

Unallocated:
/dev/sdc1 465.74GiB

root@jerry-aspirev3771:~# btrfs send /mnt/snapshots/@202109141730 | btrfs receive /backup
At subvol /mnt/snapshots/@202109141730
At subvol @202109141730

root@jerry-aspirev3771:~# vdir /backup
total 0
drwxr-xr-x 1 root root 236 Sep 14 18:16 @202109141730

root@jerry-aspirev3771:~# btrfs fi usage /backup
Overall:
Device size: 465.76GiB
Device allocated: 91.02GiB
Device unallocated: 374.74GiB
Device missing: 0.00B
Used: 89.80GiB
Free (estimated): 375.49GiB (min: 375.49GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 123.75MiB (used: 0.00B)

Data,single: Size:90.01GiB, Used:89.26GiB (99.17%)
/dev/sdc1 90.01GiB

Metadata,single: Size:1.01GiB, Used:555.23MiB (53.80%)
/dev/sdc1 1.01GiB

System,single: Size:4.00MiB, Used:16.00KiB (0.39%)
/dev/sdc1 4.00MiB

Unallocated:
/dev/sdc1 374.74GiB

After sending a second snapshot to /backup I did another usage on it.

:~# btrfs fi usage /backup/
Overall:
Device size: 465.76GiB
Device allocated: 181.02GiB
Device unallocated: 284.74GiB
Device missing: 0.00B
Used: 179.62GiB
Free (estimated): 285.20GiB (min: 285.20GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 250.31MiB (used: 0.00B)

Data,single: Size:179.01GiB, Used:178.54GiB (99.74%)
/dev/sdc1 179.01GiB

Metadata,single: Size:2.01GiB, Used:1.08GiB (53.94%)
/dev/sdc1 2.01GiB

System,single: Size:4.00MiB, Used:48.00KiB (1.17%)
/dev/sdc1 4.00MiB

Unallocated:
/dev/sdc1 284.74GiB

BTRFS's "Used" is staying just under the "Device Allocated". I never noticed this problem with Kubuntu 20.04, and on Neon I was stunned to see the "out of space" msg while attempting to save a file. Just a wild guess: It's as if in some cases BTRFS miscalculates the amount of space between "Device Allocated" and "Used", call it "Delta_AU", and compares it to the size of the file that's going to be saved. If the file size is a few bytes larger than Delta_AU but BTRFS has miscalculated it to be smaller then an "out of space" error would occur.

I was bored but this is interesting

[Beerislife]

I got my 11? year old ThinkPad running Kubuntu 20.04 LTS backed up and made a Live thumb drive of Endeavour and booted it up. Nice, I thought, but I'm not a fan of Xfce and seeing as I have nothing else to do, I installed the KDE version.

Sigh...

That machine may be old and only have a dual core i5 CPU (With 8Gb RAM and a Crucial MX500 SSD) but any other OS runs as smooth as silk on it! Endeavour? You could see Neofetch writing each line in Konsole! Moving windows around was slow too!

I wasn't in the mood to troubleshoot it or try a different DE so I found a Neon ISO I had and installed that. That's it, no more distro hopping for me!

[Snowhog]

If it's possible to increase the RAM, you'll be even happier.

[Beerislife]

If it's possible to increase the RAM, you'll be even happier.

Max is 8Gb on that old machine. Right now it's my test-bed for trying different distros and desktops. When this State Of Emergency is eased and I can open up the bar, it will go back to being my media player. 8Gb is fine for what it's used for.

It's only a matter of time before it dies. When that happens it will be replaced with a Raspberry Pi.

I don't really want to open up again though, I want to retire to Thailand...

[oshunluvr]

Jerry, maybe something else is amiss with your BTRFS? @here: btrfs-progs 5.4.1-2, kernel 5.11.0-34-generic

[FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt fi us /mnt/root_backup/[/COLOR]
Overall:
    Device size:                 931.50GiB
    Device allocated:            429.02GiB
    Device unallocated:          502.48GiB
    Device missing:                  0.00B
    Used:                        395.85GiB
    Free (estimated):            528.32GiB      (min: 277.08GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,single: Size:417.01GiB, Used:391.17GiB (93.80%)
   /dev/sdd2     417.01GiB

Metadata,DUP: Size:6.00GiB, Used:2.34GiB (39.05%)
   /dev/sdd2      12.00GiB

System,DUP: Size:8.00MiB, Used:80.00KiB (0.98%)
   /dev/sdd2      16.00MiB

Unallocated:
   /dev/sdd2     502.48GiB
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt ba start -dusage=50 /mnt/root_backup/[/COLOR]
Done, had to relocate 16 out of 425 chunks
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt ba start -dusage=60 /mnt/root_backup/  [/COLOR]
Done, had to relocate 3 out of 409 chunks
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt ba start -dusage=70 /mnt/root_backup/  [/COLOR]
Done, had to relocate 4 out of 406 chunks
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt ba start -dusage=80 /mnt/root_backup/
 [/COLOR]​[/FONT][FONT=monospace][COLOR=#000000]Done, had to relocate 3 out of 402 chunks[/COLOR]
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt ba start -dusage=90 /mnt/root_backup/  [/COLOR]
Done, had to relocate 1 out of 400 chunks
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ bt fi us /mnt/root_backup/                 [/COLOR]
Overall:
    Device size:                 931.50GiB
    Device allocated:            404.02GiB
    Device unallocated:          527.48GiB
    Device missing:                  0.00B
    Used:                        395.83GiB
    Free (estimated):            528.33GiB      (min: 264.59GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,single: Size:392.01GiB, Used:391.15GiB (99.78%)
   /dev/sdd2     392.01GiB

Metadata,DUP: Size:6.00GiB, Used:2.34GiB (38.96%)
   /dev/sdd2      12.00GiB

System,DUP: Size:8.00MiB, Used:80.00KiB (0.98%)
   /dev/sdd2      16.00MiB

Unallocated:
   /dev/sdd2     527.48GiB
[COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#54FFFF][B]~[/B][/COLOR][COLOR=#000000]$ [/COLOR]
[/FONT]

note that "bt" is an alias for "sudo btrfs" and it's set in sudoers so no password prompt.

[GreyGeek]

I'm using the same versions of btrfs-progs and kernel. My first install of Neon, which I checksummed the iso, resulted in getting the out of space error. I redid the download and checksum and reinstalled. Smartdrive found no problem with the SSD. It's behaved normally on the second attempt. Probably a stupid something I did during the first install. I installed Neon 5.22.5 as a VM on qemu-kvm and hammered it pretty well, and it stood up, do I deleted the VM.

The only problem I have is that none of the wine tools for the i386 architecture work against the exe's I had installed and running under Kubuntu 20.04, but I can read EKG's directly so not having a printout capability is a minor inconvenience. I documented my problems installing EAST_EKG and SpaceEngine098 in another post.

[Beerislife]

T'was a national holiday today and a bit of an Indian summer (31C daytime temp!) so I decided to put on the air-conditioner and play around with a couple of distros on my ThinkPad...

First up was Manjaro Deepin. I really like the Deepin DE, it's so bootaful!

The live ISO was great (Tried full and minimal ISO's) Decided to install the full version. Meh, too much stuff that I don't need! Should have gone with minimal and installed what I wanted.

After installation, hit the main menu and it took ages for the menu icons to populate on the Application Dashboard type menu.

Forget it. This is almost as bad as Endeavour KDE. Maybe my system doesn't like Arch!

Next up Was UbuntuDDE...

It was a nightmare connecting to my WiFi but in the end it stuck. Way too many apps that I don't need. I'd spend half the evening removing stuff!

Installed it anyway and rebooted and never even got to the desktop, kwin-x11 just wasn't having any of it! It wasn't even worth my time looking for a fix!

Back to KDE Neon, that just works...

Let's see how I feel tomorrow!