Keyboard Boot Virus?

TTman snipped-for-privacy@gmail.com wrote in news:t3j7hd$h2v$ snipped-for-privacy@dont-email.me:

Brilliant.

And oh... that was a troll post. IF a "ChkDsk finds "problems" on an SSD...

The SSD is blown. Probably from stupid use of ChkDsk way too many times or even an idiot "defragging" his drive. Neither of which is needed on an SSD. Ever.

I have had plenty of stuck keys. I tried to check by pressing all the keys to see if one was stuck on or jammed. None were.

A fault with the Enter key is possible, but it would scroll the screen up. This problem is completely different. The entire screen flashes then flashes again. What key would do that?

The "clear screen" key perhaps?

That appears to be a hidden key on the keyboard, although it appears in DOS and all versions of windows starting with 95 as CLS. But it actually clears the screen and only leaves a prompt.

Well, it's not the processor (swapped out) or bios (reflashed). Re-cycled PSU, in the off-chance that the new one was to blame, but made no difference. Optical drive has failed in the meantime. Rechecked harnessing. Reran memtest.

Am at point where I'm reinstalling OS fresh with each attempt. Gets to the time zone and password settings, then shuts off in the next process (of hardware enumeration?).

Time to shut it down for good.

RL

Could be a bad solder joint, broken trace, etc. Too much trouble to chase down, definitively.

Ah. If you'd been able to install it successfully *once*, then taking an image would save you the trouble of going through MS's painfully slow installer.

Yup. Take it out back and shoot it.

Nowadays, most machines aren't very expensive to replace. All the real "value" is whatever YOU have added to the disk drive...

I've very little patience for tools that don't perform as expected. Hardware is usually pretty easy to identify as faulty (swap out, try a second instance, etc.). Software is a PITA as you tend to be dependent on the supplier to fix bugs. And, most suppliers' process is to just give you a NEWER set of bugs!

Moral: identify quirky behavior and discover ways to work around it or compensate for it instead of perpetually replacing one known behavior with a new yet-to-be-known behavior!

Take the opportunity to "treat yourself" :>

One of the weirdest hardware oddities is an industrial motherboard (with soldered in cpu) that appears to work fine with Windows but will not complete the installation process for Linux (I tried several varieties). Its definitely not the memory or power supply or BIOS version or settings (or the keyboard). Needless to say I don't trust it running Windows either so its on my scrap pile. I have another one, bought at the same time and configured identically, which works fine with both. John

Windows tries very hard NOT to complain about hardware. I guess the thinking is that the user wouldn't be able to do much *if* it complained. And, would likely see *windows* as The Problem.

Often, the only way to expose a hardware problem, in Windows, is to go *looking* for it (logs, etc.). Even "failures" tend to be "polite" (write error; your data is lost!)

OTOH, my UN*X boxen tend to complain, more, when they encounter odd situations (like an intermittent SCSI cable). I suspect the folks coding them weren't as tolerant of "unexpected events".

Yeah, if you've *seen* it screwup, how can you rationalize ignoring that fact?

I've got an AiO that I use as a "console" to talk to my archive/repository. It misbehaved, recently. Suspecting a failing disk, I replaced that. But, then determined the original disk to be functioning properly (so, the problem lies elsewhere!)

OTOH, as it is simply taking typed commands and passing them along to another node on the network, it is very unlikely that it will "silently" corrupt some of my SQL in a way that the other node won't detect as incorrect. And, simultaneously corrupt the reply from that node in such a way that I won't consider it suspect!

