* Front panel The case's manual has a terse illustration with two arrows to pull the front panel "away and up" from the rest of the case. Here too, the amount of force required to do that is terrifying. Notice how [[https://www.youtube.com/watch?v=nUD0HyzVpLg][our friend here]] cuts abruptly at 8:17; that's because the levels of violence required to tear that panel off are too graphic for YouTube. * Front fan Remember that fan from earlier, the one with only 3 holes for the motherboard's 4 pins? Turns out 1. that last "optional" pin is supposed to allow speed control; without it, the fan always spins at full speed; 2. the fan itself (ZA1225ASL) is [[https://www.youtube.com/watch?v=pd6gDY7LPlU][complete and utter crap]]: it cannot be disassembled, so no cleaning off the dirt, no greasing. So the thing is loud, it always spins at full speed, and if one day it decides to become even louder than usual, you're SOL. * Motherboard ** Firmware updates *** Prologue Quoth ~fwupdmgr get-devices~: #+begin_example WARNING: UEFI capsule updates not available or enabled in firmware setup See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information. #+end_example Quoth the wiki: #+begin_quote Most typically entering the firmware setup screen and enabling capsule updates will cause this warning to disappear, and also make firmware updates possible. The relevant option may be poorly labelled, for example "allow Windows UEFI updates". #+end_quote Not seeing any such option in the boot menu. #+begin_quote It is possible, but unlikely, that flashing the latest vendor BIOS, using either Windows or a LiveCD, will add support for [the thing that correlates with capsule updates being enabled]. #+end_quote Well then. [[https://www.msi.com/Motherboard/B550M-A-PRO/support#bios][Vendor says]] "put this on a stick; reboot; ask the menu to flash from the stick". Putting some feelers out first: #+begin_quote If you execute a UEFI update, this update might delete the existing UEFI boot entries — [[https://wiki.archlinux.org/title/GRUB#Installation][ArchWiki]], 2024 #+end_quote #+begin_quote Like others in this forum, I too suffered from a reformatted EFI partition following a BIOS update on my desktop pc. I had no idea that the MSI BIOS team doesn’t care about Linux installs, so to my surprise, following the update, my system booted straight to windows. […] Ultimately, I completely wiped and recreated the EFI partition with gparted (fat32), changed the structure to GPT with gdisk, and then mounted that partition in the /mnt/efi location, and then proceeded to generate a new fstab with genfstab. After arch-chroot’ing into my endeavoros install, I ran bootctl install (which complained about boot loader not setting esp information) and then reinstall-kernels. I updated the loader.conf with the correct default boot ID, and set the recommended options. That got me back into my system after quite a bit of trial and error. — [[https://forum.endeavouros.com/t/endeavoros-efi-partition-wiped-by-msi-bios-update/54740][EndeavorOS forums]], May 2024 #+end_quote #+begin_quote when updating the bios, it cleared all my settings. Apparently, this includes clearing the list of boot loaders, which it set back to the default of just Windows. Sadly this bios does not provide the tools to add boot entries as, apparently, some do. To fix it, I managed to boot to a Linux live USB and add the missing entry using the efiboomgr command line tool. — [[https://forum-en.msi.com/index.php?threads/updating-to-bios-7a32v1q1-wont-see-linux-uefi-boot.388109/][MSI AMD forums]], August 2023 #+end_quote Welp. OT1H, I could dedicate a couple of week-ends learning the joys and wonders of efibootmgr, gdisk & friends. OTOH I sort of like keeping my desktop station… not bricked? Pity, because otherwise I've had smooth and incident-free firmware updates on other stations with ~fwupdmgr~ 🤷 *** But then {{{narrator(waves vaguely toward [[file:killing-time.org][that whole debacle]])}}} *** Our protagonist sets forth Put the =.2G1= file on the USB stick, rebooted into UEFI, rebooted into "M-Flash", did the thing, rebooted. Predictably: #+begin_example Entering rescue mode... grub rescue> help Unknown command `help'. grub rescue> #+end_example =ls='d and =set='d around, browsed a couple of online posts from similarly marooned comrades[fn:: Not sure why I did not think of consulting [[info:grub2#GRUB only offers a rescue shell][the fine manual]].]. Luckily my patience for QWERTY drained out before I could damage things further; disabled Secure Boot on a whim and lo! It Booteþ Again! *** But doþ it fwupdate þough? #+begin_example $ fwupdmgr update WARNING: UEFI capsule updates not available or enabled in firmware setup See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information. #+end_example 😾 {{{ad(But wait\, there's more!)}}} #+begin_example ╔══════════════════════════════════════════════════════════════════════════════╗ ║ Upgrade UEFI dbx from 20230501 to 20241101? ║ ╠══════════════════════════════════════════════════════════════════════════════╣ ║ This updates the list of forbidden signatures (the "dbx") to the latest ║ ║ release from Microsoft. ║ ║ ║ ║ An insecure version of Howyar's SysReturn software was added, due to a ║ ║ security vulnerability that allowed an attacker to bypass UEFI Secure Boot. ║ ║ ║ ╚══════════════════════════════════════════════════════════════════════════════╝ Perform operation? [Y|n]: n Devices with no available firmware updates: • SA400S37480G • SSD 980 500GB #+end_example Getting mixed signals here. *** Can I have Secure Boot back though? Off the top of my head: - that dbx update? - ~sudo blarney-grub2 --pretty -pls --with-sugar=top --with-sugar=top~? - dracut? dbx update: nope. ~efibootmgr~ only shows =opensuse=, not =opensuse-secure=. - After ~udpate-bootloader --install~, =opensuse-secure= shows up; no change though, enabling Secure Boot still lands me in =grub rescue=. - Change bootorder with =-o 0,1=? #+begin_example $ sudo udpate-bootloader --install $ sudo efibootmgr BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0001,0000 Boot0000* opensuse-secureboot HD(1,GPT,2ffd6bee-1b1e-4088-8fdf-0c9321c861a3,0x800,0x100000)/File(\EFI\OPENSUSE\SHIM.EFI) Boot0001* opensuse HD(1,GPT,2ffd6bee-1b1e-4088-8fdf-0c9321c861a3,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI)0000424f $ sudo efibootmgr -o 0,1 BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0000,0001 Boot0000* opensuse-secureboot HD(1,GPT,2ffd6bee-1b1e-4088-8fdf-0c9321c861a3,0x800,0x100000)/File(\EFI\OPENSUSE\SHIM.EFI) Boot0001* opensuse HD(1,GPT,2ffd6bee-1b1e-4088-8fdf-0c9321c861a3,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI)0000424f #+end_example Does not seem to persist after reboot 🤷 *** The Twist #+begin_example $ sudo journalctl --grep 'secure boot .*abled' Nov 28 20:37:13 localhost kernel: secureboot: Secure boot disabled [… an so on, for every boot until today …] #+end_example … I'm an idiot; I never had Secure Boot enabled on that machine, apparently. I guess the BIOS update just turned it on silently. *** Can I have Secure Boot at all though? Personal takeaways from [[https://github.com/Foxboron/sbctl/issues/181][Foxboron/sbctl#181]]: maybe, but it involves so much futzing around and has such a high chance of [[https://github.com/Foxboron/sbctl/issues/181#issuecomment-1354247722][false positives]], that I will tentatively conclude "not worth it". * SSD LDLC's off-brand SSD died, fortunately within the warranty period. Replaced it, and… I guess I should shoehorn a joke about "a descent into hell" or "the beginning of a nightmare", but that just twists [[./killing-time.org][the knife]] ☹️