Mikeserv Support Forum

I've had CatchyOS installed on my main machine for two months now, and I've found that I'm spending more time in it than in vanilla Arch. I only have MATE and Cosmic DE's installed (mostly using MATE at this time). I like Plasma, which is what I have in vanilla Arch, but I also like the simplicity of these smaller DE's while still looking good, and while still having full functionality. And not a single crash in MATE, which is a lot more than I can say about Plasma.

You know I agree. Simplicity is what I like. I even use XFCE more like a window manager than a DE, I don't build the shit I don't like (e.g. Thunar... that bites the weenie) or its atrocious power manager.

Plasma is more of a "demo" to me than something I'd use for doing work or playing games. "Oooh, look how nice".

Have you been playing games in CachyOS?

Not yet but I plan to install it on my game machine soon. I could also get Steam etc going here on my main machine though my game machine has a stronger video card.

I booted into MATE in Arch (vanilla Arch originally with just Plasma) and configured MATE

That's a super nice wallpaper.

Does that clock overlay on your desktop like that all the time? It also looks good (nice font).

It does, as long as Variety is running, I have it set to start with my session.

Here's what the clock settings look like:

And here's that wallpaper (it came from unsplash.com

Thanks, I saved the wallpaper. So that Variety thing is a wallpaper switcher/configuration overlay.

It was hard to find with a name like that

https://github.com/varietywalls/variety

I could have this, but it does look a bit needy for my tastes

I bet you got a variety of results lol! Yeah it can pull from different remote sources, local sources, and/or both.

I booted into Arch tonight and this was my wallpaper. When there's one you want to see again you can save it to the favorites folder in the Variety menu.

That's a nice one too, a lot of contrast between pink and black.

In Vanilla Arch my initramfs fallback images for two kernels had bloated up for some reason, around 200 MB each and running me short on space in my 512 MB boot partition. So I disabled and removed the fallback images. Not sure why that was happening.

That's some silly shit. Those are large because they have all drivers in them, but there has to be something wrong for them to get that big. You won't need those anyway.

Myself, I utterly refuse to have that bollocks. I'll always tailor a (mostly) static kernel to my machine.

I noticed the Arch website has been very slow to respond the last several days.

Maybe it was launched by a disgruntled Manjaro user who asked for help on the Arch forums

I heard about that, what a petty thing to do, to DOS a community Linux distro's site. It probably is some butthurt pimple wizard.

It hasn't affected me, since I use mirrors for pacman, and git for my PKGBUILDs

After updating vanilla Arch today the zen kernel wouldn't boot, it can't find the modules or the root drive. From someone else's post about the same problem:

Warning: /lib/modules/6.16.3-zen1-1-zen/modules.devname not found - ignoring (I added my kernel version since it was an old post)

And then it timed out trying to mount it's root partition. But it boots just fine with the CatchyOS kernel I dropped in earlier, and with the regular Arch 6.16.3 kernel.
I checked and the modules are there for the zen kernel. Not a big deal since I have working kernels but I'm curious what went wrong, it was working with the previous zen kernel.

I swear I replied to this somewhere (not in the networking thread?). What I said was it probably was something wrong with the initramfs image, either that or UUID values somehow changed.

I played around with the issue with the zen kernel again, I removed the kernel along with the initramfs image, then reinstalled it (different kernel version), but same thing happened.

At first after reinstalling it I forgot to run grub-mkconfig -o /boot/grub/grub.cfg before rebooting, with the result that I saw my first Linux BSOD lol!

That looks ridiculous. I have that shit turned off in my kernels.

It gives the intelligible info though, "unable to mount rootfs", at least.

Something in today's Arch updates (gtk4 stuff and related) broke Firefox styling. I use "system" for the theme, which is my beloved "plasma fire" gtk+ style. Now Firefox is all default white.

This is unacceptable... to the point that if I can't fix this in the next half hour, Arch is GONE. Today!

P.S. Well, I fixed it in 10 seconds. My first suspicion was correct... it pulled in xdg-desktop-portal shit as new (non-optional) dependencies for gtk4. I removed them with pacman -Rdd (forced) and Firefox is back to normal. This means that I'm going to have to see if I can compile gtk4 and disable xdg-desktop-portal-gtk. Great... more hated packages I have to maintain.

What's sick about that portal shit is, it's for flatpak, as a means of accessing desktop environment resources from outside the container. I hate containers, I don't use them and it pisses me off that I have to have this crap as dependencies. Another one is Appstream, a dependency for libadwaita, I should see if I can compile around that too.

