Search

Items tagged with: AlpineLinux


Okay, this is literally incomprehensible: on my Alpine v3.24 VPS, drill github.com, nslookup github.com, getent ahosts github.com, host github.com, ping github.com, lynx https://github.com/, and manually sending hand-written queries to the configured DNS servers all return/use the correct IPv4 address, and return nothing as expected when querying for AAAA records (since github is shit and doesn't support IPv6).

And yet, curl and git both have completely nonsense IPv6 addresses returned when resolving (they're random Cloudflare addresses) alongside the correct IPv4 address, and then prioritize them. Those tools also completely ignore any overrides in /etc/hosts and I can't find any way to see what fucking broken bullshit they're doing to resolve DNS (because it's apparently not fucking getaddrinfo nor manually reading /etc/resolv.conf).

There is literally no possible source for those addresses to be returned when resolving github.com AFAICT and no way to override them other than having to edit literally everything that might touch github to add -4 to those utilities' command lines

(It's also been doing it for months with multiple different DNS servers, it's not a transient issue)

#Linux #AlpineLinux


The media in this post is not displayed to visitors. To view it, please go to the original post.

My Alpine Linux Bootloader project is a success! I can now boot any Linux rootfs such as Debian over VPN + NFS via Alpine. The entire bootloader creation uses 200 lines of shell scripts.

The advantage is that the target OS needs not to be pre-configured for PXE, VPN or NFS. In a regular netboot setup, each target OS's initramfs must know how to do networking / mount rootfs. WireGuard is used here, so each needs customization. Using the AlpineBL approach, the bootloader takes care of everything. I used a boot disk in my setup, not PXE, but they're not exclusive, PXE can deliver that boot disk if you want.

I'll publish a full tutorial on Alpine Wiki, but here's a quick review.

First, create an Alpine rootfs at ./mnt with alpine-make-rootfs, with only 4 packages preinstalled: alpine-base, linux-lts, wireguard-tools, kexec-tools. You need another DHCP client for IPv4, I use IPv6 SLAAC so I skipped it. Enable some OpenRC services such as "devfs", "modules", and "local" in that chroot. Extract the kernel from rootfs. Create an initramfs with cpio at ./mnt. Base image done.

Next, create another rootfs overlay at ./rootfs_extra, with /etc/wireguard/wg0.conf and /etc/local.d/99-alpinebl.start. Chain two initramfs binaries with cat. Linux unpacks them sequentially (feature+bug: ./rootfs_extra can overwrite existing files). Overlay image done. Warning: this image contains private keys.

Boot your machine with that Alpine kernel, and your custom initramfs, with rdinit=/sbin/init (force the kernel to use the real userspace init as the "init script"), retain_initrd (don't release compressed initramfs), kexec_load_disabled=0 (bypass Alpine hardening), alpinebl.stage=1 (custom flag).

Alpine userspace starts in a normal runlevel. OpenRC's "local" service executes our custom boot script 99-alpinebl.start. In the custom boot script, load network card kmod, enable networking, enable WireGuard, mount NFSv4 to /mnt. In theory we can switch root now, but we're still using the Alpine kernel, not the target kernel which can be arbitrary. We need to "swap" to the target kernel, and overlay more target kmods in initramfs on the fly.

To do this, create another initramfs using files in /mnt/lib/modules and /mnt/lib/firmware via cpio + gzip. Chain the original initramfs (accessing via /sys/firmware/initrd with retain_initrd) and the new overlay to /dev/shm/initrd Run kexec with the /mnt/vmlinuz symlink and /dev/shm/initrd. Run kexec with alpinebl.stage=2, and strip retain_initrd since we don't need it in Stage 2.

A small warning here: at the end of Stage 1, there are 4 copies of initramfs in RAM: /, /sys/firmware/initrd, /dev/shm/initrd, and kexec buffer, each is 1 GiB+, if you don't have RAM, you need to delete blobs under /lib/firmware before cpio / kexec but after modprobe. If RAM is still not enough, you need to stop using retain_initrd, instead, instead, find your own boot drive's block device, mount it, and find the initramfs - tedious work).

