Arch Linux 2024

[Zema Bus]

Another thread we don't have yet here lol!

Thinking of doing a new Arch install on my main system, my current one was just blasted on using a Calamares installer by a guy who does a good job and all but I was originally wanting a pure Arch install but ended up fighting a bad drive resulting in nothing booting. By the time I sorted it out and replaced the drive it was past my bedtime and I was tired so I took the quick and easy route before going to bed.

[Grogan]

Yeah, I need a place to bitch about Arch

What kind of drive... don't tell me it was a NVME that failed again. (just when I'm starting to have confidence in the technology lol). Well, I think the problems you had were faulty firmware that had fault triggers.

[Zema Bus]

It was a sata drive I forget the brand, other than that it wasn't a Kingston for a change, I had already learned that lesson lol!

[Grogan]

Good. Well, not good that it had you chasing your tail, but good that it wasn't something current.

I've never set up Arch on EFI before, I would imagine I'll create a FAT32 partition along with my Linux ones. I'll use Grub, installed to the EFI partition and then the kernels will just go in /boot like normal and I should be able to defang that grub autoconfig and go with a hand edited grub.cfg like normal.

[Grogan]

Code: Select all

resolving dependencies...
looking for conflicting packages...
:: mkinitcpio and systemd are in conflict. Remove systemd? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: mkinitcpio and systemd are in conflict (systemd<255.4-2)

Umm yeah, sure Arch, I'll get right on that. (It's because systemd is in my ignore list and not being installed at the same time), I patch and build my own but what a stupid, stupid resolution to suggest). For me, I'm force mkinitcpio for now to get through my updates, and then I'll compile systemd. I don't generate initramfs at all anymore anyway, I don't have a distro kernel installed.

Systemd is no longer compatible with the old mkinitcpio, and the new mkinitcpio is not compatible with the old systemd. I hate you, I hate you, I hate you.

P.S. Worse... it won't let me force this conflict. Pacman is ignoring -Sdd and refusing to install mkinitcpio, contrary to its stated behaviour. -dd is supposed to ignore ALL dependency checks, including conflicts. So instead I'm going to have to add mkinitcpio to the IgnorePkg list, get my updates, edit the rigid, version specific dependency in the systemd PKGBUILD so it's just "mkinitcpio", build systemd and then upgrade mkinitcpio.

P.P.S. No, not even that. There's a whole stack of circular dependencies involved with mkinitcpio here. How ridiculous, it's just a shell script, not a library dependency.

Tired of fighting with Arch,

[Grogan]

Every solution I try here is just fuckery. I'm editing PKGBUILDs to remove conflict lines and building them, forcing the removal of stupid shit like cryptsetup and mdadm that I don't use but are artificial dependencies for other things, and mkinitcpio STILL cannot be upgraded or removed because of file conflicts with systemd. I have to manually delete systemd's mkinitcpio hooks to be able to install my mkinitcpio package. That's it now, I got that and put back all the shit I removed so as not to break dependencies in the package database. I really shouldn't need cryptsetup if I'm not encrypting drives, I should not need lvm2 if I'm not using any logical volumes, and I should not need mdadm on a non-raid system.

I have my new systemd packages building now. When I get that installed I'll be able to go back to the distro package for mkinitcpio. I don't need to maintain those packages (several actually) as they are just shell scripts.

Arch Linux is getting very close to being fired. Right now I'm still at "but what else would be suitable?" but with each bout of stupidity, that sentiment dwindles.

[Zema Bus]

This is in the Arch news today:

archnews030424.jpg (85.58 KiB) Viewed 5056 times

[Grogan]

So... deliberate sabotage, then. That's why I had to jump through all those hoops to resolve those impossible conflicts.

[Grogan]

By the way, I'm really glad I switched Arch to using "eth0" (udev rule with mac address) rather than that stupid systemd nomenclature based on bus id's. Removing the NVME from the PCI-E slot would have shifted the thing back to enp0S4 and broke my networking again. That's progress for you

[Grogan]

