Malware assault? Related questions
 

There are multiple hard drives (all are SSDs) in my box, and a switch allows use of one at a time. Drive One has (Slack 14.2) Linux 4.4.29 64-bit that has suddenly decided not to boot, and Drive Three was behaving well until a few hours ago, when it lapsed into total insanity (no commands work -- everything is "input/output errors", write-protected files, and chaos). When I try to boot Drive One, the text on the monitor remains large and blurry, and the boot process is abnormally brief; attempts to log in are ignored. I'd reinstall, but I would like to save some data that are on the SSD. Fussing with the boot process (ASUS UEFI Bios Utility) for Drive One has led nowhere. I'm writing from Drive Two, which runs Debian 8.5. Can I boot Drive One somehow, or possibly save the data on it without booting it? It would also be nice to know how I managed to corrupt Slackware so dramatically. Yes, I browse with prudence. TIA!

Hmm, please do not assume malware -- it helps nobody.
This sounds like either a SATA controller, motherboard or PSU issue. So, try to boot to USB and get the remains of your data backed up then remove most things from your system, boot, and see whether anything fails.

Hopefully you can mount the drives and get the data off. As root, run this:

To find out the names of your drives; e.g., /dev/sdxx and /dev/sdyy. Choose or create directories where you want to mount them temporarily; e.g., /media/hd0 and /media/hd1. Then mount the drives (replacing xx and yy with the correct characters):

When you are done copying files, umount the drives:

Note: I'm not sure if those /media/hd0 and /media/hd1 directories exist on Debian, but you can use any directories you want.

Also note: if this is a hardware issue, which it sounds like it might be, reinstalling won't do any good. Hopefully, mounting the drives will be successful so that you can back up the data.

Thanks for the info and advice!

What puzzles me: both Slack SSDs are in trouble, but the SSD running Debian is OK. ??

What puzzles me is how the "switch" change the SDD live ? Is it an official hardware dedicated for that or is it a custom made switch ?

Because when I hear (read) about HDD being shutdown live, I'm a bit scared about missing syncing etc... If it's a "brutal" switch it can mess up the very logical data of your disk (SSD or not). I mean theoretically, if you're controller is "smart" or your switch inform software (OS) to flush cached data and to complete any pending write it should be ok, and it's not clear by which "magic" your switch works.

This apply if it's a "hot switch" while your OS is running, obviously, if you switch HDD "offline" while the computer is shot down it shouldn't be a problem.

Sorry if I misunderstood your context.

When I want to move to a different SSD, I close the program(s) I am using and shut the drive down (typically with #shutdown -h now). The computer itself is now completely off. Then I push the button that links to the SSD I just closed; that "de-selects" that drive. Now all three buttons on the switch are in the OFF state. Then I push the button associated with the drive I want to use, and turn the computer on. It boots into the SSD I have just selected.

Based on your description, it sounds like the drives are in some kind of caddy with a physical switch that allows disconnecting them. I would also check for a hardware issue with this switch and at the ports. Have you tried swapping the bays the drives are in? Or you can try another machine, if the drives are readable. Of course, please make sure you have intact backups before you start experimenting further.

Swapping bays is a measure that I never considered; how I change the connections between the SSDs and the mobo might help to diagnose the cause of the problem, but I seriously doubt it would fix anything. -- This is the second switch I have had: the first one lasted quite a while and then failed. (When a switch goes bad, it simply stops working; you don't get the mad misbehavior that's currently present.)-- Yes, the drives are in separate bays. --- History: Connecting both the old and new switches was easy, and for some time the entire system worked perfectly. I made no changes in the cables (yes, I used the correct cables). Then Disc One started giving boot problems (already described). After a few more days, Disc Three went crazy: strings of letters and numbers started swirling around in the display, and even # whoami produced chaos. I have closed down Discs One and Three. Disc Two, Debian, is still doing fine...so far. --- I agree with 273: the problem could be somewhere on the (elderly) mobo -- SATA, possibly, yes -- so at present, I plan to put in a new mobo. I could be wrong, of course. (Have a look: on www.amazon.com, call up SISUN PW4101 3.5" Full Aluminum Floppy Drive Slot 4x SATA HDD Power Switch Control. Dual boot is obsolete!)

Before you start spending money on a new motherboard, it might be worth trying the drives directly in the motherboard rather than through the switch. Just because your last one failed by not working doesn't mean all of them will. Maybe a trace on a component that covers drives 1 & 3 is failing.

It's always best to at least try and diagnose problems without throwing money at it. If it still happens with the new mobo, then that was wasted money (unless you really wanted the upgrade), then the diagnosing has to start again. Just like when you're diagnosing POSTing issues, you try and remove anything that could be part of the problem and take it down to the basics. In this case, the basics would be removing your switch from in between the mobo and harddrives.

Good luck!

Dual boot is also obsolete for those of us who stick with one install ;)

