gemini - kennedy.gemi.dev

💾 Archived View for fuwn.me › blog › the_daily.xml captured on 2024-08-25 at 00:34:34.

-=-=-=-=-=-=-

<?xml version="1.0" encoding="UTF-8"?><rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><lastBuildDate>Sat, 27 Jul 2024 12:01:34 +0000</lastBuildDate><generator>locus</generator><link>gemini://fuwn.me/blog/the_daily</link><title>The Daily</title><atom:link href="gemini://fuwn.me/blog/the_daily.xml" rel="self" type="application/rss+xml" /><item><link>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_1</link><description># NVMe Troubles Part 1.

This is the second time my primary NVMe drive has failed on me in some way in the past couple of months. I’m going to go ahead and dump this here on AniList, because it was the first page that was open on my iPad.

I wanted to create a temporary partition where I would install NixOS, just for fun to see if I would make the switch from Arch. During the resize, I was met with an error that I had inode discrepancies for a file and a folder. Of course, this was what I assumed to be related to source controlled temporary blob storage caches. I honestly should’ve been expecting this, as I have seen a ton of Btrfs related source control issues regarding inode discrepancies, especially with git and Chromium’s messy file system dumps.

Anyway, I spent probably a good 3–4 hours trying to fix this inode discrepancy, but I was getting nowhere. Eventually. I had the smart idea to run a SMART test, but this literally froze my system and eventually led to me completely turning off my system. SMART *shouldn’t* be problematic if prematurely terminating any processes, so I went ahead and did it.

Long story short, my drive was nuked … or at least I thought.

I could not boot into anything. Nothing would work. Between this phrase and the following paragraph, I was checking every possible forum, video, and thread, and they were all dead ends. I started to search for drive cloning methods, and I was a few clicks away from purchasing a new NVMe along with an M.2 drive cloning rig. I was even close to resorting to data recovery services if I so had to.

The first thing I tried was my GParted "LiveCD" USB drive, and this should always be anyone’s go to anyway. Well, GParted would not even boot. I don’t actually know why this was the case, even now, but something about the Wi-Fi drivers on their Debian release wasn’t working. I don’t even use Wi-Fi in the first place, and this shouldn’t be coming from my NVMe situation, since this is a LiveCD. After some trial and error, I realised that loading the environment into RAM got it to boot. GParted could not even see my NVMe, after all of that.

I backed out to the BIOS, and the BIOS couldn’t see my NVMe a bit. Eventually, after a series of power cycling and leaving the NVMe to rest a few minutes, (this probably didn’t help) I was able to get the BIOS to recognise the drive. I tried to run a self-test, but that self-test failed every single time.

Now, knowing that the NVMe is still visible to the motherboard, I booted back into GParted, but now, even my RAM trick wasn’t working. This too, after a few power cycles, was solved and able to boot. I’m not sure why.

As I make this post, I was successfully able to mount the supposedly "failed self-test" ridden drive, and I am able to see the entirety of my root file system.

What did I learn? I’m never choosing Btrfs again … *maybe*. In theory, it's great, but in practice it seems to lack stability in seemingly simple cases like this. (?) I think I'll go with XFS for NixOS, so I can stay on the edge, but Ext4's stability is appealing, and I've used Ext4 for a great deal of other devices and servers before in confidence. I still look at Btrfs with hope, but I just can't look at it with the same kind of hope after this nightmare scenario. I’ll also purchase one or two extra NVMes just in case, and perform regular full-disk backups. And I now want to switch to NixOS more than ever just so I can get rid of this broken Btrfs partitioned file system.

=> https://media1.tenor.com/m/2eFcSj58UhwAAAAC/head-bang-frustrated.gif

## Addendum

This blog thread continues on in the second part!

=> /blog/the_daily/nvme_troubles_part_2 NVMe Troubles Part 2.</description><guid>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_1</guid><pubDate>2024. 06. 17.</pubDate><title>NVMe Troubles Part 1.</title></item><item><link>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_2</link><description>=> /blog/the_daily/nvme_troubles_part_1 Previously on The Daily: NVMe Troubles Part 1.

# NVMe Troubles Part 2.

OK! I've managed to boot back into my Btrfs filesystem. The bitrot (I guess) is still present, but I don't mind. I think I'll end up moving my secondary OS over from my primary NVMe to my secondary NVMe, then create a NixOS install in-place of that partition, clone my essential files over from my primary NVMe's Arch install, and then nuke the Arch (Btrfs) partition for good.