If I could ditch Zenity (like ncurses dialogs for gtk+) and Pavucontrol (a pulseaudio volume control and/or volume control back end) I could ditch gtk4 (which I can't stand).

P.P.S. Easy peasy... just have xdg-desktop-portal-gtk and xdg-desktop-portal gone (and take it out of the depends array in the PKGBUILD) and compile gtk4. Now, I could ditch Zenity (it's an optional dependency, some operations just won't display a progress bar or something, for example Steam and Lutris while unpacking runtimes etc.) but I need pavucontrol. Maybe I can compile THAT without gtk.

No, pavucontrol requires gtk+4 but I found a fork called "pavoldcontrol" and fixed up a PKGBUILD for it instead, that still uses gtk+3 and it works (back end for my XFCE volume control, xfce4-pulseaudio-plugin)

pavoldcontrol
https://github.com/ItsZariep/pavoldcontrol

Also, I built zenity 3.44.2 which is an older version that uses gtk+3. I had tried to do that before, but I didn't go back far enough (I had looked at 3.62.x and it was gtk4 too so I gave up).

Now my life is once again gtk+4 free. I had kept that off my system for a long time, but it became a hard dep. Also gone is libadwaita which I utterly detest (though I had a special "libadwaita-without-adwaita" that made it easier to override). Another corresponding, dependent package removed is gtkmm4 (the c++ interface to gtk4). That poxy appstream is gone now too (hard dep for libadwaita)

Another thing I had to ditch was that nice mission-center program though, but I wasn't using it anyway. I prefer the simpler btop. That's unfortunate collateral damage, but fuck anything that uses gtk4 and libadwaita dictatorial shitware.

Music to my eyes:
This is what happens when I get pissed off.

I just got a Steam client update, and during its installation of runtimes etc. it was so nice to see the little zenity progress bar dialog in my beloved style again (black dialog with orange gradient bar) instead of that white gtk4 eye poison. I got to see the fruits of my labour this very day

The end result was the complete opposite of what Arch tried to do

I added the CachyOS repositories to vanilla Arch, so I'm running their kernel and their versions of some other stuff. It still identifies as Arch, but I bet I'd be ostracized on the Arch forums if I ever asked a question there after revealing what I did to a once pristine install of Arch originally installed the Arch way

That would be utterly blasphemous to some of them

You might as well have some better optimized packages (especially kernel).

I don't know when, as I haven't used this in several months, but somehow, Arch broke my virt-manager/KVM networking. Unable to start the default NAT based networking, even though it was set to be active. It was (always) working perfectly. I have all the shit, I know what I'm doing and I couldn't for the life of me figure it out. I wasted my whole afternoon (when I should have gone out and done some things I have to do). I heard tell it was because of dnsmasq, but I couldn't downgrade that because older versions won't compile against newer system headers, so I can't test that (unlikely) theory.

Finally I gave up on it and used bridged networking, which isn't as much tomfoolery (it's a "real" network that gets DHCP from my router). I had to set up a bridge for that, but I don't want it permanent... I don't actually use this shit very often. All I wanted to do was boot up my Windows VM to test something today.

Anyway, I just manually set up a script to use the ip utils to temporarily create a bridge and append the route (and remove the IP address from eth0) so I can still use my network on the host (my first attempt worked for the guest, but I lost my route on the host lol)

The eth0 interface is already up, so I don't have to bring it up.
The reason I have to load kvm_intel manually is because I have the modules blacklisted so they won't load automatically (again, I don't use this shit very often and kvm_intel and kvm are huge kernel modules) and I might as well just stick that in this script. I might as well start the libvirt service there too (I keep it disabled).

Note: The reason my interface is eth0 is because I have defied systemd and set up my own network manually using netctl (and mask out 80-net-setup-link.rules and use my own udev rules). I just hate that enp0s5 type nomenclature. Anyone following this needs to use the correct device on their system.

This will all be gone on reboot, as I intend. I add intel_iommu=on to tne kernel command line manually from the grub menu when I want to boot with it, so that will be gone on reboot too. I don't want any of this crap even in the picture, on what is mainly a system for gaming. My frugal, stubborn ways do create work for myself, though.

Now, in the VM configuration I use Bridged for the network type, and br0 as the bridge device. I'm still using the accelerated virtio adapter (default is e1000). I really should have been using bridged all along, instead of that NAT kludge anyway.

