This actually delays the migration by about a week. It may also need a firmware update - specifically, a may not occasionally boot scenario.
I also had an idea: relocating the database to another drive... again. I did this last time and it was a success, but it was with 2x 80GB IDE drives as a dm-integrity RAID 1 test.
The database is on the same drive setup as the rest of the webserver data... which is not the system drive.
And... it also seems that I finally managed to get the board to keep its BIOS settings.
That literally took over an hour to solve that.
It originally started with it not responding with the power button, then eventually I walked off to retrieve something (over two minutes), then tried again and realized it powered on...
Set the time and date, exit, power off the board then the PSU... wait ~2 minutes, power on the PSU, then the board. Forgot its settings.
Repeat this ad-nauseam between testing RAM for errors and CPU temp. Oh, and the display would glitch up at times. May have to retire that particular old Sony SDM-HS94P monitor.
Earlier, I disabled the BMC by jumper; the BMC was still zombie-enabled, but now the BIOS would no longer acknowledge it. Odd.
Eventually jumpered the Chassis Intrusion setting and then used the Set User Default settings in BIOS. From there, BMC was no longer running...
The board is in standby; it needs a SATA drive before the system migration.
Ran a memtest, left for ~15 minutes, returned and saw that the CPU hits ~70° C on load... and that's on an open 'case'. Will repaste the CPU, but I may replace it with a Xeon E3-1270 at some point anyway.
The board works, though its IPMI is also very old and insecure. [Version 1.86! Latest official is 3.52 (was 3.38 but someone YOLO'd and is official now), though 3.64 exists.]
Since I'm not going to bother updating it like I did with the OPNSense board, I'll disable it on the board with the jumper settings instead for now.
Found out the other old drive CD image is questionable as well. Going to have to re-download it. So both 2021-era driver CD image downloads have mismatched checksums...
Forgot to mention: found one questionable file (possibly slightly corrupt). It was a driver CD image. Moved that one to 'questionable'.
One BCM/IPMI firmware was repacked and a few third-party source files were loose, so I repacked them into RAR files.
There actually was one official BMC/IPMI .zip file that was packed a little over a week before the known good checksum one, so it was moved to 'old'. The files themselves matched the ones in the known good one, too.
Anyway, found some missing BMC firmware and one newer BMC firmware on the Internet. I am also obtaining the rest of the driver CDs, since an earlier attempt was done when I didn't even have enough space in general.
I was just made aware that the Rev. C2 version of the AMD Phenom II X4 945 can be 125W TDP (most are 95W TDP), so that part is correct. So it does not account for the 95W Rev. C2 or C3 version of the CPU...
I went through the trouble of setting up a test server on a MiniPC (Intel NUC NUC6AYH), and it does run there. Though, I forgot to run lscpu for the instruction flags... so I searched for it online, and that NUC's CPU does indeed have the flag.
I then actually compiled the source on an even older Dell Latitude D830 and executed it. Same illegal instruction (SIGILL) as on the aging server. It does not have the flag.
It does run on my main laptop that has a high-end Sandy Bridge CPU, which has the flag.
--
From the AMD server and main laptop logs:
MariaDB 11.4: InnoDB: Using generic crc32 instructions
MariaDB 11.8: InnoDB: Using crc32 + pclmulqdq instructions
However, I found an old .tar image of the server 'www' data from September 6, 2023, taking up ~548 GiB on the www-data RAID setup. (The final one is .xz'ed, taking up ~449 GiB on the NAS.) Thought I purged it years ago, lol.
There's also some old HP laptop disk image on there from 2014 that I have never removed, taking up ~109 GiB; since copied to the NAS years later.
Another ~800 GiB used up there is a bunch of Teknoparrot ROMs just sitting there as well.
Very old versions of MySQL sit there; no longer can use them since the move to MariaDB.
There's more decade [plus]-old cruft on that setup that existed ever since the server used a 4x 250GB RAID0+1 setup in the early 2010s. Removing a lot of it would free up probably ~2TiB of space.
Somehow, one of the PHP -FPM configs wouldn't stick (I changed the listen user/group entry to what httpd is using and it was stuck on default nobody...). I had to edit it locally and not from my laptop. 🤨