_0m0t3ur

Do you get any output at all in the web browser with “domain.duckdns.org” in place?

I'm having the same 0kb update issue with a handful of lio docker containers for about a week.

Glad you find this helpful. My intention was to be more complete for someone new.

This post is a starting reference point for someone else wanting to flash a system with multiple SAS controllers. I took the time to write it up to help the next person. Let me know if this is of value, or unclear, etc. So, I updated my mobo LSI SAS 2008 controller to 20.00.07.00 in IT mode to match the LSI 9201-8i HBA. For the full series on how to make the USB drive, and screenshots of step-by-step flashing for a system with just one SAS controller, click on this URL link. You'll need to verify which LSI SAS controller you have and which firmware you'll need for it. The SAS2Flash Utility supports the following controller models: LSI SAS2004 LSI SAS2008 LSI SAS2108 LSI SAS2116 LSI SAS2208 LSI SAS2308 You'll also need to verify whether you have UEFI BIOS or Legacy BIOS. The following information is for updating your SAS controllers on systems with Legacy BIOS. If you have UEFI BIOS, you will need to use Broadcom's UEFI Flashing Utility. Google is your friend. My SAS controllers are LSI 2008, and thusly I'm referring to them here. Also, since my motherboard SAS controller is an LSI 2008, it's basically an LSI 9211-8i, so I used the firmware from the 9211-8i to flash my motherboard SAS into IT mode and the same firmware to also flash my 9201-8i to IT mode as well. More resources available at these: A Serve The Home article about flashing a Supermicro motherboard that has a SAS 2008 controller. A Serve The Home forum post about flashing a Supermicro motherboard to IT mode. There are commands to execute flash functions on all controllers in a system. Refer to this linked LSI SAS2Flash Utility Quick Reference Guide for more information. This guide comes with the firmware version you'll download for your system. For anyone with multiple SAS controllers/HBA's installed in their system and you want to update controllers individually, you'll need to use the -c command to choose the specific controller/HBA that you want to flash, or otherwise execute on. If you're unfamiliar with this command, here's how it works. After booting into your DOS USB drive on the host machine, at the DOS thumb drive C:/ prompt, run the command: sas2flsh -listall This will list all your SAS 2008 controllers, showing columns for firmware version, NVData, BIOS, and PCI address. Additionally, there is a first column labelled "Num". So, in the above screen shot, you notice there are two SAS 2008 controllers showing, after executing the -listall command. The controller named SAS2008(B1), designated with a "1" in the "Num" column has the older version, 20.00.04.00. Use the number from the "Num" column, that is next to the SAS controller you are interested in flashing or otherwise executing commands on, along with the -c command, telling the flash utility to which controller you're referring. Generally, the standard command sequence for flashing the LSI 2008 controller is the following: sas2flsh -o -e 6 sas2flsh -o -f 2118it.bin -b mptsas2.rom sas2flsh -listall For our purposes, now, to be able to execute commands on this specific SAS controller, we'll change the standard command sequence shown above, adding in the "-c" command, as shown below: sas2flsh -c 1 -o -e 6 sas2flsh -c 1 -o -f 2118it.bin -b mptsas2.rom sas2flsh -listall The "-c 1" tells the sas2flsh utility to execute the commands on the SAS2008(B1) controller. Since this controller happens to be a motherboard, there is one more thing that needs to happen. We need to find out the address of the motherboard SAS 2008 controller BEFORE any actual flashing. We need to know the motherboard SAS address in case we erase the SAS address from the motherboard SAS controller. Then we can just write the SAS address back to the controller and it will match the SAS address on the sticker adhered to the motherboard. Being consistent is helpful to avoid confusion or if we sell the motherboard. And this only applies to flashing the motherboard SAS controller. You don't need to do this to flash a SAS 2008 controller card (HBA). Note: The first line of the standard command sequence is putting the controller into advanced mode (-o) and erasing the flash memory (-e 6). That "6" is a command parameter to cause a clean flash, erasing everything except the manufacturing area. This also means that the motherboard SAS address will not be erased. I suggest do the SAS address checks despite this just to be sure. You can read more about the various region parameters on page 14 of this linked SAS2Flash Utility Quick Reference Guide. In the event we cannot find the SAS address sticker adhered to the motherboard, we can also find this address by invoking a command with the sas2flsh utility like this: sas2flsh -c 1 -o -listsasadd This will simply show the SAS address for the SAS controller associated with the 1 in the "Num" column. Make sense? I advise using your smart phone to take a picture of the motherboard SAS address on your screen after running the -listsasadd command. It's a quick and easy way to record the address while avoiding possible transcribing errors. In fact, take photos of any screen information that you will want available later in the flashing process. So, to sum this up, use the "-c x" command where "x" is the number from the "Num" column, that is next to the SAS controller you are interested in flashing. Here is the sequence of commands for a system with multiple controllers: Flashing HBA: 1. Run, sas2flsh -listall, to find out the "Num" of the SAS controller you want to flash. 2. Use that "Num" number with the -c command to execute any flashing operations. 3. BEFORE REBOOTING, run the command, sas2flsh -listall, to verify that the flashing commands worked. Flashing onboard SAS: 1. Run, sas2flsh -listall, to find out the "Num" of the SAS controller you want to flash. 2. Run, sas2flsh -c x -o -listsasadd, where "x" is the "Num" of the SAS controller, to obtain the motherboard SAS address. 3. Record the SAS address from step 2. 4. Use that "Num" number with the -c command to execute any flashing operations. 5. BEFORE REBOOTING, run the command, sas2flsh -listall, to verify that the flashing commands worked. 6. BEFORE REBOOTING, run the command, sas2flsh -c x -o -listsasadd, where "x" is the "Num" of the SAS controller, to verify the motherboard SAS address. If the SAS address is not present, then: 7. BEFORE REBOOTING, run the command, sas2flash -c x –o –sasadd 50062b000000000, where "x" is the "Num" of the SAS controller, and "50062b000000000" represents your actual SAS address that you saved as picture in your smart phone from earlier. 8. RE-VERIFY SAS ADDRESS by running STEP 6 again. 9. Reboot.