I'm not having any luck with grub on EFI. It just flashes to a screen that I can't quite see and then goes to bios setup. That'll be the efi boot manager failing to hand over to grub or something. I did everything they said, it just doesn't work. The drive shows up in the bios as a UEFI boot device now, so it got written,

I'm also having fuckery with my two NVME drives so I have to use UUID as udev changes the nvme0 and 1 on every boot. But I have that sorted, and it still won't boot.

[Zema Bus]

Have you tried booting with a live environment like an EndeavourOS installer iso? I installed EndeavourOS on mine but I'm going to replace it with vanilla Arch.

[Grogan]

Oh I'm booting from USB alright, I have Arch installed I just can't boot it. I've actually got my EFIVARS screwed up right now I think because I forced reFind to be the default and it writes that to NVRAM. The problem is efibootmgr causes this on some systems. My disk doesn't even show up as a UEFI device anymore now.

I'm switching to CSM mode (I can boot both UEFI and Legacy) and starting over with good old fashioned MBR partitions. Fuck these stupid bootloaders.

I was perfectly happy before this UEFI boot complexity was invented

[Grogan]

Of course, it booted right up with grub installed to MBR

Now to configure networking (I use netctl, not that systemd shit or network manager) and then I think I'll shut everything down and go to bed. It's been a long, aggravating day.

[Grogan]

I got XFCE up and running pretty quick. I installed all of xorg first though (this would have pulled in some of it as dependencies but I need all the dev stuff).

It is unfortunate about udev and those two NVME drives. Every other boot it switches them around. I can't exactly add a udev rule, it's chicken before egg. I'd have to do it in the initramfs, but then that's what I'm trying to avoid. Because of that, I'm going to have to boot and mount all the partitions on those drives using UUID in fstab and grub.cfg. This means that I am going to have to start creating initramfs (mkinitcpio) for my kernels. That sucks, I hate having to use that.

udev is fucking stupid. It is asking for trouble to enumerate hardware in random order every boot. I'm not a happy man.

[Grogan]

I'll bet that once I get my kernel compiled that nvme horseshit will settle down. I find kudev (the udev that's in the kernel) to be more consistent when drivers are built right in. On Arch the nvme drivers are modules and that's systemd-udevd at play in the initramfs.

My first kernel is going to have initramfs (using UUID) but once I get settled I'll try and go back to normal disk nomenclature and a more monolithic kernel. It'll be mostly a skeleton, it won't need to load drivers in the initramfs.

[Grogan]

I meant to mention, I DID actually have the reFind bootloader working last night. I forced it though, using -use-default which writes to NVRAM without using efibootmgr (which, I think, screws up my efivars). However, when run in chroot, it takes the configuration from the arch installer environment, not the actual system. It requires manual configuration. (I was getting a graphical boot menu but on hitting enter to boot it was loading the kernel but just dumping me to a shell in the initramfs because it couldn't switch over). I could have gotten it, but that would have necessitated figuring out the syntax and it was faster to just do what I want anyway and I'm not otherwise interested in that boot loader

It's actually the best of both worlds having that CSM enabled in (UEFI + Legacy) mode. I can boot from either disk type.

Well, I'm about to BLAST over most of /home/grogan from the other box (I'm going to delete some unwanted things in a staging directory first before the blast). I created partitions with mount points so all the paths will jibe (well, once I finish copying data).

Code: Select all

[grogan@nicetry ~]$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
dev            devtmpfs   32G     0   32G   0% /dev
run            tmpfs      32G  1.6M   32G   1% /run
/dev/nvme1n1p1 ext4      196G  3.6G  183G   2% /
tmpfs          tmpfs      32G     0   32G   0% /dev/shm
tmpfs          tmpfs      32G   12K   32G   1% /tmp
/dev/nvme0n1p1 ext4      1.8T  1.7T  147G  93% /storage3
/dev/nvme1n1p7 ext4      295G  2.1M  280G   1% /storage
/dev/nvme1n1p8 ext4      1.3T   17G  1.2T   2% /storage2
tmpfs          tmpfs     6.3G   36K  6.3G   1% /run/user/1000

