(Written March 13th at 2am.)

This morning (yesterday), my computer decided not to boot again: it halts on "cannot find firmware rtl-whatever" every time. (it has booted just fine several times since removing the firmware.) I've had quite the ordeal today trying to fix it, and every freaking step along the way has thrown errors and/or required workarounds and a lot of research.

Let's make a list of everything that went wrong!

1) Live CD: 2yo had been playing with it, and lost it. Not easy to find, and super smudgy.

2) Unencrypt volume: Dolphin reports errors when decrypting the volume. Research reveals the Live CD doesn't incude the cryptsetup packages. First attempts at installing them mysteriously fail.

3) Break for Lunch: automatic powersaving features turned off the displays, and also killed my session.

4) Live CD redux: 25min phonecall from work! yay, more things added to my six-month backlog.

5) Mount encrypted volume: Dolphin doesn't know how, and neither do I. Research ensues. Missing LVM2 package; lvmetad connection failure ad nauseam; had to look up commands to unlock, clone, open, and mount encrypted Luks volume, and how to perform these actions on Debian instead of Ubuntu/Kali. This group of steps took four hours.

6) Chroot into mounted volume group: No DNS! Research reveals how to share the host's resolv with the chroot.

7) `# apt install firmware-realtek`: /boot/initrd.img does not exist. Cannot update.

8) Find and mount /boot, then reinstall firmware: Apt cannot write to its log (minor), listed three install warnings, and initially refused to write to /boot/initrd.img-[...]

9) Reboot!: Volume group not found. Cannot process volume group. Dropping to a shell! oh no..

(Not listed: much research, many repeated attempts with various changes.)

At this point it's been 9 hours. I'm exhausted and frustrated and running out of ideas, so I ask @perfectasshole for help.
He walks me through some debugging steps (most of which i've already done), and we both get frustrated because everything looks correct but isn't working.

10) Thirteenth coming of the Live CD: `update-initramfs -u` within chroot throws warnings about /etc/crypttab and fsck, but everything looks fine with both. Still won't boot. Editing grub config manually to use the new volume group name likewise produces no boots. Nothing is making sense.

11) Rename volume group: doubles -'s for whatever reason; Rebooting gives the same dreaded "dropping to a shell" result.

A huge thank-you to @perfectasshole for spending three hours fighting with this issue with me! I finally fixed it about half an hour after he went to bed.

After renaming the volume group to what it was originally, one of the three recovery modes managed to actually boot and load the volume. From there I was able to run `update-initramfs -u` from the system proper (which completed without issue) and was able to boot normally thereafter.

I've run updates and rebooted twice now.
After twelve+ hours... yay, I have my Debian back!

oof.

KALI FOR THE LOVE OF GOD CAN YOU NOT BREAK YOUR BOOT PACKAGE FOR 24 FUCKING HOURS

the initrd isn't at all valid and the vmlinuz package is 0 bytes.

After two years of being in (metaphorical) jail, I once again was given the a privilege of unlocking and rooting my phone. Damn. Frick Huawei, never coming back to that experience.

I gotta say, rooting... Feels a tad less accessible nowadays than when I last practiced it. All this boot image backup, patch, copy, reflash is crying to be automised, only reason I can think of why that changed and magisk can no longer patch itself into the phone's initrd is that it's somehow locked? Was it a security concern? Or can sideloaded twrp no longer do that?

Oh, and the war... The war never changes, only exploits do - fruck safety net... Good for Google that they now have an *almost* unfoolable solution (almost). The new hardware-based check is annoying af, but luckily, can still be forced to downgrade back to the old basic check that can be fooled... Still, am I the only one who feels Google is kinda weird? On one hand, they support unlocking of their own brand of phones, but then they continuously try to come up with frameworks to make life with a rooted or unlocked phone more annoying...

On the other hand, I do like having my data encrypted in a way that even sideloading twrp doesn't give full access to all my stuff, including password manager cache...

Any recommendations what to install? I do love the basic tools like adaway (rip ads), greenify (yay battery life!), viper4android (More music out of my music!) and quite honestly even lucky patcher for apps where the dev studio practices disgust me and don't make me want to support them...

So, today, I wanted to try setting up a wireguard VPN server on my little raspberry pi at home. I... expected /some/ issues, but what I found dumbfounded me.

1 - I already had the wireguard package from the unstable branch of the main raspbian repo installed... Huh, okay.
2 - Setting up config was extremely easy... Wow, so the rumors were true. Wireguard really is almost dumb-simple.
3 - Failed to create a network interface? Oh, trouble, here it is! So lets see... modprobe wireguard... Nope. Don't have the module? What?
4 - Reconfigure package to rebuild the module - missing kernel headers? Huh... weird

This was the simple stuff... Then I went down the rabbit hole of the Raspberry Pi ecosystem:

1 - There is the Raspberry Pi Bootloader, that is apparently separate from the Kernel itself. And I didn't seem to have any of the standard linux-image-* installed... What? Weird, yet there I was, running a 4.19.42-v7+ kernel...
2 - No kernel and no headers... What... The... Fuck
3 - Okay, so... Lets just... try to install the latest kernel image then? One apt-get install... It downloaded the image, but during package configuration, it failed because... I didn't have... its headers? What? What for? And if it needs them (for whatever reason), why isn't the headers package as a dependency? Ugh, whatever...
4 - Another apt-get install and... Okay, building the initrd image aaaaand...
FAIL
WHAT. What is it this time!?

Oh... Ran... No more space on device? What? Is /boot independent? Of course it is, it has to be, its a bloody different filesystem

Okay, so, lets che-OH MY GOD WTF.

Its just bloody 45 MBs big! The entire /boot is just 45 MBs large. WHY. THE. FUCK.

This was a default raspbian install from I have no idea when. But... Why. Oh WHY would ANYONE pre-configure /boot to be this incredibly tiny!?

No wonder the new init ramdisk couldn't fit in there! Its already used up from 64%!

Thanks, Raspbian Devs, now I gotta reinstall the whole system because, yes, the /boot is, of course, sector 8192. Just far enough from 2048 that there are *some* sectors free - About 3 MBs.

So what did I try? Remove the partition and recreate it from the very beginning. Only... I never tried in in the past, and okay, kernel doesn't like having the partition where its image resides deleted on the fly, it will not give up FDs pointing there or something.

So now, I have a system I cannot reboot, or it will never boot back up :|

Thanks, Raspbian!

I need to get a cheap 1U somewhere or something T.T