💾 Archived View for fuwn.me › blog › the_daily.xml captured on 2024-12-17 at 11:00:59.
⬅️ Previous capture (2024-09-29)
-=-=-=-=-=-=-
<?xml version="1.0" encoding="UTF-8"?><rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><link>gemini://fuwn.me/blog/the_daily</link><generator>locus</generator><lastBuildDate>Sun, 10 Nov 2024 01:12:52 +0000</lastBuildDate><title>The Daily</title><atom:link href="gemini://fuwn.me/blog/the_daily.xml" rel="self" type="application/rss+xml" /><item><guid>gemini://fuwn.me/blog/the_daily/airpods_4_anc</guid><pubDate>2024. 10. 24.</pubDate><title>The AirPods 4 with ANC are impressive!</title><link>gemini://fuwn.me/blog/the_daily/airpods_4_anc</link><description># The AirPods 4 with ANC are impressive! I've owned a few sets of AirPods since their initial release, and they've always been some of my favourite audio appliances. With the release of the new AirPods Pro 2 and AirPods 4, I thought it was time to pick up a new pair. I initially purchased the AirPods Pro 2, but the pair I received had the infamous audio imbalance issue where the audio panning is constantly stronger to one side or the other. In my case, the left side was noticeably skewed to the left. I wasn't going to just give up, so I picked up another pair the next day and returned the first pair, and the second pair also had the same exact issue! At this point, I didn't want to try my luck a third time, so I went for what is mostly a side-grade, which is the AirPods 4 with active noise-cancelling. From what I am aware, the AirPods 4 with ANC are missing very few features when compared to the AirPods Pro 2. They lack the clinical hearing aid and hearing test functionality and the ability to adjust the volume using the stem controls on each AirPod. If I missed anything, it likely wouldn't matter to most people, but I don't think I did. I actually highly prefer the classic AirPod design without the silicon ear tips over the Pro design. Even though I often use both designs throughout the day, I still find myself escaping back to the classic more and more. With the AirPods 4 with ANC being an even better choice this generation, I could finally and confidently ditch those annoying ear tips. I've been testing out the active noise cancellation on the AirPods 4 for about a week now, and they are really impressive. They aren't 1:1 with the Pros, since they lack the silicon ear tip to seal the audio in, but they are very close. The AirPods 4 do an excellent job at cancelling out low and steady sounds, and are effective for higher frequency sounds as well. The active cancellation range does get noticeably better the further you move out, with anything about a metre out typically being silent, and anything closer in depends on its frequency. I'd rate the AirPods Pro's ANC at around a 7.5‒8/10, the AirPods 4 at a 6‒6.5/10 for high frequency sounds, and again at a 7.5‒8/10 for low and steady sounds. Some other compliments I have are that the battery life is great and lasts me a fantastic amount of time; the charging case is nice and small for pocketing; and the shape of the AirPods make for a comfortable and secure fitment. </description></item><item><guid>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_1</guid><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><link>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_1</link><title>NVMe Troubles Part 1.</title><pubDate>2024. 06. 17.</pubDate></item><item><title>NVMe Troubles Part 2.</title><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++! ## Addendum #2 This blog thread continues on in the third part! => /blog/the_daily/nvme_troubles_part_3 NVMe Troubles Part 3.</description><guid>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_2</guid><pubDate>2024. 06. 17.</pubDate><link>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_2</link></item><item><pubDate>2024. 09. 03.</pubDate><link>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_3</link><description>=> /blog/the_daily/nvme_troubles_part_2 Previously on The Daily: NVMe Troubles Part 2. # NVMe Troubles Part 3. This may not be the crash and burn scenario you were expecting after this three part series, but you might be surprised to learn that the NVMe drive is still up and running months later after some "questionable treatment". I'll also mention that the events of this post are about two months old, but the process wasn't too complicated that I'd forget the details. You'd also expect that I would have gotten around to finally fixing the Btrfs partition just before I wanted to install the long awaited NixOS, but, no, I actually just had a spurt of motivation sometime in the AM. ## The Repair At this point in my Btrfs filesystem saga, I had tried all but cloning-wiping-restoring my partition and/or NVMe and `btrfs check --repair`. I can't recall the exact message, although, with the amount of times I've seen it at this point, I should, but the message that `btrfs check --repair` usually gives is something along the lines of "Only run this command if you are OK with losing your data or a Btrfs developer tells you to."—I think. I didn't want to deal with the cloning BS, so I'll bite the bullet and go with Btrfs's obscure repair functionality that **absolutely no one** advises using. To prepare, I wanted to save at least some of my data. I don't actually care about any directories on my system apart from my home directory and some `/etc/` files, so I'll back them up accordingly. During my backup endeavours, I tried a few methods, but ultimately, I wasn't satisfied with any of the results. One method was `rsync`-ing everything, another was zipping everything into an archive, and I also tried plain copying. One annoyance was that I was cloning from a Linux filesystem to a NTFS one, which was giving me all kinds of pain with file permissions and other metadata. I also ditched `rsync` and zipping in the end, because they didn't produce the expected results in one way or another. Backing up from userland is not fun, I guess. That, and I already had sunk a few hours into the ordeal, so it just wasn't worth my time. By this stage, I think my exact thoughts were "Screw it, `--repair` can't be that bad. It exists for a reason." I run the forsaken `btrfs check --repair` without any remorse. Maybe it was the adrenaline, but the repair felt like it had gone through almost instantly. It couldn't have been longer than around a minute or two, at the absolute most. In these moments of post-repair bliss, I ran `btrfs check` to verify if the repair had done anything at all, and the previous errors were nowhere to be seen. I also did some digging in the mounted filesystem, and everything seemed to look and function just how I left it. Booting back into Arch also went fine, not that I couldn't before, but I was just making sure I hadn't screwed anything up again. Functionality, I gained nothing, since the filesystem and drive still worked perfectly fine, even with the inode errors screaming at me; however, I'd now finally be able to modify the drive through GParted. If I hadn't mentioned already, GParted runs a `btrfs check` before any operations on a Btrfs partition, which is why I'd eventually need to repair the partition to continue on with my plans to install NixOS, so I spared future me the trouble. ## The Aftermath I used my system like normal for a few weeks, after which I went on a month long holiday abroad, away from my rig, and I wasn't about to attempt to install NixOS via SSH, although, the steps to do so are documented within the NixOS installation instructions. Spoiler alert, but I did install NixOS, and I'm currently writing this post on it. It's definitely the best Linux distribution I've used so far, and just from the short experience I've had with it, I can tell you that I can't see myself ever using anything else. I might write a post about it soon, so keep an eye out for that. ## Conclusion I won't go as far as to say use `btrfs check --repair`, but if a filesystem has strictly inode-related errors, I think it might be the quickest, and possibly even safest, way to fix them. I could have just gotten lucky, but I'm not one to tempt fate, so I'll just leave it at that.</description><title>NVMe Troubles Part 3.</title><guid>gemini://fuwn.me/blog/the_daily/nvme_troubles_part_3</guid></item></channel></rss>