Those are nvme0 and 1 for NOW (they are mounted by UUID). One thing I was liking about GPT partition tables was not having the 4 partition limitation though. I had to use an extended. Swap is p5, and p6 is a 100G partition reserved for my LFS root filesystem for when I get around to adjusting it. It won't be hard, with normal booting etc. either!

Should be back to normal colours soon. I've left XFCE at its defaults (blech) until I get my styles in place. I won't be using it for much longer anyway though. It was actually a good one to install to get a lot of the machinery installed as dependencies, though, but I'll be back to my simple icewm soon. I can't compile just yet, so I'm blasting over /usr/local from the other box for now. I'm blind as a bat without my X File Explorer and terminal setup etc.

[Zema Bus]

Glad you're getting things sorted out. I've been using UUID for my drives, including in Slackware where I'm not using an initramfs.

[Grogan]

I'm just realizing that too, the kernel keeps track of that in /dev/disk/by-uuid now. You don't need blkid and friends in early userspace for that anymore. I didn't know that, because I've always just shunned it.

What I don't like about by-uuid is that it makes writing configuration files by hand really hard. I always know my device nodes, but UUID? lol

It sure is nice to have my colours back, and my beautiful red, intricate Rage-Cursor. I sure do love this new display. I'd have never done it (thanks )

[Grogan]

Well, I'd say I can compile a little faster now

I tested a kernel build (not valid, the same config that I build on the other for comparison)

make -j24

real 1m31.191s
user 31m16.943s
sys 2m26.410s

That takes near 10 minutes with all the netfilter shit I build (-j10 over there). A minute and a half here. That's just with the distro packages too, it'd probably be better once I get this system optimized.

[Grogan]

Arch got me in the ass again... I've been keeping my own firmware blobs for so long that I didn't know Arch compresses the firmware now.

I build a kernel and amdgpu was fatally dying. WTF. Compressed firmware support in kernel. I was just going through and it stuck out like a sore thumb... hey, that sounds just like something Arch would do and would certainly cause it to fail to load the firmware.

Anyway, I have a kernel and I have games now. Steam and Lutris and I tested a few games. I didn't have sound at first because numbnuts forgot to install pulseaudio and friends.

I made room for Far Cry 6 too. Going to purchase that now.

[Grogan]

Forgot to say... no, arch does NOT boot with UUID nomenclature without a properly constructed initramfs (with all the right hooks or nothing). It's kernel panic.

I had to change the rootfs in fstab to /dev/nvme1n1p1 (I left the others UUID for now just in case it shifts again) and in the grub entry for this kernel:

Code: Select all

menuentry 'Arch Linux, with Linux 6.7.9' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_msdos
                insmod ext2
                search --no-floppy --fs-uuid --set=root 73ce9b88-c44b-4454-a673-9e111ccc0dfe
                echo    'Loading Linux 6.7.9 ...'
                linux   /boot/vmlinuz-6.7.9 root=/dev/nvme1n1p1 rw  loglevel=3 quiet

I just copied and pasted and edited a stanza for now. I'm going to fix that file up soon so it has only what it needs.

The nvme drives have seemed to stabilize with the drivers built in. I tested rebooting several times.

[Grogan]

It had been so long that I didn't know Arch dropped my mail program, Sylpheed. I have to head out soon and I needed to check my email, so I thought I'd take a shortcut and just install the distro package. It's gone! (at some point in the last 4 years or so lol). So I had to take 20 seconds to compile it to /usr/local. Just because things are old doesn't mean they are no good anymore.

[Grogan]

I've got my grub configuration cleaned up now

Code: Select all

set default="0"
terminal_input console
terminal_output console
set timeout=10
set timeout_style=menu
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set linux_gfx_mode=text

### Add delayacct to the kernel command line for iotop ###

menuentry 'Arch Linux' {
     search --no-floppy --fs-uuid --set=root 73ce9b88-c44b-4454-a673-9e111ccc0dfe
     linux  /boot/vmlinuz-6.7.9 root=/dev/nvme1n1p1 ro mitigations=off loglevel=3 quiet
}

