De Vloek van Vastgesoldeerd RAM

Ik gebruik normaal gesproken twee laptops: één voor persoonlijke zaken en één voor werk. Dit is een vergeefse poging om zaken gescheiden te houden en de werklaptop aan het einde van de dag in het "kantoor" achter te kunnen laten. Ik heb in 2021 al geblogd over de aanschaf van mijn huidige werklaptop.

Deze Lenovo X1 Carbon was fantastisch, totdat ik onlangs merkte dat er veel vaker browser-tabs crashten en het root-bestandssysteem zich af en toe als 'ReadOnly' markeerde, wat uiterst onhandig is.

Oct 15 23:33:35 razor-crest kernel: BTRFS warning (device dm-0): csum failed root 257 ino 166754 off 5859786752 csum 0x31019647 expected csum 0x6d009929 mirror 1
Oct 15 23:33:35 razor-crest kernel: BTRFS error (device dm-0): bdev /dev/mapper/luks-571c7357-a343-49f3-993c-167c8c5dcec6 errs: wr 0, rd 0, flush 0, corrupt 3856936704, gen 0

Deze fouten maakten me nieuwsgierig naar mogelijke RAM-fouten. Daarom heb ik een memtest86+ boot-image toegevoegd aan mijn Ventoy USB-stick en hiervan opgestart.

Memtest86+

Dit programma start een absoluut minimaal besturingssysteem dat vervolgens een reeks patronen schrijft naar elk mogelijk fysiek geheugenadres en deze vervolgens weer terugleest. Als de teruggelezen waarde niet overeenkomt met wat er geschreven is, is er een probleem.

Wanneer het programma ongestoord draait, voert het meerdere passes uit, omdat sommige fouten slechts incidenteel optreden. In dit geval werden er echter vrijwel direct een reeks fouten getoond.

In het verleden zou dit een eenvoudige reparatie zijn geweest. De output zou voldoende zijn geweest om te bepalen welke van de DIMM-modules defect was, of in het ergste geval zou je er één verwijderen en de test opnieuw uitvoeren om via een binaire zoekmethode de boosdoener te vinden. Eenmaal geïdentificeerd kon je gewoon een vervangende DIMM bestellen (of de gelegenheid grijpen voor een upgrade) en verder gaan.

Maar in de zoektocht naar nog dunnere laptops (omdat een DIMM-socket ongeveer 6 mm diepte toevoegt) — en wellicht cynisch om ervoor te zorgen dat elke defecte module resulteert in de aankoop van een volledig nieuwe laptop — is het RAM-geheugen in de meeste laptops nu direct op het moederbord gesoldeerd (uitzonderingen zoals Framework daargelaten). Tenzij je bedreven bent in het vervangen van ball grid chips, is vervanging geen reële optie.

Gezien de afschrijving over vijf jaar en de technologische vooruitgang is het waarschijnlijk tijd voor een nieuwe laptop. Toch wil ik kijken of er een manier is om de Lenovo X1 Carbon draaiende te houden, aangezien het nog steeds een zeer capabele machine is die de nog oudere Dell XPS 13 kan vervangen die ik als persoonlijke laptop gebruik. Over de vervanging schrijf ik later.

Memmap

Terwijl ik wacht op de nieuwe laptop, wilde ik kijken of ik de huidige stabieler kon maken. Uit kort onderzoek kwamen twee opties naar voren die aan de Linux-kernel kunnen worden meegegeven om defecte sectoren te vermijden:

  • badram
  • memmap

badram blijkt een out-of-tree patch te zijn die meestal alleen in Debian/Ubuntu-gebaseerde distributies wordt meegeleverd. Aangezien ik Fedora op deze machine draai, was dit geen optie.

memmap is een kernfunctie van de kernel en zou dus beschikbaar moeten zijn op Fedora. Je moet een lijst met geheugenadressen en lengtes opgeven in het formaat lengte$offset in de kernel-commandline.

Memtest86+ kan de correcte output genereren (voor zowel badram als memmap) en deze zelfs naar een bestand opslaan. Dit lukte echter niet met het ISO-image dat ik op de Ventoy USB-stick had gezet, waardoor ik genoodzaakt was een foto van het scherm te maken. De handmatige transcriptie hiervan was een "leuk" klusje.

