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.

1 members found this post helpful.

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.

2 members found this post helpful.

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

1 members found this post helpful.

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.

2 members found this post helpful.

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/