=> https://i.imgur.com/5WiE6Xs.png
=> https://i.imgur.com/nyJ2IPN.png

## Addendum

I failed to mention the information about my Windows partition and what troubles came with it! I also failed to mention that I was unable to boot into my primary Arch Linux installation because systemd-boot had been wiped from my EFI boot order. Here is that discussion continued.

I have a small Windows 11 partition that I exclusively use for gaming. This partition is actually running AtlasOS, a modified Windows "distribution", but that isn't too important. I don't keep anything on this install other than games and a browser.

Throughout my scrambling to revive my NVMe, and after I had been able to get my BIOS to recognise the NVMe, the only boot entry that was available other that my GParted live USB was the Windows Boot Manager entry belonging to this OS. I don't know why this was the case, but I assume that it was some safety mechanism for Windows to wipe out the rest of the order, since I have had Windows overwrite my boot entries before.

Anyway, at some point, I tried to launch into Windows using this boot entry, but I was getting instant system failures. After trying to get through about three times, I was prompted with a new screen that gave me a few options, such as navigating back to my BIOS interface, or trying to boot into Windows. I tried booting back into Windows, and I was met with a BSOD so fast that I couldn't even see the message properly. I went ahead and tried to record my screen using my phone, and I was able to retrieve the BSOD with an error status of 0xc0000001, and some information telling me that my Boot Configuration Data was in a terrible state.

At this point, I gave up, as both the information on Windows' system failure screen and the information I found online was letting me know that I'd had to flash a Windows installation media to a USB to access any usable troubleshooting tooling. Thankfully, skipping over some that I've already in the original post above, I was able to boot into my primary Arch Linux installation and use it like nothing ever happened, minus the bit-rotted directory.

Fast-forward about a day. I'd like to play Wuthering Waves, so I have to boot into my Windows install. Windows still doesn't work, so I have to fix that.

I got around to flashing the AtlasOS installation media to a spare USB and getting into the troubleshooting menu, and after attempting the automatic rescue, a load of command-line tools, and more guides, still, nothing could bring back my system. My final resort was to try the System Restore functionality of Windows.

I'll preface this segment by outright stating that I have not once ever had a successful interaction with the System Restore feature. I've had two instances where a Windows installed potentially could have been saved by one, but in neither case did the System Restore either help, or even work due to the System Restore point itself being corrupt. In the past, I have disabled this feature from the first available moment, as to not waste my time and "drive space".

Whatever, I'll give it a try. I opened the system restore menu, and I was extremely surprised to see that I had a few points I could restore from. The latest one was from either the 8th or 9th of June, 2024, so that would be about ten days away as of the writing of this addendum.

> If anyone is wondering, this System Restore point was one made by some version of the Microsoft Visual C++ Redistributable, and I actually remember that the Lossless Scaling application from Steam requested this resource.

The System Restore feature has this feature that allows you to view the programs affected from this would be system restore, so I clicked it. Apparently, some registry, and I'm not sure exactly which, since I've been hit with a boat load of these types of messages by now, but some registry was corrupted and beyond saving, so I could not check which programs would be affected by this would be System Restore point.

That doesn't inspire confidence, but screw it, it can't hurt to try it anyway, right? So I give the installation media the go ahead to try and apply the restore point. What do you know it, the system goes through a short, roughly three minute process of applying this restore point, and then another short reboot, and I'm back in my Windows installation as it was the day it left me.

From what I was informed by Windows, System Restores don't touch your personal documents, and I don't keep any in this partition anyway, but I now had my system fully back in operation. Between the less than ten days between now and the System Restore point's capture date, the only part of my system that changed was literally the removal of the Visual C++ Redistributable. So System Restore **is** a valuable feature!

Let's reflect. Why does a SMART status check render an NVMe unrecognisable, wipe the first boot entry (systemd-boot, in this case), cause Windows to destroy its own BCD (Boot Configuration Data), and more? (I could go on, but I've already written about it!) Who knows! I don't think we'll ever understand the black system that we call practical computing.

> Thanks, Lossless Scaling for requiring Visual C++!</description><guid>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_2</guid><pubDate>2024. 06. 17.</pubDate><title>NVMe Troubles Part 2.</title></item></channel></rss>