Close, but not quite enough info. This is on RHEL 7 however I checked on Ubuntu as well and bingo:
usbcore: registered new interface driver DS9490R
What the heck RedHat? Beaten by Ubuntu, lol
The stick is a DS9490B so now we at least know what the heck it is.
I thought to myself that the “battery” looked a bit odd shaped but it’s a damn iButton
So copying the key, as originally thought, won’t be an option. Somewhere in googleland I stumbled across a comment that said the lifespan of these are ~10 years, so we’ll have to call SEGA if the key would fail. But I’ll double-check if that’s true or not.
But I’ll play around and with this iButton a bit and get more familiar with it, I’ve never even heard of this but my friend apparently new.
; “It’s some fucking iButton chip”
; “iButton? Yuck! Talk about grotesque devices, I forgot those were a thing! LOL”
Yep that’s something to research, I couldn’t get a copy of the drive yet since my hub is at home and I’ve been hanging around the warehouse . Sure an arcade version of a game could be totally different from the PC version since those are more locked-up but I’m keeping my hopes up that when I get my hands on the drive we’ll figure something out. If not, at least we’ll be smarter lol.
I did briefly throw in an SSD that had Fedora in it but that didn’t boot, most likely because the version installed is 64bit, weird tho that there was no output signal from any of the VGA ports, even on an external monitor instead of the built-in CRT, the monitor wouldn’t even wake up at all… usually it should at least nag that “this is a 32-bit machine”
Also I can’t boot from an external drive either since there’s no access to BIOS, so I’m still stuck needing to copy the drive.
I copied the HDD to a spare Kingston SSD, that worked out fine. System booted and the arcade machine worked without problems.
However, now that we ordered two SSDs ( 850 Evo ) to replace the HDDs with, those won’t work for some reason, system won’t boot…
The files are there, just checking through the data with a disk utility and a file manager everything seems right: partitions, files, what have you.
A dd copy of the original HDD to the Kingston SSD comes out fine, when comparing the sha256sums & md5sums of 512B sectors with dcfldd the copied SSD is identical to the original HDD.
But.
On the Samsung ones only the 3 first 512B sectors passes the sumchecks, no matter how many re-tries copying the data from the original HDD, the Kingston SSD, or an img to the 850 Evo’s, the sumchecks always fail after the 3rd 512B sector…
EDIT: Both the Kingston & the Samsungs have the default 512B sector size
EDIT2: Fixed typos, sorry for updating the thread
That is odd that they are not aligning properly. You may need to format, then trim the drives and then try again if the firmware upgrade does not work. or, use the Kingston for the cab and add the Samsung to your shiny new part storage.
And what DD command are you using? You may need to force the 512 block size with bs=512B
