Dear Fedora, Would one of our intrepid code warrior heroes please fix these for me? Hot swapping a SATA backup drive crashes Fedora. This is a production level server. I can not turn it over to the customer in this condition, so I am in a real pinch here. FC26, x64 Xfce 4.12 # uname -r: 4.12.5-300.fc26.x86_64 Motherboard: https://www.supermicro.com/products/motherboard/Xeon/C236_C232/X11SAE-M.cfm BIOS 2.0b SATA = RAID Hot Pluggable = either, no symptom change The main drives are two Samsung SSD MZ-7KM960NE SM863a 960GB SATA SSD drives in RSTe ("e" for enterprise) RAID 1 configuration. The drive enclosure is a CRU 8440-6502-0500, DataPort 10 Drive Bay Adapter Internal with four addition carriages CRU 8442-6502-0500, DataPort 10 Drive Enclosure Internal https://www.cru-inc.com/products/dataport/dp10 The backup SATA drives (five in rotation) are Western Digital HDD WD20NPVZ 2TB SATA 6Gb/s problems: 1) if the drive is not in the sleeve at boot time, the drive is never recognized. (This is not an issue the Supermicro's C7Z87 motherboard where hot swap SATA acts like a USB drive. Stick it in whenever you like.) 2) if I dismount one of the above backup drives and slap a new drive into the sleeve before /dev/sdc and /dev/sdc1 disappear and the icon disappears from the desktop (about 90 seconds), Fedora crashes with "input output error" and "comreset failed error = -16". The one fingered reset does not work. You have to flip the power off to recover. And I ***** GUARANTEE YOU ***** the customer will not sit around and wait 90 seconds to put the new drive in. So this server can not be delivered in this condition. I do hot swap SATA drive ALL-THE-TIME. This has never been an issue before. Many thanks, -T
Guys, I really need this fixed! New information. I installed a Syba SI-PEX40062 four port SATA card, which supports hot swap and hot plug. http://www.sybausa.com/index.php?route=product/product&path=64_77_85&product_id=157&filter=16,38,19,73 Then I moved the backup drive over to it. Still hoses the Fedora 26 when I change the unmounted drive. I then removed the card and put everything back to normal. Next I booted off a direct install Fedora 26 flash drive made from Fedora-Xfce-Live-x86_64-26-1.5.iso. The flash drive OS handled hot swapped drives as fast as I could jerk them out and slap them in, whether or not the RTSe raid 1 pair was mounted or not. If I tried to access the drive to quickly, I got the finger shaken at me, but the next attempt work perfectly. Took about 5 seconds to mount. The flash drive is using kernel-4.11.9-300.fc26.x86_64, which I could not locate on the repos, so I install 4.11.8. No symptom change. The OS still got hosed. So, may I presume that the hardware is not to blame, but that the OS on the hard drive is not functioning properly.
----------------------------- more info ----------------------------- I did a lot more thorough testing this time, including with Fedora 25 Live. A pattern emerged. If your OS is not running off the RSTe RAID 1 volume, you can swap the backup drive a many time and as fast as you can move. After you swap the disk, the RSTe RAID 1 volume will hose. If you are running your OS of the RSTe RAID 1 volume, your OS will also hose. If the drive is not inserted when you boot, the same pattern emerges when you insert it. The hose error message for the RSTe RAID 1 volume when not running the OS off of the RAID volume is (takes about 60 seconds): Failed to mount "894 GB Volume" Error mounting /dev/md126p2 at /run/media/todd/f1c297de-d5c6-48ba-ac8f-d2c1a7b4702d: Command-line `mount -t "xfs" -o "uhelper=udisks2,nodev,nosuid" "/dev/md126p2" "/run/media/todd/f1c297de-d5c6-48ba-ac8f-d2c1a7b4702d"' exited with non-zero exit status 32: mount: /run/media/todd/f1c297de-d5c6-48ba-ac8f-d2c1a7b4702d: can't read superblock on /dev/md126p2. These were all on BIOS version 2.0b. The Fedora 25 server with the same configuration (different model hard drives) that works properly is on BIOS version 1.0b. I asked Supermicro for a copy of 1.0b.
I will be downgrading to bios 1.0b next week. Are there any tests or data you need me to collect before you lose your window on this particular machine presuming it works)?
Follow up: This stinking issue took the server down and I had to reinstall it. It did not get home till 06:00. And XFS, bless its hearts, rolled back everything I did on the new server every time this issue surfaced. I am about over $1000 U$D in free consulting. Anyway, it repeats itself under F25 Live USB and F26 Live USB. It also repeats itself under BIOS SATA = AHCI or RAID, it doesn't matter. And whether the OS is installed on a single drive (AHCI) or an RSTe RAID 1 (RSTe RAID) drive. And, the I managed to isolate the stinker to the back drive itself, which is a Western Digital HDD WD20NPVZ 2TB SATA 6Gb/s Mobile 8M Cache Internal 2.5inch Blue Bare drive. This did not repeat using an Intel SSD 530, which you can connect and disconnect to your hearts content. This was an extremely *** expensive *** lesson!
Not to state the obvious, but just because I came up with a work around does not mean this is fixed. This bug cost me dearly. You need to protect others from it too.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.