Thanks for all your hard work! I really appreciate these updates. My server is updated to v6.7.1, with no problems detected.

I'll look at updating my mobo to 20.00.07.00. Thanks for the feedback.

I have a Supermicro X8DT6-F motherboard, which has 2x4 onboard SAS 2008. Recently, I added an LSI 9201-8i HBA, upgrading to the latest P20 firmware. At the end of the HBA flash, I verified the firmware for both the HBA and mobo. Mobo: 20.00.04.00 HBA: 20.00.07.00 I recall reading in the FreeNAS forums that it is recommended that all SAS controllers be flashed to the same firmware version. Can anyone tell me whether this is specific to FreeNAS or a general recommendation? I couldn't really find much information regarding this other than a few comments here or there on The Net. Any additional info/guidance would be appreciated. Thanks much.

My approach was to perform some task that I would usually do, and then look at the other processes in Netdata and Glances to see which processes were impacted by my task. Then it's a matter of figuring out what needs to change in order to improve the performance. Regarding your NVME, I would think just setting up a typical write you would normally do, and then see what other processes, viewed in Glances, show IOWAIT. Like I mentioned earlier, I don't have an NVME drive. My standard SATA III SSD's are all connected to my motherboard SATA II. And my performance is great. The fact is the SATA II spec is up to 300 MB/s. But because of parity writing, the max speed writing to the array is much less than that. You mentioned that your previous NVM drive worked great. Why not get another one of them?

Looking at the link you provided, Silverstone recommends an LSI 9211-8i, though they say, "Installation of expansion card up to maximum size will occupy one hot-swap bay space..." So, looks like there is a trade off but an LSI card could be used. If you were to decide to go this route, I would recommend an LSI 9201-8i, which is an IT only card. They can be had on eBay for about $20, without cables. There are 4i versions of similar cards, but they cost more and are about the same physical size, so the 9201-9i is a better value.

I had already decided that I was not going to try recovering anything on this disk. Turns out data on this disk was the least problematic to lose, if I were going to lose anything. The disk showed the orange triangle (said it was emulating but it was really emulating 'no data'); yet, I needed to get this drive out of this error state and functioning inside the array with full parity. All my drives are near brand new with zero SMART errors of the physical disks, so I'm not concerned about full disk failures for the immediate future, but I also didn't want to chance being parity unprotected in the event that I had another connection problem, which should also be a very low probability with brand new cables and new LSI SAS HBA. So, basically, I just needed to get this sorted and move on. I let unRAID do it's parity sync, which is nearing its end. This will get rid of the orange triangle and bring the array back to full parity, leaving me with the one disk blanked out, but I'm already fine with that. I had searched the forum, trying to find similar scenarios of formatting in the array and the best way to move forward with getting the offending disk out of an error state. But I kept finding posts focused on recovering data, and when data was said to be recovered, the conversations ended. The other thought I had was to use New Config. But decided that just letting unRAID perform the parity sync was the easiest thing to do. The problem with unRAID is that it works too well. It runs error free for a year or two, and during that time one forgets stuff about how this thing all works, then when there's a problem, it's like one has unRAID Alzheimer's.

