Yeah I figured there would be multiple answers for you. Just keep in mind that you DO want to get it fixed at some point to use the disk id instead of the local device name. That will allow you to change hardware or move the whole array to another computer.

Are you sure about that? Ever hear about this supposed predictable network names in recent linux versions? Yeah those can change too. I was trying to set up a new firewall with two internal NICs plus a 4-port card, and they kept moving around. I finally figured out that if I cold-booted the NICs would come up in one order, and if I warm-booted they would come up in a completely different order (like the ports on the card would reverse which order they were detected). This was completely the fault of systemd because when I installed an older linux and used udev to map the ports, it worked exactly as predicted. These days I trust nothing.

OP – if your array is in good condition (and it looks like it is) you have an option to replace drives one by one, but this will take some time (probably over a period of days). The idea is to remove a disk from the pool by its old name, then re-add the disk under the corrected name, wait for the pool to rebuild, then do the process again with the next drive. Double-check, but I think this is the proper procedure…

zpool offline poolname /dev/nvme1n1p1

zpool replace poolname /dev/nvme1n1p1 /dev/disk/by-id/drivename

Check zpool status to confirm when the drive is done rebuilding under the new name, then move on to the next drive. This is the process I use when replacing a failed drive in a pool, and since that one drive is technically in a failed state right now, this same process should work for you to transfer over to the safe names. Keep in mind that this will probably put a lot of strain on your drives since the contents have to be rebuilt (although there is a small possibility zfs may recognize the drive contents and just start working immediately?), so be prepared in case a drive does actually fail during the process.

That is definitely true of zfs as well. In fact I have never seen a guide which suggests anything other than using the names found under /dev/disk/by-id/ or /dev/disk/by-id/uuid and that is to prevent this very problem. If the proper convention is used then you can plug the drives in through any available interface, in any order, and zfs will easily re-assemble the pool at boot.

So now this begs the question… is proxmox using some insane configuration to create drive clusters using the name they happen to boot up with???

One promising item I found are some json files from Reuters…

This one provides info on the candidates and the key for state ID’s: https://graphics.thomsonreuters.com/data/2024/us-elections/production/events/20241105/metadata.json

This one seems like it will provide the ballot counts(0) and possibly any declared winners(1): https://graphics.thomsonreuters.com/data/2024/us-elections/production/events/20241105/summary-votes/president.json

Of course I won’t know anything for sure until tomorrow evening when states start releasing their counts, but I went ahead and wrote up some code to use the files. It’s something at least, and the Reuters data should be fairly timely. I hope to play around with the collected info in real time, then maybe next election I can re-use the same code.

Yeah I found the same on the AP data. I also found that reddit thread, but haven’t been able to find a valid URL for this year’s election. Maybe they don’t make it available until voting starts?

Hmm good idea, I’ll take a look into that!