-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
Intel ss4200-e dead power supply
Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Intel_SS4200
Junior Member
Hello Everyone,
So just like OP, after 10+yrs of running my power supply on my Intel SS4200 died. Had a old power supply and rigged it to power the whole unit.. the problem now is that there are only 1 lights on in the front of the unit and it's the top 2 lights, standard critical failure. I was thinking holding the reset button on the back would fix that but it just gets stuck there.. nothing.
Anyone have any ideas on where I can go from here.. I tried to remove all the disk and start it up to reset.. nothing. I've removed all the disk and plugged them 1 by 1 to another computer and tried to use data recovery software and still nothing. My guess is because the IDE uses software RAID controller. Tried to plug them all into a RAID controller and it wouldn't rebuild the array because my guess is that it doesn't know how to due to software on the IDE. The IDE is getting power but I'm not sure if it's corrupt or not.
Just looking to get my info off these drives. It's served it's purpose and I'm ready to move forward but looking for some guidance/ideas.
Thank you
So just like OP, after 10+yrs of running my power supply on my Intel SS4200 died. Had a old power supply and rigged it to power the whole unit.. the problem now is that there are only 1 lights on in the front of the unit and it's the top 2 lights, standard critical failure. I was thinking holding the reset button on the back would fix that but it just gets stuck there.. nothing.
Anyone have any ideas on where I can go from here.. I tried to remove all the disk and start it up to reset.. nothing. I've removed all the disk and plugged them 1 by 1 to another computer and tried to use data recovery software and still nothing. My guess is because the IDE uses software RAID controller. Tried to plug them all into a RAID controller and it wouldn't rebuild the array because my guess is that it doesn't know how to due to software on the IDE. The IDE is getting power but I'm not sure if it's corrupt or not.
Just looking to get my info off these drives. It's served it's purpose and I'm ready to move forward but looking for some guidance/ideas.
Thank you
Well, you've come at the right time since I dug deep into this system last weekend. 🙂
So, the good news first--your data should all still be intact, and Intel released a technical paper and how to retrieve the data using unix. It's not for the faint of heart as it's quite technical, but it can be done.
So now onto the potentially bad news. Power supply failures can be catastrophic and damage the motherboard or other components, which might have happened. 🙁 But it could also just be the dom not booting, which is easier to fix.
I'd remove your drives and try the reset a couple of times to see if you can get the dom to boot again. The types of presses also do different things per the ss4200 wiki here:
http://ss4200.pbworks.com/w/page/5122739/Boot Issues - Power light flashes continuously
If not, you can remove the dom and put it in another system and then re-image the dom as it might be corrupted. I think technically you could even put the image on an ide hard drive or compact flash with a flash adapter, but I'd try the original dom first.
Once you have the system booting again (even if it is in pieces), you can put your drives back in it and there's a process to make it use those drives without formatting them. There's some instructions I've saved from somewhere that told me how to properly do this, but I can't recall atm. BE CAREFUL HERE BECAUSE IT WILL WANT TO YOU REFORMAT THEM, AND YOU DON'T WANT TO DO THAT OR YOU WILL LOSE THE DATA.
Let me know what happens and I'll do my best to help. 🙂
So, the good news first--your data should all still be intact, and Intel released a technical paper and how to retrieve the data using unix. It's not for the faint of heart as it's quite technical, but it can be done.
So now onto the potentially bad news. Power supply failures can be catastrophic and damage the motherboard or other components, which might have happened. 🙁 But it could also just be the dom not booting, which is easier to fix.
I'd remove your drives and try the reset a couple of times to see if you can get the dom to boot again. The types of presses also do different things per the ss4200 wiki here:
http://ss4200.pbworks.com/w/page/5122739/Boot Issues - Power light flashes continuously
If you're able to get the DOM to boot again, you're halfway home.
If not, you can remove the dom and put it in another system and then re-image the dom as it might be corrupted. I think technically you could even put the image on an ide hard drive or compact flash with a flash adapter, but I'd try the original dom first.
Once you have the system booting again (even if it is in pieces), you can put your drives back in it and there's a process to make it use those drives without formatting them. There's some instructions I've saved from somewhere that told me how to properly do this, but I can't recall atm. BE CAREFUL HERE BECAUSE IT WILL WANT TO YOU REFORMAT THEM, AND YOU DON'T WANT TO DO THAT OR YOU WILL LOSE THE DATA.
Let me know what happens and I'll do my best to help. 🙂
Intel_SS4200
Junior Member
Thank you!! I actually think you are right also and think the DOM isn't booting.. I checked the two little pins to make sure power was getting to it and 5w was going to the DOM.. I'm going to try to connect via the RS232 header but I think I need to find/order a converter/adapter to go form the header to the cable since I just checked and a standard cable wouldn't fit it lol. Any recommendations for this part?
I'm confused - if the box is running linux with some standard raid software like mdadm; can't the disks be moved to a modern linux system and the raid set should be found ?
I wouldn't bother with trying the rs232--just take the dom out and see if it shows up in another computer. Then that will eliminate the dom as the issue as it could still be something with the motherboard. Remember though that a corrupt dom may not boot even if the drive shows up--and there's a fix for this by just reimaging the dom.
That's pretty much what can be done except there's a specific procedure to it since the box is a bit proprietary.
Intel_SS4200
Junior Member
I'm literally trying that first since I don't have a connector to go from the pins inside the unit to the computer. If this doesn't work I will be in touch.
Attachments
Intel_SS4200
Junior Member
But wondering.. do all 4 disk need to be connected at the same time to the computer in order for this to work? Or can each be connected one at a time?
If it is raid 5 (3+1) then you will need 3 disks for the raid set to be readable.
I can't find intel instructions but these instructions might work:
https://www.funkypenguin.co.nz/note/importing-existing-raid-devices-new-linux-installation/
---
basically have mdadm discover the raid set from the disk labels
then have it write a conf file based on the live configuration.
-
if someone knows where the intel instructions are located we can see if there is much difference. These days I use zfs instead of mdadm but once a long time ago in a galaxy far away i used to use mdadm.
[root@myhost ~]# mdadm --assemble --scan
mdadm: /dev/md/2_0 has been started with 2 drives.
[root@myhost ~]#
Then I needed to recreate /etc/mdadm.conf by running
mdadm --detail --scan >> /etc/mdadm.conf
https://www.funkypenguin.co.nz/note/importing-existing-raid-devices-new-linux-installation/
---
basically have mdadm discover the raid set from the disk labels
then have it write a conf file based on the live configuration.
-
if someone knows where the intel instructions are located we can see if there is much difference. These days I use zfs instead of mdadm but once a long time ago in a galaxy far away i used to use mdadm.
[root@myhost ~]# mdadm --assemble --scan
mdadm: /dev/md/2_0 has been started with 2 drives.
[root@myhost ~]#
Then I needed to recreate /etc/mdadm.conf by running
mdadm --detail --scan >> /etc/mdadm.conf
Oh my. I would clone those drives in a drive cloner before you do anything to them or the data might be lost forever in one wrong move...
That being said, here's a thread I found where someone that got their drives mounted after a failure:
https://forums.intel.com/s/question...utage-help-me-get-my-data-back?language=en_US
That being said, here's a thread I found where someone that got their drives mounted after a failure:
https://forums.intel.com/s/question...utage-help-me-get-my-data-back?language=en_US
I looked at the Intel data recovery pdf and it only talks about doing it from the console via ssh or rs232:
https://www.intel.com/content/dam/s...server/ss4200-e/sb/ss4200edatarecovery_12.pdf
https://www.intel.com/content/dam/s...server/ss4200-e/sb/ss4200edatarecovery_12.pdf
From that thread the mdadm commands i suggested would probably work IFF the version of the 4200 was running linux. There appears to be a window version and no clue what it uses for raid.
There are two versions, but if it is booting from the dom and was 'stock' (user didn't install an os), then it is the ss4200-e and not the ss4200-ehw, which could have windows installed.
I think between the instructions you've posted and those that Intel gave the user in the thread I posted, there's a solid shot of getting the data back if something hasn't altered the state of the drives by now.
IFF=If and only if? I haven't seen that since my C days. 😀
C - i don't know C these days; just gnu C... but once a long time ago i knew K+R C; but that was a long time ago in a computer room far away.
I didn't know much of C either except when I saw your IFF. 😀 I think that's one of the few things I remember besides arrays and pointers.
Intel_SS4200
Junior Member
Great news! I took a old hard drive and loaded fedora to it.. mounted all 4 disk and fedora saw the RAID! Nothing had to be done.. I copied all my data, took 20hrs but man I'm a happy camper! thanks everyone!!
10 years ago it would still have been recoverable but a lot more painful; they've added a lot of conveniences over the years. Btw why copy the data? I mean you can use the disk in your linux box (if you have a box running linux 😉 though in all honesty i would use zfs over mdadm for numerous reasons. One of these days brtfs will rule the day but that day hasn't quite arrived as of yet.
So great to hear!! So what version did you use? Could this be done as simple as loading up a live cd and moving the drives to the same system? I'd love to know for future reference. 😎
Boy I'm glad things are easier for now. One of the reasons I liked these units was because they were pretty linux partitions and raid so recovery was easier. But if it's this easy, that's a serious bonus.
The problem with mdadm is it is used to raid mostly ext4 or ext3; and does not contain file checksums so bit rot can occur over time. brtfs and zfs both support native raid (though I suppose you could run brtfs ontop of mdadm but then it woudln't be able to fix bit errors - just log them) and also contain file check sum so errors can be detected and fixed. While actual parity errors are rare block reallocs will trigger a zero page on the disk causing file corruption. zfs for example will detect this error and fix the data during scrubbing. Naturally with raid 0 recovery is not possible but with raid 1 or raid 5 it is and it is quite efficient at fixing these errors as i've discovered much to my delight. I haven't played with brtfs much so can't say with certain it is reliable at fixing these errors but i presume it works similar to zfs - the problem with brtfs is that it is less stable with error conditions and data can be lost (not just bit errors but certain types of raid faults will confuse the file system. This is a moving target as the filesystem is (or was) undergoing rapid development and any statements made from yesterday version might not apply to tomorrow update.
-
i'm not sure how common sector remaps are these days - the last few mechanical disks I have owned had very few remaps over time (mostly 0 for the 4tb hitachi drives i had as well as the newer 10tb drives - but they are not very old). I know older 1 and 2tb drives i owned had quite a few sector remaps over time - but i don't have enough drives to know if this is the luck of the draw or improvement in technology.
-
i'm not sure how common sector remaps are these days - the last few mechanical disks I have owned had very few remaps over time (mostly 0 for the 4tb hitachi drives i had as well as the newer 10tb drives - but they are not very old). I know older 1 and 2tb drives i owned had quite a few sector remaps over time - but i don't have enough drives to know if this is the luck of the draw or improvement in technology.
I've worked with raid systems since the early late 1990s having a full external scsi-scsi raid controller on my desktop system (mylex dac960sui) for several years, and I think the biggest problem is that most people dont understand that a raid doesnt automatically protect the data. It can, depending on the implementation, but even then still has limits.
I stopped using raids and moved to manual triple-set mirroring before the days of zfs because bit rot has become a reality with today's densities. I still don't use raid today except on the intel units (because you have to), as I'm still not convinced that the extra overhead of zfs will still be enough to deal with bit-rot.
In terms of raid, raid0+1 is what I would probably implement with zfs with multiple parity. This would be relatively safe and also detect bit rot, but it still subject to catestrophic failure.
I'm using the intel nas as just a online backup, so if it fails, it's just one in a series of backups. But recovering if necessary is also something to consider, so I did like the very standard and simple setup of the units. And hearing that
Intel_SS4200 was able to recover the volume so easily, makes this even a better unit imo.
I stopped using raids and moved to manual triple-set mirroring before the days of zfs because bit rot has become a reality with today's densities. I still don't use raid today except on the intel units (because you have to), as I'm still not convinced that the extra overhead of zfs will still be enough to deal with bit-rot.
In terms of raid, raid0+1 is what I would probably implement with zfs with multiple parity. This would be relatively safe and also detect bit rot, but it still subject to catestrophic failure.
I'm using the intel nas as just a online backup, so if it fails, it's just one in a series of backups. But recovering if necessary is also something to consider, so I did like the very standard and simple setup of the units. And hearing that
Intel_SS4200 was able to recover the volume so easily, makes this even a better unit imo.
multiple failure is a bit different than bit rot. zfs will definitely detect errors at the file level due to bit rot - and it will inform you if they cannot be recovered. With ext3 or ext4 (on top of raid) you will never know if a file has suffered bit rot even if the filesystem itself remains intact and across all disks the data can actually be recovered because the file system is unaware that an error has occurred.
With regards to 'recover the volume' i see nothing magical that happened here with regard to the intel ss4200. Because they used software raid instead of hardware raid - moving the disks to another linux box made the data recoverable (well i think recoverable is the wrong term - it made the data visible - no actual recovery occurred). This has always been a huge advantage of software raid over hardware raid - of course there is a price to be paid in performance. While that might be visible in a slow system like hte intel 44200; certainly modern processors are more than fast enough to keep with the disk when performing parity computation.
-
Personally I run x+2 and the company i used to work for ran x+3 (x being the number of data disks and 2/3 being the number of parity disks). There are two reasons to run x+1; the first being cost (minor for a data center but somewhat more visible to a home owner); and performance. The first parity disk is extremely cheap using xor; but the computation for anything over 1 is quite expensive - though 1 gigabit is possible with careful coding on a middle range processor. However if you are trying to sustain 10 gig - probably won't happen (this is only relevant for writes or parity recovery on reads) - these values are for a single core or hyperthread. With a bit of additional complexity at the code level and today modern many core processor 10 gig can be obtained and sustained on the recovery side - bit harder on the write side but that is less relevant as the write side is normally a lower bit rate than the read rate (these values are for a high performance system and not relevant to most home owners who would be overjoyed at several 100mb/s.
With regards to 'recover the volume' i see nothing magical that happened here with regard to the intel ss4200. Because they used software raid instead of hardware raid - moving the disks to another linux box made the data recoverable (well i think recoverable is the wrong term - it made the data visible - no actual recovery occurred). This has always been a huge advantage of software raid over hardware raid - of course there is a price to be paid in performance. While that might be visible in a slow system like hte intel 44200; certainly modern processors are more than fast enough to keep with the disk when performing parity computation.
-
Personally I run x+2 and the company i used to work for ran x+3 (x being the number of data disks and 2/3 being the number of parity disks). There are two reasons to run x+1; the first being cost (minor for a data center but somewhat more visible to a home owner); and performance. The first parity disk is extremely cheap using xor; but the computation for anything over 1 is quite expensive - though 1 gigabit is possible with careful coding on a middle range processor. However if you are trying to sustain 10 gig - probably won't happen (this is only relevant for writes or parity recovery on reads) - these values are for a single core or hyperthread. With a bit of additional complexity at the code level and today modern many core processor 10 gig can be obtained and sustained on the recovery side - bit harder on the write side but that is less relevant as the write side is normally a lower bit rate than the read rate (these values are for a high performance system and not relevant to most home owners who would be overjoyed at several 100mb/s.
Yep, they are two different issues. That's the thing about being informed if it can be recovered--my current system of triple mirrors pretty much guarantees a recovery unless there are 2 failures in the same file across two disks--highly unlikely.
I agree that the 'recovery' was nothing magical, but for those of us that don't know unix, simply mounting the drives again and seeing the data will seem like a miracle. I'm still wondering exactly how it was done so I can have that in my toolbox.
I agree that the 'recovery' was nothing magical, but for those of us that don't know unix, simply mounting the drives again and seeing the data will seem like a miracle. I'm still wondering exactly how it was done so I can have that in my toolbox.
The drives have a label; the software sees the label and reacts accordingly.... It is a good thing these labels are unique but i guess that was by design.
---
The problem is that unless you have file or block checksum; having mirror 3 does nothing to prevent bit rot or ensure reliable data. If you have a failure - and the disk that is copied is the one with the bit rot - that bit rot will be coppied onto the new disk. If you keep a strong checksum (zfs uses md5 or sha256 (user configurable)) having redundancy helps but over time the data will likely corrupt.
Btw for tcp one should use ssl - the simple chksum tcp uses is nearly worthless with preventing bit errors - ssl uses strong checksum at the user layer (though ssl is very expensive relatively speaking) (we used to get massive corrupted data over tcp when there were hardware errors because the chksum was too weak).
---
The problem is that unless you have file or block checksum; having mirror 3 does nothing to prevent bit rot or ensure reliable data. If you have a failure - and the disk that is copied is the one with the bit rot - that bit rot will be coppied onto the new disk. If you keep a strong checksum (zfs uses md5 or sha256 (user configurable)) having redundancy helps but over time the data will likely corrupt.
Btw for tcp one should use ssl - the simple chksum tcp uses is nearly worthless with preventing bit errors - ssl uses strong checksum at the user layer (though ssl is very expensive relatively speaking) (we used to get massive corrupted data over tcp when there were hardware errors because the chksum was too weak).
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