You're right, these speeds seem unusually slow. I don't have an NVME drive. Though, I've heard there are "good" and "bad" NVME drives. You might search for "best nvme for unraid" and find out what nvme drives are being used successfully by other unRAID users. You should double check your overall disk and share setup. For example, what shares are set to reside only on the cache vs those that are set to utilize the array in some capacity? One last thing comes to mind, have you tried setting up Netdata docker? I've found Netdata to be a fabulous tool for looking at IOWAIT. Here's a resource regarding IOWAIT. https://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/

Well, when I started the array, unRAID automatically started a parity sync/rebuild.

When writing to disks in the array, parity writes are going to always be a speed limiter.

I ran make_bootable_mac for good measure. At first the thumb drive would not boot. Then I noticed that the option rom was enabled for the slot where the new LSI SAS HBA is installed. So, I disabled that and rebooted. Unraid booted up fine. So, this was the culprit. Not the thumb drive. Lol. Here is a link I found after figuring out my problem, where another user has the same problem unable to boot. The screen shots here are identical to my experience with my SuperMicro X8DT6. I read in the FreeNAS forum that some users have reported problems with multiple LSI 2008 SAS controllers with different firmware installed on each. So at this point, I can either pull the formatted array disk to try to do file recovery or run a rebuild on the disk to zero the disk/update parity for the array. I'm choosing to lose the data. To execute the rebuild, I would: 1. unassign the drive. 2. start the array. 3. stop the array. 4. reassign the drive. 5. start the array. a parity rebuild should begin. Is this what you recommend?

All bz* files copied to my thumb drive, overwriting the originals. No errors. No problems. Do I need to rerun "make bootable"?

Ok. That makes sense. I was able to copy all the files off the thumb drive with no problem. Now, I'll download the Unraid ZIP file and try to copy the bz* files to the thumb drive, overwriting them. I'll report back. Thanks for the suggestion.

itimpi - appreciate your reply. I was able to copy all the files off the UNRAID thumb drive to a folder on my Macbook. Looks like there are options to restore network, drive assignments, drive settings, and share settings. I can't seem to find anything in my search on how to get the current thumb drive to boot, without doing a START OVER. Is this possible? Is it as simple as rerunning the "make bootable" from the thumb drive?

I've been searching the forums for steps to take to recover my UNRAID thumb drive. Is there ANY REASON, in my scenario, NOT to perform a START OVER as described in the link below? https://wiki.unraid.net/Files_on_v6_boot_drive

****Update: There were kids involved. Turns out my son's friend was "helping" and they formatted the disk that showed "Unmountable: no file system" and then ended up turning the server off. When I returned home, the server was off. (I thought this odd, since it's connected to a UPS that is tested working.) That's when I couldn't boot into the unRAID thumb drive, as described above. What steps are recommended to get my thumb drive working and my array up? Can I use parity to rebuild the disk that was formatted? I will wait to get some help. Trying to avoid a data loss catastrophe. Thanks in advance.

The 9201-8i was installed with new SAS-to-SATA cables. Booted fine. Started rebuild as was instructed but noticed that the file system status showed "Unmountable: no file system". I paused the rebuild to find out whether this was normal. While the rebuild was paused, the system got inadvertently shut off while I was gone. When I turned the server back on it booted fine through the BIOS, but failed to load the unRAID thumb drive. I get "Reboot and Select proper Boot device". I tried the thumb drive in three different USB 2.0 ports. No luck. The thumb drive is fine. I am able to browse the device when connecting it to my Macbook.

Gotcha! Thank you.

Thanks for your input, johnnie.black. Yeah, the disk is perfect. Zero errors of any kind. As a little backstory, I had a similar thing occur on a different disk a few days ago, showing read errors and disabling the disk, but without this error message "program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO". At that time, reading the logs, I saw the issue related to the SATA cable. I replaced the cable and rebuilt the disk. Everything seemed fine. But then this happened with another disk. I replaced the SATA HBA with an LSI 9201-8i with brand new SAS-to-SATA cables. This should fix the problem. All my other disks running from onboard SAS or SATA2 have been peforming great. I appreciate your input. Thanks again.

Diagnostic zip file attached. I had a very new disk become disabled today due to read errors. The log shows "program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO". I think this means that the SATA HBA controller card, to which this drive is attached, is problematic/not supported. And I should replace it, probably with an LSI HBA. I'm looking for confirmation of this, or any suggestions. Update: 1. I rebooted to check the disk SMART data. And received pop up notification "Array Turned Good - Array has 0 disks with read errors." 2. I ran the SMART short self-test. Completed with no errors. Thank you in advance for your help.

Also, reverted back to 2.3.8-1-01, and all is working.

Thanks, Binhex!