The system starts again, and all the procedures described above is repeated again: enable network, enable WireGuard, mount NFSv4. Now the startup script sees alpinebl.stage=2 in /proc/cmdline, so it knows to switch_root instead of kexec.

But remember, we're in an initramfs, but the boot script is not executed by /bin/sh with PID 1. This is a full system with Busybox init + OpenRC, we're a normal userspace process, so we can't kill or replace init unless we're init already... We're stuck here. Should we use a PID namespace to work around it? No!

Busybox init supports hot update via the "restart" target after receiving a SIGQUIT (an arcane feature), it's a replacement binary path. We create a /init file (to bypass switch_root's safety check), write ::restart:/sbin/switch_root /mnt /sbin/init to /etc/inittab, send SIGHUP to PID 1 to reload config, then send SIGQUIT to PID 1. So init shutdowns userspace daemons, call execvp(), and switch_root takes over.

Alpine userspace is gone. Debian userspace starts up with systemd like a regular boot. Existing Ethernet, WireGuard interfaces, and the NFS mount are auto-inherited by systemd. You get a login shell. Mission complete. #alpine #alpinelinux #NFS #WireGuard


Ok, I think I've got this display card under control - or so it seems. It hasn't crashed since Wednesday.

I guess this is a combo AMD RDNA3 Navi23 and KDE Plasma (+ Wayland?) bug...

I backed out all my Linux kernel command line switches for AMD GPUs and it crashed to green screen in less than a half hour. So, re-adding them stopped that from happening.

... amdgpu.dcdebugmask=0x410 amdgpu.tmz=0 amdgpu.gpu_recovery=1 amdgpu.sg_display=0 ...

And then the cursor thing is fixed <?!> by adding

KWIN_FORCE_SW_CURSOR=1

Currently this is what is set:

`cat /proc/$(pidof kwin_wayland)/environ | tr '\0' '\n' | grep KWIN` :

KWIN_DRM_NO_AMS=1
KWIN_DRM_NO_DIRECT_SCANOUT=1
KWIN_FORCE_SW_CURSOR=1

From a user experience point of view I don't see any difference with that software cursor setting.

There's another wrinkle to this that might be a factor but I can't really test around it currently. This is a multi-head machine and one screen is connected via HDMI and one is DP.

Perhaps this wouldn't be a problem if both screens were connected via the same type of connector.

Both screens are set to the same refresh frequency. But, in the display control app one reads back at 60.00 Hz while the other is 60.000 Hz. Minor thing right? But in trying to make this work I've seen references to AMD GPU weirdness in multi-head configurations where the refresh rates were different between screens. Red herring perhaps.

Anyway, don't know if there are (or will be) any people trying to make a RX 5800 XT GPU behave under Linux but this seems to be what worked for me and my dual head setup. I'll update if anything changes.

#Linux #AMD #AMDGPU #KDE #KDEPlasma #Plasma #AlpineLinux #kwin #Wayland


Back at testing whether my RDNA3 card (7800 XT) will behave itself on this system.

I'm running kernel 7.1.4 (Alpine linux-stable) so supposedly there are a bunch of fixes since 6.19 -> 7.0 -> 7.1.x.

We'll see. Last hour has been solid. No screen artifacts or horizontal aberrations on terminal or web browser windows.

When it did occasionally work adequately before it would hard crash to a green screen on one of the monitors after about 24 hours or so. Didn't matter what kernel parameters I put on the kernel cmd line.

It's kind of weird as I've been running this card in a different system (same OS, different gen CPU/mobo) successfully but it is a single head system so maybe that's the difference. Some combinations of cobbled together junk just don't work in the PC space.

Fingers crossed.

#Linux #AMD #amdgpu #RDNA3 #AlpineLinux


It took some time and effort, but the Alpine Linux riscv64 3.24 builder finally managed to churn through all the packages.

This means Alpine Linux 3.24 is imminent. Expect the first RC soon.

#AlpineLinux