Your logic is clear, bassmadrigal. It certainly could be the switch. As I see things, that possibility begs the question of how a simple switch could cause the problems I have. Thanks for the advice, and I mean that sincerely, because your cautious approach is perfectly rational.

A switch that is handling gigabit data rates is not "simple". Heck, I recently got a refund on some plain eSATA cables that couldn't handle even the lowest SATA data rates without occasional errors and were worthless at higher speeds.

My fault entirely: I apologize for my vague explanation of how the switch is installed and what it does. Only power is controlled by the switch. There is no add-on gizmo of any kind in the signal path that carries data to and from the SSDs. The switch has one function only: it permits electricity to power the selected SSD, while blocking power to the other two SSDs. It is completely isolated from the data path, which is why I am not worried about it being the cause of my problems.

Ahhh, OK. I looked up that device and couldn't figure out whether it switched the data path. I saw that it was "compatible with SATA I and SATA II" and figured that it must have something to do with the data. It's probably just a matter of SATA III not existing yet when that spec sheet was made.

You're entitled to your opinion. I'm happily dual booting Slackware and OpenBSD on two machines. Everything works as expected. I have no reason to change my set-up.

As mentioned by others it may be the case that a hardware issue is causing your woes. If you do wish to scan for malware in Slackware these utilities are offered on slackbuilds.org.

https://slackbuilds.org/repository/1...earch=rkhunter

https://www.slackbuilds.org/reposito...em/chkrootkit/

that would worry me as a concept. As long as the machine is completely shut down then, yes, ought to be OK but even getting BIOS to poll the SATA ports then find the live one and boot from it seems, perhaps I am just supersticious, like it's usng the hardware in a way it's not configured to be used. I can't point to a logical problem with the approach so you can dismiss this but, personally, I would use something like GRUB or even just the BIOS and choose the boot in software rather than powering attached devices off and on.

273's caution seems to me to be warranted. Now I refer to myself as "An Eternal Novice" when it comes to computers, but I honestly believe that the power-only switch can be operated safely: I never turn the box on until I have checked the buttons on the switch and made sure that none of them is depressed. Then I decide which drive I want to boot, depress that button, and proceed deliberately.