That's the whole file (and yes, it should be "ro" in the kernel command line when not booting with initrd. fsck can't work if the real root is mounted rw at that time). I left a note for myself about delayacct, I can never remember a kernel parameter when I need it. iotop still works to show disk activity, but a lot of the stats can't be shown. So most of the time I don't bother enabling it (overhead... whether it matters or not) because all I want to see is disk transfers.

I probably don't need that search line with my kernel, as the NVME drive enumerations are stable but it does no harm. Another thing I hate about UUIDs though, if you format the filesystem they change. (think... restoring system from tarball). So I'll be getting rid of that nomenclature everywhere, soon. (still mounting non root filesystems by UUID in fstab).

I already removed the distro kernel (I hate when that gets updated, it generates two mkinitcpio images (bloated fallback) every time). I'm going to get my LFS set up here soon so I have two Linux systems to boot to (so I can work on things from off system without having to boot from USB)

P.S I don't need mitigations=off (they are disabled in kernel config) but the directive does shut off the warnings about my CPU vulnerabilities. I won't be loading microcode blobs either, I hate that shit.

[Grogan]

Another thing I was grandfathered into having was python2. Arch ditched that probably a year ago. (I still need it for some builds and older software)

That was an old distro package and I didn't even have a PKGBUILD for it, so I went to AUR and they had one (with patches from gentoo even... it's an unofficial Python 2.7.18)

[Grogan]

I'm a chicken with my head cut off. I go to install my new LLVM packages, and pacman didn't prompt me to remove the Arch packages despite my provides= and conflicts= lines. I'm all WTF, making sure my LLVM installation is OK and then I remembered. I already replaced the distro's LLVM with mine (built on the other computer) immediately after installing Arch (before I built mesa). Mine would have been fine (and I'm still compiling with nehalem anyway, because it likely won't be safe to use alderlake because it could turn on some hinkey things. -march=nehalem produces good code for Intel) but I wanted to test a build of LLVM anyway (and watch sensors output etc.)

[Grogan]

I got my LFS set up now. I blasted the tarball to the partition, dropped in my kernel from Arch, edited fstab, networking files... the only thing I forgot was my udev rule, wrong MAC address. Then once the system was up I recompiled my kernel (slightly different config on my LFS)

It actually boots up too fast, I had to add another second of sleep because it was dumping network bridge initialization messages after the login prompt (had to hit enter to dismiss).

I DO have to use that search line and set the root (not the same as the rootfs) using the UUID because that disk0 part1 syntax isn't going to work anymore. This is how grub finds the kernel in /boot, it has to know where it is relative to the root device. Oh well, if I format the partitions I'll have to change the UUID in grub.cfg. Easy enough, just "ls -l /dev/disk/by-uuid" and it will show them by partition.

Code: Select all

set default="0"
terminal_input console
terminal_output console
set timeout=10
set timeout_style=menu
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
set linux_gfx_mode=text

### Add delayacct to the kernel command line for iotop ###

menuentry 'Arch Linux' {
     search --no-floppy --fs-uuid --set=root 73ce9b88-c44b-4454-a673-9e111ccc0dfe
     linux  /boot/vmlinuz-6.8.0 root=/dev/nvme1n1p1 ro mitigations=off split_lock_detect=off loglevel=3 quiet
}

menuentry 'Bollux' {
     search --no-floppy --fs-uuid --set=root ba77b9a2-0602-440b-840a-47ed0f63a8f6
     linux /boot/vmlinuz-6.8.0 root=/dev/nvme1n1p6 ro mitigations=off split_lock_detect=off ipv6.disable=1
}

[Grogan]

I'm using XFCE for non gaming, and my trusty IceWM for gaming. This way I can use gaming-adverse settings like focus follows mouse, and workspace switching at screen edges etc. for XFCE. It's better for workflow.