Alle documentatie voor het toevoegen van kernel-commandline-argumenten schrijft voor om het bestand /etc/default/grub te bewerken, de waarden toe te voegen aan de GRUBCMDLINELINUX entry en vervolgens grub2-mkconfig -o /boot/grub2/grub.cfg uit te voeren.

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=\$memmap_val memmap=0x30$0x3fe90140,0x48$0x3fe90b08,0x48$0x3fe90ba8,0x48$0x3fe916a8,0xf0$0x3fe91c00,0x90$0x3fe92560,0xf0$0x3fe92f00,0x50$0x3fe93200,0x90$0x3fe93260,0xf0$0x3fe93800,0xf0$0x3fed4300,0x70$0x3fed4900,0x70$0x3fed4980,0xf0$0x3fed5400,0xf0$0x3fed5e00,0xf0$0x3fed6700,0xf0$0x3fed6d00,0xf0$0x3fed7000,0x30$0x3fed7a00,0xb0$0x3fed7a40"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

Ik probeerde dit, maar na het herstarten van de machine weigerde deze op te starten. In het GRUB-scherm kon ik de kernel-commandline inzien en zag ik dat de $0 in de memmap-entry was vervangen door grub2-mkconfig. Dit wijst op klassieke substitutie van omgevingsvariabelen ($0 is gewoonlijk de naam van het script dat wordt uitgevoerd).

Ik vond een RedHat-bug waarin een soortgelijk probleem werd beschreven, met als oplossing om de waarde als variabele toe te voegen:

# grub2-editenv /boot/grub2/grubenv set memmap_val='0x30\$0x3fe90140,0x48\$0x3fe90b08,0x48\$0x3fe90ba8,0x48\$0x3fe916a8,0xf0\$0x3fe91c00,0x90\$0x3fe92560,0xf0\$0x3fe92f00,0x50\$0x3fe93200,0x90\$0x3fe93260,0xf0\$0x3fe93800,0xf0\$0x3fed4300,0x70\$0x3fed4900,0x70\$0x3fed4980,0xf0\$0x3fed5400,0xf0\$0x3fed5e00,0xf0\$0x3fed6700,0xf0\$0x3fed6d00,0xf0\$0x3fed7000,0x30\$0x3fed7a00,0xb0\$0x3fed7a40'

Pas daarna wijzig je /etc/default/grub naar:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=\$memmap_val"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

En voer vervolgens opnieuw grub2-mkconfig -o /boot/grub2/grub.cfg uit.

Deze keer startte het systeem correct op en zijn de juiste waarden zichtbaar in /proc/cmdline:

BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.2.11-200.fc44.x86_64 root=UUID=869b183b-b858-40e5-8da7-e923dd367c2a ro rootflags=subvol=root rd.luks.uuid=luks-571c7357-a343-49f3-993c-167c8c5dcec6 rhgb quiet memmap=0x30$0x3fe90140,0x48$0x3fe90b08,0x48$0x3fe90ba8,0x48$0x3fe916a8,0xf0$0x3fe91c00,0x90$0x3fe92560,0xf0$0x3fe92f00,0x50$0x3fe93200,0x90$0x3fe93260,0xf0$0x3fe93800,0xf0$0x3fed4300,0x70$0x3fed4900,0x70$0x3fed4980,0xf0$0x3fed5400,0xf0$0x3fed5e00,0xf0$0x3fed6700,0xf0$0x3fed6d00,0xf0$0x3fed7000,0x30$0x3fed7a00,0xb0$0x3fed7a40

Ik heb een tekstbestand op een USB-stick gemaakt met de memmap-waarden, zodat ik deze opnieuw kan toepassen als ik een volledige herinstallatie doe. Dit zou de machine draaiende moeten houden tot de nieuwe laptop arriveert, en hopelijk nog een tijdje langer.

De volgende taak is om te controleren of ik alles heb gebackupt en vervolgens btrfs check --fix uit te voeren om te zien of ik de metadata in het bestandssysteem kan herstellen.