It all works as intended now, but I'm still not getting what I wanted done because of Windows Update now. It's getting 25H2

I haven't used virtual machines in a very long time, I used to use them all the time. I had a lot of trouble getting a bridge working in KVM. I did it in Proxmox, which also uses KVM but has a GUI interface for that, way back years ago when I was running my work Windows VM from Proxmox. I miss the days of having control over my work environment.

I don't think I have 25H2 on my work laptop yet, I heard it's a bad one

I wasn't in there long enough to hate 25H2. On the "Cumulative" update before 25H2, after the reboot Microsoft went through the "Hi, we're taking over your system" routine and tried hard to get me to use a Microsoft account. For that, submitting no username and password then going back, led to a "skip for now" but only when I did that. 25H2 didn't bother me after the reboot at all, straight to desktop.

I just grabbed some stuff from the host with sftp, extracted archives and tested the program. Bollocks... then shut down

Good old Arch and their fucking disabling of static libraries in everything. I can't build a static node.js on Arch anymore because there's no libatomic.a. They go out of their way to prevent the install of static libraries, even to the point of deleting static libraries from the pkgdir destinations.

Sigh... I'm going to Crux to compile that where I don't have a crippled gcc installation (that's where I built it last time so it could run on both systems). Thing is, I compile node.js with llvm/clang but I think the SSL component being compiled with node uses functions in libatomic.

Next Arch gcc build (that's too time consuming for right now, just for this... I just did one recently) is getting static libraries... fuck this silly "static linking bad" ideology. It's not clever at all. Sometimes it's what you want to do, so stupid shit doesn't get broken by the distro. I'm going to have to change the way the gcc PKGBUILD installs gcc. I think I'll just do a monolithic package instead of splitting it out into gcc-libs. You know, "make infuckingstall" instead of crap like "make -C $CHOST/libgcc DESTDIR="$pkgdir" install-shared" and "make -C $CHOST/$lib DESTDIR="$pkgdir" install-toolexeclibLTLIBRARIES" and take out any "rm" commands that nuke .a files.

I'm glad I was paying attention today... Arch is trying to shove QT6 packages down my throat. A new dependency for vulkan-extra-tools

Seriously... qt6 is a dependency for vulkan tools now. That is silly, I would not allow such a dependency on something like that (that would be a good reason to separate that). Force everybody to have qt6 just so they can have vkconfig. I haven't decided whether I need vkconfig (certainly not vkconfig-gui), as I've never used it, or whether I'm going to build it myself without the QT6 dep.

I only have a few things that use QT5 (some compiled to use that instead) as I dislike QT6 and don't let it get on here. Same with GTK4.

LOL... I don't have vkconfig now. The currently installed vulkan-extra-tools package basically has nothing in it
You have to really look closely to see just how silly Arch Linux is, sometimes.

I'm going to just remove the package and if I want vkconfig I'll just compile it standalone.

Earlier in the thread I was having occasional Grub boot problems where I'd get the menu, hit enter to boot my kernel and it would just go dead (not load the kernel) and I have to hard boot.

Well, that stopped happening for a long time. It started again, with Arch upgrading to a grub-2.14-rc1 checkout (I scoffed, but upgraded anyway). It happened the first time booting with it even. It persisted through the next grub update (still 2.14-rc1 but a newer checkout) too. It wasn't happening that often, but it happened again tonight when I got home, starting from a powered off state, even. That pissed me off enough now.

So fuck that, I'm going back to the last one before the 2.14-rc1 builds. This one "2.12.r418.g6b5c671d-2" (I checked out that tag for the PKGBUILD)

I rolled it up adding grub to the conflicts=, provides=,replaces= lines and gave it a custom name so it won't show up in the ignore list and Arch will never touch it... grub-cust-2:2.12.r418.g6b5c671d-2-x86_64.pkg.tar.zst

and of course grub-install after installing the package.

There is NO reason to update a working grub (I don't care about boot loader "security"), it's not like it has library dependencies, just standard C and assembly.

Now we'll see again if it happens again.

Several years ago Arch broke the boot loader for a lot of users after pushing out a new grub version, I don't remember if it was an rc but the boot loader is one thing that should be properly tested before pushing it out. EndeavourOS (Arch-based) switched their default boot loader to systemd-boot because of that. I added it to my ignore list and left it there.