diff options
| author | Fuwn <[email protected]> | 2024-06-17 09:09:54 -0700 |
|---|---|---|
| committer | Fuwn <[email protected]> | 2024-06-17 09:09:54 -0700 |
| commit | 9d4438c478640568d865367353483a0bf8757c8e (patch) | |
| tree | 8f704cb16e711861570f6596b42bb45404b5cb93 | |
| parent | build(nix): remove docker (diff) | |
| download | locus-9d4438c478640568d865367353483a0bf8757c8e.tar.xz locus-9d4438c478640568d865367353483a0bf8757c8e.zip | |
feat(nvme_troubles_part_1): update content
| -rw-r--r-- | content/blogs/the_daily/nvme_troubles_part_1.gmi | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/content/blogs/the_daily/nvme_troubles_part_1.gmi b/content/blogs/the_daily/nvme_troubles_part_1.gmi index 1c6ee17..1c43448 100644 --- a/content/blogs/the_daily/nvme_troubles_part_1.gmi +++ b/content/blogs/the_daily/nvme_troubles_part_1.gmi @@ -8,7 +8,7 @@ Anyway, I spent probably a good 3–4 hours trying to fix this inode discrepancy 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. +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. @@ -18,6 +18,6 @@ Now, knowing that the NVMe is still visible to the motherboard, I booted back in 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. +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
\ No newline at end of file +=> https://media1.tenor.com/m/2eFcSj58UhwAAAAC/head-bang-frustrated.gif |