Thanks.
> My understanding was that if CMOS was dead, so long as the PC could boot with default BIOS settings, it'd boot.
That was mine too, but I found enough results to suggest it was worth swapping the battery, and I thought it was a simple task.
Given I haven't changed the battery before, it's at least 15 years old - well past the 10 year lifespan on the pack of CR2032s I have.
Although I might have read that it was removal of the battery to reset a corrupted BIOS which was the solution, in which case merely disconnecting then reconnecting might be enough - though even if that works a spare seems a good idea.
--
> I assume you've done the reseating dance, pulling out and reseating every connector, SATA cable, RAM card etc.
It's a large notebook form factor and I have limited space, so that's a complicated dance, and not one I was willing to even contemplate last night.
It's not the hard-drives: they all work fine in an external dock, and it doesn't boot with them removed.
I'll start removing/reseating other bits after I've had some lunch, and see if that reveals any further clues.
There's three RAM chips, all in awkward many-screwed places, but a single bad chip would be 12->8 which would be annoying but probably not a disaster.
If it's graphics card, they seems to be in region of £100..200 on Ebay - and hopefully, if it is that, I can find a compatible replacement and it doesn't trigger the Windows Activation bollocks... :/
Since removing the optical drive there is no discernible noise.
That's the service manual for a Clevo 3220, which is an unrelated model.
Neither the Clevo D900F Service Manual nor Clevo D900F User's Manual mention beep codes - the latter does reference a "Power On Boot Beep" option in the BIOS, which is either off or not occurring (I think it normally beeps, but I'm not certain - it's usually the whir of the fans I listen for).
So far I've removed the optical drive, keyboard and RAM chip under the keyboard, with no differences (other than the drive not whirring).
Currently trying to figure out how to get at the part where the CMOS battery connects.
Was hoping to spend January making it sufficiently usable, so I can relegate the last Windows machine to graphics and music (since there are still no good Linux equivalents to Cinema 4D, Lightroom, Music Bee, Paint Shop Pro.)
Except I also have a bunch of other tasks that needed doing ASAP, and now this is yet another blocker on top of the stack.
If I can't make progress in figuring it out today, I'll have to accelerate work on the replacement, transfer the Windows stuff to a VM, and hope I can get everything important going quickly enough without making compromises. (Like why the fuck does a PDF viewer have PulseAudio as a dependency. :@)
It's not a direct depends - comes via phonon4qt5 - "a task-oriented abstraction layer for capturing, mixing, processing, and playing audio and video content."
Since Okular doesn't support any audio or video formats, I don't know why it thinks it needs that, and haven't yet checked if there's a compile option to ignore it.
Main problem with Mupdf is the lack of table of contents.
So either the battery is dead, or it's the graphics card that died, or something else.
Or I undid a vital wire/ribbon that I forgot about and didn't reconnect.
The poorly named qpdfview has fewer dependencies than Okular (is only Qt instead of KDE), but depends on Cups, which I'll need to recompile to remove Avahi crap.
I disconnected the graphics and RAM, but neither had any effect on behaviour.
Trying to get anywhere with the supposed replacement machine is roadblock after roadblock, with a few brick walls and dead-ends thrown in.
Everything sucks. Anything that seems good is a lie or a temporary illusion.
:(