Stuff done to the machine so far since the last maintenance run:
* The sound card's audio jacks needed some contact cleaner.
* The sticky optical drive door needed rectifying.
* The RAM sticks needed cleaning.
* System drive defragmentation.
This one I caught a few hours ago: happened while archiving some Nintendo 64 ROMs.
Miraculously, the initial transfer from two days ago did not corrupt any of them (those are big endian; also lucky, because there is no local mirror...), but copying them for the byte-swapped conversion set directly on the server corrupted one ROM in that copied set. This is becoming much less frequent, at least.
Checked RAID5 status, array is fine. This issue shows up over a wireless network; should try wired network and local transfer... and probably examine the SATA ports on the motherboard, among other things (which I may eventually replace anyway).
Found the telltale sign re: bad data cable... it was on RAID5 drive 2 (layout: 0 - 1 - 2 - 3; drives are in order of manufacture date). That particular 4TB drive now has a UDMA CRC Error Count of 1, a recent happening during a bunch of large file transfers.
Since I replaced them all, this may no longer be an issue right now.
Almost forgot, was running into some file corruption issues for some time on the rebuilt file server.
First noticed the issue when I was creating some slipstreamed Windows XP CDs to use on the programmer machine.
It became worse when I was transferring data to that same server to store No-Intro ROMs; almost 20 ROM archives had bad CRC errors and the GBA pack had one corrupted file which wasn't present on the main laptop.
I eventually replaced all four data cables with some I bought a few years ago and were in storage for a bit less. Those replacements were originally meant for a compile box, but the box is now a laptop instead. ๐
I haven't run into the corruption issue since, but I'll keep watch for it. This is why I originally use an external hard drive to do initial work on, then send it to the file server later, but the external drives are not on hand right now.
Around January 2023, homebrew, pirate, and aftermarket stuff is no longer included by default. In my opinion, this is good, because is would be initially assumed that original commercial ROM and disk images would be present.
However, they can be added back in with different settings. I separated the aftermarket ones from the original sets in the /alt/ directory for now; may move those to /aftermarket/. Someday, I will grab the pirate ones as well; those need different settings.
Clarissa Walker (amisapphire@cwcyrix.nsupdate.info)'s status on Friday, 31-Mar-2023 21:48:53 EDT
Clarissa WalkerThe MIDI Box running Windows 98 Second Edition on an ASUS P55T2P4 board has had a CMOS/RTC issue for about two years, and more recently had issues booting in rare occasion; also had temp corruption within BIOS (would show Unknown CPU for AMD K6-2/500). Date/Time would also revert to Jan 02 1980 at 12:00 AM (and in more recent times, while Windows was running as well), though other CMOS data remained.
The board was pretty much fine before the 24-pin socket replacement, because the first replacement socket was a hack job (clipped 32-pin socket with edge bodge), and the original soldered Dallas CMOS/RTC's battery was long dead.
Procedure for the board:
Change CMOS/RTC to a spare - boot issues were gone though
Reflash BIOS and properly clear CMOS - no real change
Painstakingly remove board from old case and reflow the replacement socket - this seems to have fixed the issues
It's been a little over a week, and the aforementioned issues have not yet returned.
Timeline:
Jan 5: Obtain Linksys E8450, convert it to OpenWrt, run into connectivity issue
Jan 6 - Jan 14: Initial troubleshooting and notes, flash OpenWrt 22.03.0-rc1; this delays wireless network migration
Jan 14 - Jan 16: Initial look into source code
Jan 16: Find forum thread on OpenWrt forums
Jan 26 -29: Second look into source code and more testing finds this issue was actually introduced in 22.03.0-rc2
Feb 5: Issue filed
Feb 20: workaround introduced by xNUTx
Feb 23: someone runs into same issue on OPNsense LAN bridge
Feb 26: xNUTx realizes they were on bridged LAN (accidental confirmation)
Feb 27: Third look into source code finds suspect commit
Feb 27 - Feb 28: Removing suspect commit fixes issue
Mar 1: Fully migrated to new setup running patched 22.03.3
Supposedly a FreeBSD change requires you enable link-local on bridged LAN in order for IPv6 to work since 13.0; before this version, it was not needed.
Probably a proper check for people that do not want a link-local address showing up in devices for which the network in question is not utilizing IPv6 at all, which makes some logical sense.
As it stands, the migration to OPNsense 23.1 is truly a success.
...Apparently IPv6 routing is broken in recent OPNsense versions with bridged LAN ports (and IPv4 to some extent) so we're back on OPNsense 21.1.9, but on an SSD instead! So a success, except for that routing problem, I guess.
You would have to use a proper switch for extra ports from now on, at least until that issue gets fixed.
I am going to migrate the firewall that is handling all connections, especially this very server, from old-ish reliable 21.1.9 to the latest future 23.1 in February.
This requires manual setup and not an upgrade, so some downtime is expected. No ETA on when this will be done just yet.
Okay, the system lives once again. Yeah, I freaked out because there is years of stuff not on the main server yet from that Windows install. Thinking the cumulative Windows update was actually installing despite the WinApp saying Downloading 100% after other updates that require reboot have installed (and you could restart the system in the process). Pressing Restart the System does interrupt this install process after confirmation...
Restoring the Windows 10 partition was a success. No more odd system hangups and stuff seems to download from Windows Update normally. Now to see what happens after this. So odd. If this happens again (somehow), may as well use a Linux distro on it; I still have all the data for the Windows install.
Bought a Linksys E8450 recently and ran into a showstopping bug regarding wireless clients and communication on later OpenWrt 22.03 releases and even very recent snapshot versions. Flashed 22.03.0-rc1 and wireless communication and clients now work normally without the static ARP workaround. This took a week to troubleshoot, too.
After all that, the Intel NUC's SSD's Windows partition really became corrupted. Luckily, I mirrored the entire disk a month prior. Actually, that backup is the most recent because it hadn't been used since last month; I was testing Kubuntu 22.10 in live mode on the NUC, then eventually went back to Windows 10. Ran a Windows update, then it wouldn't boot after a restart. ๐ฎ Now, I'm restoring just the Windows partition to see what would happen.