Now for the news (and I'm kicking myself for not thinking of this long ago): as statistically unlikely as it is, in fact two of my three SSD drives failed.

Proof of concept: I swapped the positions of SSD 1 and SSD2. SSD 2 has the Debian install, and it is running flawlessly. SSD 1 has a hopeless mess that was supposed to be Slackware. I booted into Debian by depressing button 1 on the switch, not button 2. By the same token, booting into SSD 1, where Slack has collapsed, means pressing button 2.

That's right: why did I completely overlook the possibility of SSD failure, and try to blame everything on my (elderly but still fully functional) mobo? I suspect it was due to my conviction that SSDs are the wave of the future. Maybe they are, but they have life-spans that vary, eh?

I'm going to purchase three brand new spinning disc hard drives.

Does anybody want to recommend which brand I should purchase?? TIA!

That is very interesting. I have not started using SSD's yet - one of the reasons being because of the numerous reports that they tend to fail quite suddenly and without warning - unlike HDD's - which most of the time fail gradually (specially if you have smartd keeping an eye on them and warning you in time). The other reason is that most of my setups need the larger capacities more than they need the extra speed.

As to hard-drive brands, I believe avoiding Seagate is a priority - as their failure rates in the last few years have been quite hight - based on frequent online reports and the number of Seagate drives I had to send back in warranty.

While I agree that it would appear that SSDs can simply fail more often that HDDs, which tend to give some warning, I do not see that as a reason to avoid SSDs. If your backup policy and recovery is dependent upon having warning that your storage will fail then your strategy is a very bad one.
I run my systems with the assumption that, at some point one or more components will just fail and, possibly, take my data and/or the whole machine with them. That's not to say that my backup and recovery strategy is perfect but that I don't avoid SSDs in the hope that a spinny thing won't fail as quick.

My post does not state that SSD's fail more often than HDD's. It says that SSD's more often fail without warning, compared with HDD's - at least based on various online reports.

But I agree with your thoughts on the need for appropriate backups.

On the other hand, just as an example of a particular situation - the last few hdd's which failed in my main laptop started to give SMART errors first. I had a good few weeks to arrange for the purchase of a new hdd, to find a suitable day when I could be without the use of the laptop for a few hours - during which I installed the new hdd and transferred the data - all in an orderly fashion and without stress. Had it been the case with a SDD which might have failed without warning in the middle of a busy day full of urgent work at clients - it might have been a completely different story.

So in practice, for me, it can make a significant difference. Of course, it is possible to arrange for a hot standby laptop constantly at the ready, constantly running and constantly keeping data in sync :-)

Perhaps I ought to have typed "simply fail" -- I meant that they just fail without warning more often not that they, in general, fail more often.

Edit: While, in general, it is more likely that with a SMART error one can simply transfer files it isn't guaranteed that the drive will not just fail with the SMART errors being symptoms of a larger problem. It's often said that when one drive starts to fail in a RAID 5 the chances of another failing while the RAID is rebuilding is fairly high, for example.
If your livelihood or similar depends upon a working laptop every day then you need two laptops and, possibly, some spare parts. If you don't actually need the laptop then, yes, a hard drive gradually failing may be more convenient but, as I mentioned, may amount to the same thing.
Also, remember that storage is just one component and a CPU, motherboard or PSU may just fail.

That is certainly possible - but in practice, maybe I'm lucky, but of all the hdd's with SMART errors I've had to replace, the data was still readable without problems.

I think this refers to the situation when the drives in the array are of the same make, model and age - which I always try and avoid. I've never had a failure so far of a second drive during the rebuilding of the array as the result of changing a failed drive.

Agreed - and I do. I still appreciate the extra notice and time to get things done when it is convenient. At least in my situation.

Theoretically correct. In practice though, hdd's are by far the most frequent points of failure. For a well used machine, every 3-4 years, like clockwork, most of them go. I think I've only ever seen once or twice a dead CPU in 20 years. They don't have moving mechanical parts - they don't wear out like hdds. RAM and mobos - a bit more often, but nothing like hdds. I still have a handful of old servers running on desktop mobos which are closing in on the 12 years mark. I don't have any 12 years old hdds left in production though :-)

All I can say is that I've had HDDs fail on me without any SMART errors. My backups don't rely on me having a warning to get new storage and move the data when time permits.

SMART errors are a great resource to provide you insight on your harddrive's health, but even the healthiest-seeming person can still die instantly from an aneurysm. If you get warnings that your drive might be dying, that's great, but it isn't always going to happen.

With you identifying that this is a drive issue, please identify the models of the SSDs that failed. There have been some bad models out there, and it's handy to hear first hand accounts. And update your thread title.

Agreed. That's what backups are for. And RAID arrays - if possible (i.e. - not a regular laptop).

Sorry to everybody for going on a slight tangent in this thread :-)

How recently did you upgrade to kernel 4.4.29? Was it the official Slackware package?
Did you run "lilo", etc after upgrading the kernel?

It may be worth backing out that kernel and either temporarily going back to the official 4.4.14 which comes with Slackware 14.2 (but vulnerable to the "Dirty Cow" bug), or going to 4.4.30.