💾 Archived View for fuwn.me › blog › the_daily › nvme_troubles_part_2 captured on 2024-08-18 at 18:04:49. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-07-09)

➡️ Next capture (2024-08-25)

🚧 View Differences

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

https://ruu.neocities.org/images/animeHeader.gif

NVMe Troubles Part 2.

Author: Fuwn

Created: 2024. 06. 17.

Last Modified: 2024. 06. 19.

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++!

Quick Links

Home

Skills

Contact

Blog

GemRest

Search

Web-to-Gemini Gateway

Finger Gateway

Sitemap

Useful Links

Footer

"I learned very early the difference between knowing the name of something and knowing something." - Richard P. Feynman

Gopherhole (Gopher)

Finger Server (Finger)

Onion Service (Tor)

Eepsite (I2P)

Copyright (c) 2021-2024 Fuwn. All rights reserved.

Any and all opinions listed here are my own and not representative of my employers; past, present, and future.