I haven't finished populating my panel, and I have some broken icons that no longer jibe with the fallback icon names in Adwaita (My Noia icon theme is both old and incomplete for modern DE's, but the main ones all work and it's my favourite icon set). It didn't help that I blasted over .desktop files and stuff from the old home directory either (which is where a lot of those applications are even coming from in the menu... many aren't even here yet lol)

I miss my old XFCE 4.12.0 but that's not going to work correctly on Arch (or possibly even compile) like it does on my LFS system. I keep the minimum versions of the GTK libraries and related dependencies to function, because I like a lot of old programs. Also that old version isn't aware of newer desktop technologies and the way X is handled under systemd. I tried it once a while back and while my compiled binaries ran, it did not work correctly.

For example, adding a launcher where the icon is only going to be a flyout launcher and not do anything itself (like my Utilities icon with the wrench). It doesn't let you do that anymore. So what I do is make the target command /bin/true so it silently succeeds at doing nothing if clicked

Both bottom and thinner top panel auto-hide but all that's on the top panel is taskbar (they call it window buttons). View image in new tab to see full size (otherwise the fonts look like ass)

The hostname, nicetry, is recycled. The computer that used to be nicetry/192.168.0.2 went to landfill (an old PIII system I had set up as a dialup gateway with an old slackware distro and I no longer have room for it on a desk... and fuck dialup... mobile fallback now) so this one can assume its place. This way all the hosts files I have around the network all jibe lol

arch-newbuild.png (1.4 MiB) Viewed 4954 times

[Zema Bus]

Looks great! I wish Plasma in my Slackware 15 install hadn't ruined XFCE, otherwise I'd be using it. The Plasma version in Slackware 15 is very stale, I don't use it anymore, but XFCE is timeless. So I've just been using MATE. I'm using MATE on my Arch gaming machine as well, it has been a good compromise between between being gaming friendly and general usability. On my main system I'm planning on doing a new Arch install, and I may do a new Slackware install as well, this time minus Plasma unless maybe if I go back to Slackware-Current, but I don't know if I want to go back to Current.

[Grogan]

You pretty much have to use Slackware Current nowadays if you're going to use Slackware and even then things like KDE won't be shiny new. (may have to consult Alienbob)

I remember, maybe 4 years ago I started to see people saying "You should only have one desktop installed". I was all WTF, you can have as many desktops as you want, start them from your session manager etc. Then when I started using sillier distros and sillier desktop environments when I started playing games on Linux again, I got why those people were saying that. It's not just KDE and XFCE, I had an openbox front end that did that too (can't remember the name, but it bit the weenie and stepped on my user configuration and took me a while to figure out what files it changed... my gtkrc files and everything)

[Grogan]

Well, my Arch is about to become x86_64-v3. No, alderlake is not v4, even though it's a newer cpuarch than rocketlake. That's because Intel dropped AVX-512. See why I hate these gimmicky intel instructions? They don't even know what the fuck they are doing... they have essentially guaranteed that nobody can use AVX-512 unless specifically turned on for your own projects, because of the abiguity. What... "system requirements: Intel 11th Gen or specific Xeon models"? Grandma gamer will never get to use AVX-512. They aren't stopping either, they are introducing new AVX instructions that are like the old ones only different, in newer models.

Code: Select all

#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
# CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=alderlake -O2 -pipe -fno-plt"
CXXFLAGS="$CFLAGS"
# LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed"
LTOFLAGS="-flto=auto"
RUSTFLAGS="-C target-cpu=alderlake -C debuginfo=0"

I'm about to bootstrap with new kernel headers, glibc, binutils and gcc (which also has our libstdc++) and henceforth, everything is going to be built for alderlake unless it breaks and needs overriding. (and if I break anything critical, I have my LFS setup to boot to and I can easily fix it). Of course I don't like their CPP and LDFLAGS hardening either, so I always change that. Performance optimizations, not spinning hamster treadwheels.

They have also got some assholish defaults now for the options= parameters.

Code: Select all

OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)

Defaults:
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)

I don't want debugging (but when used with strip, it creates a separate package with debugging first at least). I also don't want lto by default, I'll decide which packages to build like that. (they turn it on by default, and override with !lto on a per package basis. That's bass ackwards for my tastes, for there are too many things broken like that, telling your toolchains to do that arbitrarily. Even things like mesa get subtly broken at times with LTO.