(i.e., if it screws up, again, I'll be there to witness it!)

I've always shuddered when I hear folks overclocking machines or using recapped motherboards; how do you know the system is really working as intended, now? If you rendered a 3D object, would you be able to tell if it messed up one of 100,000 polygons? Two? Five hundred??

I once had a PC/AT clone motherboard where the supplier had changed the main clock oscillator for a faster one. It worked fine for nearly everything, but a multi-channel audio acquisition board I had designed did not work properly. It turned out that the setup and hold times were completely wrong on the DMA channels so my hardware failed. After I replaced the oscillator with one having the correct frequency everything was fine again. In contrast, I once needed to use a TMS320C51 DSP at a combination of power supply voltage and clock frequency that was not allowed in the data sheet rules, but which looked as if it should work reliably. It was a medical application. In those days, TI had good technical support in the UK and I was given some test code which exercised the critical timing paths that were known to be the most likely to fail under voltage or frequency stress conditions. This was built into the power-on startup code, so each device was known to be happy with its operating conditions at that point.

John

Just trying to get it safe enough to stick a system HDD into it. It already ate one. The back-up will not work in new hardware, but I guess there's no choice. In cat years, it's no spring chicken. The LXLE dual-boot was intended to nurse the thing into it's golden years . . .was just teaching LXLE to print. Brings a tear to the eye.

A HDD is a place to stick your data, until it 'goes'. HDD rel has seemed to improve for me, particularly since the adoption of SATA. Sticking a reliable HDD into junk doesn't raise the reliability of the junk. A lot of things are built on crumbly foundations these days.

RL

Be thankful it was a hard/observable failure! Imagine if it had been intermittent -- plaguing your product "in the field"!

You've more guts than I. I like being able to point to a document and prove that my design is 100% compliant so any "problems" lie in the components being used. (regardless of temperature, power supply noise, etc.)

I like to dick with RESET on processors as it often lets me implement special features cheaply. But, RESET is often a poorly defined event. I can empirically verify that a particular design MIGHT work... but, have no guarantee that some mask revision won't break my solution.

Give me something that I can hang my hat on to justify to boss/client/customer that my approach has addressed due diligence... or, I'll look for another, better documented device -- or approach.

What is your goal AFTER that? Are you trying to recover data from some OTHER drive present in the system? Or, are you hoping to actually USE the system once the system drive is installed?

I keep external USB drive enclosures (and/or "docks") on hand to let me "mount" a drive on some other system -- without worrying about how the drive will dick with the hardware *in* that system. If the drive has a problem, then the DRIVE has a problem, not the system that I'm using to examine it.

PATA vs SATA? (hence the value of keeping external USB drives around as "test fixtures")

I still have small (megabyte!) IDE disks that power some of my older (collectable) kit. But, the total PoHr stays low because they don't see much use. And, as they are so small, it is easy to keep an image of the entire system around -- on something as small as a CD-ROM! <frown>

Newer drives (in my workstations) tend to run 24/7/365 so I'm potentially at more risk. But, most of the content on my machines is "applications" and "libraries" (of sorts). Which can be restored from their originals, if need be.

Consider moving the media into a NAS or SAN? The advantage being that you can share the media "for free".

People want features, not reliability.

And, developers often find improving reliability/robustness to be "interesting" -- compared to starting off in some NEW direction (on a new, half-baked feature).

My solution has been to "settle" for something known. And, then replicate it so I'm not reliant on a single unit.

I'm developing an aversion to attempting an LXLE dual boot system (with an MS OS). I'm looking at my HDD morgue and now see 4 dead HDD associated with such an endeavor.

Two were in Dell refurbs - now both still running with non-dual boot clones (WXP)in 2020, The other two are from this attempt in the PC Chips A13G+ v3.0 home-brew (W2K). This is now officially junk.

There are only two things in common; LXLE and me.

A Ubuntu single or dual boot (it doesn't seem to care - on separate hard drives) is still in progress.

Meanwhile, other obligations call.

RL

I'm having a hard time thinking that they are truly *dead* (as in "scrap"). Have you tried: dd if=/dev/zero of=/dev/r<drivedevice> bs=1024k count=100 just to ensure there's no cruft on it -- esp the boot/MBR area?

I used to run a "quad boot" tower -- {Net,Open,Free}BSD (not a fan of Linux, nor its license!) plus Windows -- when I was writing drivers. Back then, a 4G drive was $1K so it was easier to put 4 of them in a box than to try to share a single drive.

Now, I have a clean demarcation between boxes. It's a Windows box or a Sun box or a *BSD box... but never more than one.

You might consider running your non-windows boxen headless and installing an X server *under* Windows. Or, a bunch of VMs. I run an ESXi server for my VMs -- so any workstation can run any VM, served over the wire. Or, copy the VMDK onto the host and run it locally if A/V performance is an issue. (my VMs are on a big SAN)

Bottom line: figure out how to REDUCE your sysadmin tasks and the time wasted on them.

Always! It's a wonder we get ANYTHING done!

No, don't run X. X is garbage, always has been, always will be.

Lol, this clown has a "big SAN", but can't quite tackle NTP yet.

Say the guy running a "sun box", which is likely some 22 year old piece of s*it with no networking enabled.

This was a research project with less than 100 units being made and they were all under our control. There was no alternative device at that time that met our other constraints, so the choice was to make the best of what we had or do nothing. The fundamental problem was that TI had specified maximum clock frequencies at a couple of different supply voltages. We needed to operate at an intermediate voltage and intermediate clock frequency. The code was the same as TI used for production testing, so I don't think it was particularly risky - quite the opposite. ...

In an ideal world, yes, definitely.

John

I have not been following this thread very closely, but I will add one details: The source code for NTP is publicly available at NTP.org, is about 70,000 lines of plain C code, and have become a bit convoluted over the years. It would take a solid year to become reasonable familiar with that bit of code.

Joe Gwinn

Ah. I often have had to make "proof of concept" prototypes -- but, the approach that I took had to be able to move into manufacturing without significant redesign. So, I had to be able to defend the design as ready for manufacturing.

Other designs were intended for manufacture so not a good strategy to "hope" for something that isn't published (my contracts provide "free" fixes, indefinitely -- but, only for things that I have control over!)

OK, so you just wanted another point on an already bounded curve. You weren't trying to look beyond the horizon...

It needn't be an "ideal" world -- just one in which I am comfortable dotting i's and crossing t's. Warts are fine -- as long as they are visible and acknowledged.

You're using forte agent for your post. How many lines of code is it? Are you able to use the program without reading all the code?