Arch Linux 2024

[Grogan]

I found an article at Tom's complaining about the AVX-512 thing:
https://www.tomshardware.com/news/intel ... in-silicon

Intel's support for AVX-512 instructions with its Alder Lake processors has been a confusing affair. The company initially claimed the feature wouldn't work on its new 12th Gen processors and then backtracked when motherboard vendors found multiple workarounds to enable the commands. After a bit of cat and mouse with motherboard vendors that built new firmware to enable the feature despite Intel's attempts at disabling it, the company has finally decided to deploy the nuclear option and fuse off AVX-512 support entirely inside newer revisions of the Alder Lake chips.

The reason would be that they want you to buy a big expensive Xeon if you want 512 bit vector instructions, not that it wouldn't work on the cpu architecture as they claimed (vendors were turning it on with firmware lol) so they permanently sabotaged it on them going forward.

-------------------------------

Related, I found a cool awk script to determine which x86_64 sub arch levels are supported. I didn't need it (I can look myself and already knew that) but I like clever little scripts

Code: Select all

#!/usr/bin/awk -f

BEGIN {
    while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
    if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
    if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
    if (level == 2 && /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3
    if (level == 3 && /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
    if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
    exit 1
}

That would run if set executable, but I just did "awk -f filename" to run it.

Code: Select all

CPU supports x86-64-v3

[Grogan]

Fascinating stuff. A bootstrap LTO build of gcc isn't helped a lot by -j24 because it can't just go ahead and compile all the objects (I'd think a plain build could do more in parallel). OK, that's boring, but it gave me a chance to observe Turbo Boost behaviour on a workload where cores are idle. It can go up to 5.2 GHz under those conditions:

Code: Select all

[grogan@nicetry ~]$ cat /proc/cpuinfo | grep MHz
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 5143.098
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 3945.585
cpu MHz		: 3088.444
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000

[Grogan]

Well, I can say the -march=alderlake wasn't good for some 32 bit parts of Wine (or at least in my Proton-TKG build... I also built a system wine 9.4 (TGK) that I haven't tested yet, I might not bother lol)

The Ubisoft client was crashing out on me, wouldn't start. I tried some other games and they were fine. I went back to my previous Proton-TKG (nehalem) and the Ubisoft client worked fine again.

Then I noticed that ubibooby was in c:\program files(x86) and tested another 32 bit game that was working just last night, and blammo.

So that wasn't such a good idea. I'm going to have to recompile that.

[Grogan]

That turned out to be only the 32 bit build of DXVK that broke on -march=alderlake. It was easier to isolate that with my system wine and DXVK for Lutris.

So I built my Proton-TKG with -march=alderlake everywhere but that, where I used "-march=nehalem -mtune=alderlake" (nehalem always has worked) and now the Ubisoft client in Steam works again too. That was a good clue, that the client was 32 bit (everything like that uses directx on windows at the back end... the embedded browsers generally use Angle which translates EGL to directx)

[Zema Bus]

Looks like I have a favorable revision of Alderlake

Code: Select all

CPU supports x86-64-v3

I haven't run any games on it yet but I'll be doing that soon. In all the gaming benchmarks I've seen the Ryzen 7 5800X3D (which is what I have in my other machine next to me) comes out on top of the 12900KF in most games probably mainly because of it's 96 MB L3 cache (the 12900KF comes out ahead of the Ryzen 9 5900X in the gaming benchmarks) but I want to test that myself with the same card.

[Zema Bus]

I did a new Arch install last night on my main machine, I did it "the Arch way". I ssh'd into it from my other machine so I could copy paste some stuff along the way. I didn't bother trying the script, it only works half the time. Initially I installed Mate as the only DE since it's compatible with other DE's including Plasma, and I'll be doing some gaming on this machine, I've found Mate to be pretty gaming friendly. I have more work to do on it today. I may do Slackware-Current today too, then once they're both the way I want them I'll nuke the old installs.

[Grogan]

Yeah, that's the best way to install Arch. It only takes maybe half an hour to get the base system up that way. It's easy to forget stuff if you get in a rush though. I didn't even look at the instructions for this install (I had just done one a few hours prior) and forgot to run localegen. Perl and a bunch of software were all complaining that my locale was invalid "fuck off, I set the variables". What I forgot was the actual en_US.utf8 locale. Two ways to fix that... simply reinstall the glibc package. It will generate a locale (it doesn't during the install, because that stuff is installed by pacstrap, not the package manager). Or, just install the glibc-locales package. What I did was just manually extract the glibc-locales package and copy the en_US.utf8 directory to /usr/lib/locale. Of course now I have my own glibc package and it installed the locale.

I find Arch pretty easy once the base system is up, with the package groups and dependencies pulling things in and all. (but if the Arch install is actually for me to use, I have a lot of shit I'd want to do)

[Grogan]

Well, everything is alive and well but I had trouble starting Arch, or so I thought. It was just going to a black screen with a blinking cursor (mode switching first, so I knew it was actually "booting" enough to load modules and firmware). I'm all WTF, because nothing should have changed. The nvme0 and nvme1 devices didn't shift. My LFS system started up fine (after I re-corrected the nvme0 vs nvme1 changes I didn't need to make) and didn't miss a beat.

What was ACTUALLY happening, was that I had it booting in "quiet" mode, and systemd was taking a 1:30 to time out on a start job, the network. (and I wasn't waiting a minute and a half, but aborting with ctrl-alt-del)

You see, that stupid "enp5s0" shit bit me in the ass again! I meant to change that all over to eth0, but it's a pain in the ass and it was working fine.

Removing the NVME drive from the PCI-E slot (M.2 adapter card) and installing it on the M.2 slot on the motherboard, shifted the device numbers on the PCI-E bus. Therefore, enp5s0 wasn't that anymore.

It took me a a while to remember all the places I have to change enp5s0 to eth0 (and mask out Arch's udev rule in /usr/lib/udev/rules.d and replace it with mine to change the device to eth0 which is the real kernel device anyway that gets mapped to the other)

But now, this will never happen to me again. What a dumb assed thing, that nomenclature. It's way easier to just change a MAC address if you change adapters or something than when bus device numbering changes.

[Grogan]

I forgot to install acpid, Arch doesn't install that itself. (should check... install and "systemctl enable acpid.service" if you don't have it)

I went to test a power button shutdown and it didn't work. I'm not sure why else I should care about acpid personally (I do want acpi power button shutdown to work for sure, it can save you from a bad shutdown if all that's screwed up are your input devices and display etc.) as I don't really use much power management, but xorg also complains in the log if it can't connect to the acpid socket, so it likes it for something. It doesn't seem necessary/mandatory for anything though.

[Zema Bus]

Just got it installed and running on both machines.

[Grogan]

I'm glad I noticed, then. (I wasn't sure if maybe some KDE power manager might have pulled that in for you or not)

The default should be to intercept and do a shutdown command, HOWEVER, I have seen "power managers" override that. XFCE power manager for one (I removed that, smeagol hates it)

Check in your desktop environment's control center to see if there are settings for any of that behaviour, if it has any kind of power manager. Disable if you can, or at least make sure the override is going to do the right thing. (I hate desktop environment power managers... The X server already does the right thing for the display in absence of such overrides and I don't want a DE messing with anything else)

I still think you should have acpid, despite that caution. I don't think a distro's acpid is configured to do much out of the box. For the power button purpose, that's something you'll probably need more when your graphical environment is dead in the water or something. Like, for example, if a game malfunctions and hurts your session in a bad way

[Grogan]

Heh... I went to install xpdf today and noticed that Arch links theirs against QT6. I don't want any of my software dependent on that (I don't have it installed) so I went to grab the PKGBUILD. There, I noticed they are applying part of a debianal patchset. Just the patch that wraps enforcement of document permissions around #ifdef's. Just that, not the part that actually defines ENFORCE_PERMISSIONS. At first I was all "WHAT? I want that about as much as diarrhoea in a spacesuit" but then I grepped for the definition in the source headers and stuff and there's nothing that's ever going to define it. So they are essentially disabling the enforcement if nothing sets it (the only behaviour in the program was, previously, to enforce it)

Anyway, for a QT5 build of xpdf I'm all good according to the CMake config files... I just have to not have QT6 installed (and change the deps in the PKBBUILD) and it will build against QT5, which I prefer and have configured the way I like it (non-kde).

[Grogan]

Arch has decided to change the default vm.max_map_count to 1048576 (which is far lower than my value lol)

If you have already set one, make sure it overrides the default in /usr/lib/sysctl.d. One would think that simply putting files in /etc/sysctl.d would do that, since it's the one that's processed first as overrides, but not so. The priority gets processed first regardless of the directory. Therefore, /usr/lib/sysctl.d/10-arch.conf would get processed after something 01-filename.conf. Unless the files are the same name, just having them in /etc/sysctl.d may not do what you want.

For example, I'm fine because I named my file where I put sysctl commands /etc/sysctl.d/99-swappiness.conf. It will get processed last because of the 99 and change whatever values that may be set in /usr/lib/sysctl conf files.

[Grogan]

I just got the "filesystem" package that made this change in /usr/lib/sysctl.d and I rebooted.

I can verify that it's not fucking with any of my values with the output of: (or I could pipe the results through grep etc.)

Code: Select all

[grogan@nicetry ~]$ sysctl -a
abi.vsyscall32 = 1
debug.exception-trace = 1
dev.hpet.max-user-freq = 64
dev.tty.ldisc_autoload = 1
dev.tty.legacy_tiocsti = 0
fs.aio-max-nr = 65536
fs.aio-nr = 0
fs.binfmt_misc.DOSWin = enabled
fs.binfmt_misc.DOSWin = interpreter /usr/bin/wine

.... snipping a long list of default values of kernel parameters...

vm.max_map_count = 2147483642
... snip...
vm.swappiness = 10
...snip

My directives are processed last in the /etc/sysctl.d/99-filename.conf

[Grogan]

I got around to getting my Trinity stuff working today. I had already copied it over (and the configs from grogan) but just had to set some environment variables and ldconfig paths (I have it in a non system location, /opt/trinity and /opt/tqt3 for its qt). It's one of those things where every time I thought to do it, the old PC wasn't powered on and "OK, next time" and I couldn't remember the variables offhand (TQTDIR and stuff).

So that means I have my preferred PDF viewer (the KDE 3 version of kpdf), my hex editor (khexedit) AND most importantly, my fat ladies solitaire game

trinitykpat.jpg (98.78 KiB) Viewed 326 times

It's no problem to run these applications in other environments because as soon as the last thing closes, all the KDE daemons and shit go away.

[Grogan]

I just tried that "archinstall" script that's in the ISO's now.

It's pretty bad... anything other than just letting it take the disk "best guess partitioning layout" or some such wording, fails with a bunch of python errors, it doesn't look like it actually created the second partition and didn't format, and couldn't mount. I even created them beforehand with fdisk before running archinstall and all I did was go in to manual partitioning and assign the mount points. Still "missing superblock, wrong fs type, missing codepage..." some mount error occurred.

All it will do is use swap in zram, there are no facilities for creating and using a swap partition or any other kind of swap. That's got to be the most retarded spinning of wheels I've ever seen. Putting swap in ram mostly defeats the purpose of freeing up pages, and adds compression overhead to it if you actually use it. Write it out to swap on disk and forget about it. (most common use of swap nowadays is more likely to free up anonymous pages that didn't get freed when an application terminated)

So that's not really viable for Saturday either. I can't do that on a real system where I can't lose data.

It did let me choose grub though, not just systemd-boot.

So now I have nothing and I must pacman everything. But we'll get a better system up than that manjaroo poo here for testing a Linux guest with Plasma 6

[Grogan]

Oh, how fruity

(my nephew won't like this... lol)

fruityarch.jpg (190.97 KiB) Viewed 76 times

[Zema Bus]

lol!

I'm surprised to hear Manjaro is still on Plasma 5. Slackware-Current is still on Plasma 5, but that's not surprising considering how long he stayed with Plasma 4

[Grogan]

Well, Slackware gets a pass for that stuff.

1) It's not piggybacking on Arch. Manjaro doesn't actually DO a lot, but build Arch packages. They have some of their own front ends (e.g. that MHWD) and do build some packages somewhat differently, but most of it is Arch. Their installer is just that Calamares thing, they didn't make it and they already have the pacman packaging system and dev environment already worked out.

2) Slackware is one man that stubbornly does everything himself. (I understand that... it's his project and he doesn't want to have to owe anybody. So he doesn't have to concede to them etc.)

The hoops he jumped through to adapt Slackware to Plasma 5... it took years for him to work that out and be OK with it (even though Alien Bob did much of the ground work, his big honking workarounds are fine for him, but it's still not appropriate to just blast into Slackware). I'm sorry to say it ruined Slackware though, it's now too complex of a system for its simplicity, turning it into an all-or-nothing monolith for most people. For me it's no longer worth fighting with to have things my way.

[Grogan]

Well, I've got a pretty versatile Ventoy boot stick now. It's the (fast, $100) Corsair 250 Gb one. I actually may give him Manjaro tomorrow, he won't know about Plasma 6 anyway and 5 was probably better anyway, I was just mad because it was 6 that I wanted to see. The installer may not crash when manual partitioning is selected on a different (or real) system. I'd also consider kubuntu for him, though I do not like that prospect. Buntardo is probably the one he'd get the most help/acknowledgement of. I don't think he cares too much about gaming on Linux at this time (not when he has a Windows setup) though I'd prefer to see him with a good environment for it. I'd also prefer to see him with a good dev environment (which Manjaroo does have) so he can realize what power that grants.

archlinux-2024.04.01-x86_64.iso
manjaro-kde-23.1.4-240406-linux66.iso
kubuntu-24.04-desktop-amd64.iso
Win11_23H2_English_x64v2.iso

I have room for maybe 1 more (~4Gb free)

I have an 18G partition for boot ISOs and the rest of the disk (except for a 32M EFI partition) is a 220G exfat for normal thumb drive use. It's the fastest sneakernet solution I've ever had (~400 Mb/sec under the right conditions)

[Zema Bus]

Plasma 6 is still not nearly as stable as Plasma 5 anyway, it often crashes when I merely click on a launcher. If he's not going to do any gaming on Linux then Debian may be a better option than Ubuntu. Debian is pretty good these days and with none of of the Ubuntu nonsense, though it will get crusty after a few years. But yeah he'd find more online help for Ubuntu.

I overlooked your earlier post - yeah the Arch install script only seems to work about 40% of the time. I didn't even bother with it for my current Arch install, I just did it "the Arch way" via ssh from my other machine.

[Grogan]

I haven't had any crashy behaviour with Plasma 6 yet, but if I set Autohide on the panel, it goes away and never comes back. I see a bit of that faint glow effect (one of the compositor desktop effects) at the bottom screen edge but the panel is off screen and can't be actuated. I can turn off that panel float (that looks stupid) but can't use autohide. The only way to get at the panel controls is by right clicking on the panel, too ("edit mode"). I have to delete plasmashellrc to get it back. That's a piss poor disconnect, right there.

Hell no, the things that archinstall script does would not be happening on my machine (or any real one for that matter). I was just looking for a shortcut (mostly for my nephew's system), but it's not viable. Too inflexible and the partitioning facility is retarded (less user friendly than fdisk too lol!) even if it doesn't bomb out. At least it allows grub now though, it used to only set up systemd-boot. It DID serve the purpose of getting an arch install up quickly in a VM to play with Plasma though.

The safest way to partition, when you don't want to lose data, is manually with fdisk while knowing what you're doing. With fuzzy things like those partitioning wizards in installers, knowing shit won't necessarily help you when they fail to do what you intend. Things like the Ubuntu desktop installer force you to install a boot loader too (though there is still a text based installer I think)

I'm leaning heavily towards stopping at a computer store and buying him a SATA SSD for Linux. He's intending to put it on his mechanical storage drive. I won't have to touch any others that way, he can just go into the bios and change boot drives or use the boot override. I hate to spend more money, but I also hate doing work lol

[Grogan]

Yep... I found a 1 TB Verbatim SSD (SATA) for $99 which isn't bad for hopping in the car and going to a local shop. They had Kingston too, but they can fuck off forever for their self destructing firmware. I wouldn't trust them for a $10 thumb drive. They make crap RAM too.

That will be more practical than carving out space on his mechanical storage drive and I'm not going to have to touch his other drives at all this way (it'll have its own EFI boot partition)