aboutsummaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
Diffstat (limited to 'content')
-rw-r--r--content/blogs/the_daily/blog.json19
-rw-r--r--content/blogs/the_daily/nvme_troubles_part_1.gmi23
-rw-r--r--content/blogs/the_daily/nvme_troubles_part_2.gmi11
3 files changed, 53 insertions, 0 deletions
diff --git a/content/blogs/the_daily/blog.json b/content/blogs/the_daily/blog.json
new file mode 100644
index 0000000..1d50e22
--- /dev/null
+++ b/content/blogs/the_daily/blog.json
@@ -0,0 +1,19 @@
+{
+ "description": null,
+ "posts": {
+ "nvme_troubles_part_1": {
+ "description": null,
+ "author": "Fuwn",
+ "created": "2024. 06. 17.",
+ "last_modified": "2024. 06. 17.",
+ "name": "NVMe Troubles Part 1."
+ },
+ "nvme_troubles_part_2": {
+ "description": null,
+ "author": "Fuwn",
+ "created": "2024. 06. 17.",
+ "last_modified": "2024. 06. 17.",
+ "name": "NVMe Troubles Part 2."
+ }
+ }
+}
diff --git a/content/blogs/the_daily/nvme_troubles_part_1.gmi b/content/blogs/the_daily/nvme_troubles_part_1.gmi
new file mode 100644
index 0000000..1c6ee17
--- /dev/null
+++ b/content/blogs/the_daily/nvme_troubles_part_1.gmi
@@ -0,0 +1,23 @@
+# 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 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. I’m going to 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 terrible Btrfs partitioned file system.
+
+=> https://media1.tenor.com/m/2eFcSj58UhwAAAAC/head-bang-frustrated.gif \ No newline at end of file
diff --git a/content/blogs/the_daily/nvme_troubles_part_2.gmi b/content/blogs/the_daily/nvme_troubles_part_2.gmi
new file mode 100644
index 0000000..dbbaa2a
--- /dev/null
+++ b/content/blogs/the_daily/nvme_troubles_part_2.gmi
@@ -0,0 +1,11 @@
+# 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 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.
+
+Previous blog post in question:
+
+=> /blog/the_daily/nvme_troubles_part_1 NVMe Troubles Part 1.
+
+=> https://i.imgur.com/5WiE6Xs.png
+
+=> https://i.imgur.com/nyJ2IPN.png