Fireball3

Members
  • Content count

    1196
  • Joined

  • Last visited

Community Reputation

33 Good

About Fireball3

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  • Location
    Good old Germany
  • Personal Text
    >> Engage <<

Recent Profile Visitors

1058 profile views
  1. It's probably the best you plug the card into a board and query MegaCli.exe -AdpAllInfo -aAll -ApplogFile mgcliad.txt or sas2flsh -o -listall -l sas2ad.txt The binaries you need are in one of these packages, for example.
  2. perc h310 replacing AOC-SASLP-MV8

    I remember having read about a similar problem in this forum. IIRC it was indeed a bad configured disk. I will do some research and see if I can find the post again. Edit: I'm sorry, but I can't find the related post. I don't think the controller is not compatible with SATA I specification. In fact, the drives you mention are SATA II according to the data sheet. https://www.hgst.com/sites/default/files/resources/Deskstar_E7K500_DS.pdf Are there any jumpers on the drives? I remember the solution in that mentioned post referred to a wrong jumper setting.
  3. SATA Controller Cards

    Yes, this is a problem since the first posts in this thread are somewhat outdated and, as of today, even misleading! Maybe a mod can post a word of caution in the OP, and link to the hardware wiki. I'm thinking of highlighting the most recommended cards in the wiki.
  4. If you have the PAL error, you need to boot into EFI shell and do it from there. See this post for futher info. If you have further questions feel free to ask! You can use the latest DELL toolset, just skip the DELL specific part!
  5. I'm presupposing you're on the mailing list, nevertheless: https://lists.samba.org/archive/samba-announce/2018/000434.html
  6. Maybe you can go back to earlier versions of this X firmware and see if there is a difference? How could this help? For flashing the SAS2008 chipset there is a version of the sas2flsh utility (P7) that enables overriding of wrong vendor ID's. If there is an equivalent sasflash you may be able to pass that check? And use a plain DOS environment for those flashing tasks. Not a Windows console! This is all with Windows hardware recognition in between. Can't tell if it is true what you're seeing. If you had a schematic of your board you could perhaps verify. See this post There may be some new ideas for you. e.g. 'ignore vendor' option coming with the IBM utility... I have to check if I have the lsiutil binary somewhere.
  7. Yes, I got you, but NO. The revision is right beneath the name - it is B1. (afaik, there is no C at all) Can you share the "help" of the megaRAID utility?
  8. No, it's LSISAS1068 B1 I edited my comment above. Please reread and consider the DOS option. This is strange. Where did you get the HP firmware from? What did the MegaRAID utility do exactly? Can you elaborate on that? Did that possibly alter the cards name?
  9. Have you seen this? https://hardforum.com/threads/how-to-flash-an-lsi1068e-to-it-mode.1573340/ and this? https://hardforum.com/threads/assistance-needed-ibm-br10i-1068e-flash-to-it-mode-c0-revision-error.1645862/#post-1038602393 Same error, although different goals!
  10. I also found that info. Maybe here is a loose end where one could dig deeper to see what's the SAS8888ELP. The firmware for that card is flashed with megaCLI - at least it's in the zip. Not sure what MPT6.36 is necessary for. MegaRAID needs the firmware in a different format iirc. I think the MegaRAID is a dead end as long as you don't have the P21 in that specific format. What is the help of MegaRAID saying? Is it capable of wiping the cards ID or something like that? That could possibly be of use. Can you flash an older HP firmware with the sasflsh utility? Or even with another tool. Just to have another basis. Maybe in earlier versions the adapter reports with "106e b1"? The IBM BR10i and the Intel SASUC8I also use the same 1068E chip and can be flashed with LSI3081 firmware. Maybe a cross flash with one of those firmwares can help as an intermediate step on the way to the LSI P21? I propose you prepare a DOS bootable and avoid Windows. Note what the readme.txt says:
  11. This is correct! Can you flash those firmwares? Just to prove it's working. There are some uncertainties as your chipset is on board. Maybe the error is justified and a cross-flash of this kind shouldn't be possible. It's also imaginable, that all LSI firmwares are labeled 106e and the OEMs have just tagged their cards slightly different to avoid LSI firmware being run on them. Oftentimes they cut the feature list of the OEM cards via firmware. You can work back through the old LSI firmwares and see if one of them possibly works. Once the controller is on LSI you can flash the most recent firmware. Next suggestions bear risk of bricking. You didn't erase the controller prior to flashing - may be a possible option? I have to check what options this sas2flsh utility brings to override things... Another way would be to disassemble the firmware file and see if you find the string that is checked for. Unfortunately I haven't had the time and the tools to try something like that. Did you try flashing from within Windows? Not sure if this can be a problem - I usually do firmware things from a DOS environment.
  12. Go to Broadcom and grab the full P21 firmware package and give it a try. The sas2flsh utility is newer, maybe it makes a difference? Have you elder HP firmwares? Do they also flash with the sas2flsh utility? Maybe try that one with the P21 firmware?
  13. No, the only thing you have to take care is that for use with unRAID we want to have IT mode firmware and all scripts and how-to's are tailored for that specific purpose. You have to use the IR firmware for your undertaking! There is a P21 firmware for that sort of controller. Why didn't you use that? With regard to the error, there might be some sort of vendor check to prevent cross-flashing? Is that a standalone card or onboard chip? Have you searched the HP sources for a newer firmware?
  14. Where does disk encryption stand?

    I don't think it needs such a "high paranoia" to walk the path of encryption. I tried to explain my paranoia here. You're welcome to explain your reason of encrypting your data. The "remote encryption unlock" just adds a lot more flexibility for the users not having their server running 24/7 (locked away in the basement or so, maybe even on a remote location). It's not necessarily about the higher security key strength that is possible via this method, but once implemented, this is another goodie.

Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.