Balrog

I think that this issue has nothing to do with the boot sdcard. The error points to the first partition where the DSM itself is installed. I assume that maybe logfiles or something in this direction is filling up the space. You can make a quick check if you connect as root via ssh and type "df -h" ("df" stands for "disk free" and "-h" for "human readable"). Then you get an overview over the partitions and the free space on it. Here an example: root@joe:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 1.2G 1.1G 52% / I would use afterwards "ncdu / -x" which will output what directories and files are consuming the space. On my installation I have installed "optware-ng" and I am sure that "ncdu" is part of optware. So you must search for how installing "optware-ng" if you want use "ncdu". An alternative which runs out of the box but without the nice navigation options from ncdu is "du -chx / | more". This command gives you also the output which folders and files are using the space on the root partition but just as a pure list without a navigation option. I hope this helps to get an idea how to manage the problem with no space available for the update.

Nice that you found a solution and post it.

I would boot a Linux live system from an USB-Stick and have a look how the SATA-Ports are shown to the system. Then you will not have to guess and can give the loader exactly information about the SATA-Controller/-Ports.

If you just booted from the usb-stick and not have installed DSM via the assistant than you can't login to the system. If DSM is installed you can login as "root" if you wish or with "admin" and change to root afterwards (the same way you use if you login via ssh).

Can you please write is the transfer speed of this setup is sufficient for you? I have a similar setup (the only difference is that I make a complete passthrough of the H310 HBA instead of making RDMs of the single disks) and think about updating from 6.2 to 6.2.1. But I want to make this step only if the transfer speed is similar to the 6.2-setup.

Thank you for the summarization and sharing your experiences!

@flyride: Thanks for the link to your article from march! I missed it and the information in it is very useful.

Thanks for the pictures! It seems that you are right with the idea of the internal hdd as a "save harbour" for the dsm itself. The dsm partition is a mirror and the "repair" forces a sync which seems to be needed as the usb harddisks are recognised slower than internal hdd harddisks. But if this is the only issue I think you can live with it especially as this is only a backup system.

@shrabok: Thank you very much for your article and your experiences with this idea. I have a few questions: - Do your end configuration is a SHR1 Volume consisting the 2 TB internal hard disk AND all external USB-Drives or do you use the internal drive as a "basic" drive without redundancy and have made a SHR1-Array only with the external USB-Drives? - Does your SHR1 Volume survive a reboot without breaking the the array? Or are you forced to rebuild the array after every reboot? - do you get issues with the sleep mode of the USB drives? Most of them have a real aggressive power save mode build in and maybe this will lead to problems. For my USB drives (which are currently working as normal external USB drives) I have written a little script which runs at start to disable the sleep mode (or better explained to lower the load/unload-cycles).

Nice finding. i hope there will be some time an update for the vmxnet3 driver as it has much advantages over the pure intel driver.

Sorry for posting in english here: It works very well! Thank you very much! Copy modules and set the correct rights: cp /volume2/data/HP_AMS_DSM_6.2/amsHelper /sbin chown root:root /sbin/amsHelper chmod 755 /sbin/amsHelper cp /volume2/data/HP_AMS_DSM_6.2/hpilo.ko /lib/modules chown root:root /lib/modules/hpilo.ko chmod 644 /lib/modules/hpilo.ko Then activate it: insmod /lib/modules/hpilo.ko /sbin/amsHelper -I0 -M1,5,14,16,18,23,99 Automatic activation after every boot: - Create a startup-script with the following content in \usr\local\etc\rc.d\S99HP-AMS.sh #!/bin/sh modprobe hpilo /sbin/amsHelper -I0 -M1,5,14,16,18,23,99 (make sure to set the startup-script to 755 ) I attached the result as a picture. All sensors were read and the fan is going down to 10%. :-)

Sorry but you have to do your homework and read by yourself a little bit with the given information. In short: "in IT-Mode the HBA (this is the H200) exposes all connected harddisks as themselves to the operating system whereas the original firmware sums the harddisks up in, for example a raid 1 (mirror) and exposes this raid 1 to the operating system (which you don't want for the usage in DSM). Best of luck to you.

No, I don't know the card you posted. I only want to give a hint which cards are working proved well. This is the manual I used to flash: https://techmattr.wordpress.com/2013/08/30/sas-hba-crossflashing-or-flashing-to-it-mode/ Of course as I said: it is hard if you never made such processes but I hope you get what I mean. Maybe you can buy an already flashed Dell H200 in IT-Mode on eBay? A quick search for "dell h200 it mode" gives me multiple results. Here a 2 examples where you can see what I mean: https://www.ebay.com/itm/Dell-H200-6Gbps-SAS-HBA-w-LSI-9211-8i-P20-IT-Mode-for-ZFS-FreeNAS-unRAID/163142320696 https://www.ebay.com/itm/Dell-PERC-H200-SAS-Controller-IT-mode-2x-cable-SFF-8087-to-4x-SAS-SATA/123126065790 These cards are working (if they are in good condition of course).

My suggestion is: use an IBM M1015 or Dell H200/H310 (these adapters I use by myself) flashed to IT-firmware. It's a little hard to read through the howto if you never made this before but it works for me for about 3 years now. Afterwards you get 8 internally usable ports which are recognised by DSM.

I am waiting for this too as I have no use for plex and my Xpenology 6.1.7 under Vmware 6.5 on HP Microserver Gen8 is working awesome.

Did you use the VMXNET3 or E1000 as vNIC?

If you mount the "synoboot.img" with OSFMount you can see that there are 3 different boot-settings in the loader: "DS918+ 6.2 Baremetal" "DS918+ 6.2 Baremetal Reinstall" "DS918+ 6.2 VMWare/ESXI" I will play around with the settings and try an update of a running VMware Workstation Test-VM under DSM 6.1.x.

You can exchange the loader 1.02a with 1.02b. You just have to make the same changes of the mac-address and sn in the config file as usal. Have a look into the "how to-threads" here. There will be explained the process.

In the 1.02a-loader is a bug where you have to copy drivers manually after an upgrade of DSM. I would suggest to try the actual loader 1.02b. For debugging purposes it is also good to have access via putty over a serial connection. With this way you be able to see the whole boot process. I made a thread here in the forum with a manual how to do this.

So it's a problem with proxmox and not the H200 itself.I ran for about 2 years DSM with a bare metal installation due to problems with passthrough the H200 under ESXi 6.0. The situation is much better with ESXi 6.5 now.

I use the ds3615xs version. Its working for years now and I see no advantage for me in using the ds3617xs. Before inserting the H200 into the server I flashed it with the newest firmware to 20.00.07. In the early versions of P20-firmware was a bug but version 20.00.04 and after are fine. You can have a deeper look here: https://forums.servethehome.com/index.php?threads/tutorial-updating-ibm-m1015-lsi-9211-8i-firmware-on-uefi-systems.11462/ I dont know if it is the point where it hangs at your site but this is was I have done. Afterwards I put the card into the Server and passed it through the VM with success.

It is possible that the serial port function is only available with a licensed esxi-host but I am not sure about this. Sent from my SM-T810 using Tapatalk

So this is the md5 for the first package of 6.1.4-15217: de53ef411024536dd4c47517a9b8979d This is the md5 for the new release of 6.1.4-15217: 23acaefffb0d01aa9f57870fcfcfb887 It seems that mainly hda1.tgz is different in the pat-files (I decompressed them with 7-zip). I have decompressed hda1.tgz multiple times to be able to compare the files: - a lot of .so-files are different in /usr/lib - a lot of .so-files are different in /usr/syno/synoman/webapi/lib - a lot of "style.css"-files a different in various folders So it seems that the new 6.1.4-15217 is truely a new release with new content.

Nice. I will do it this evening after work. Gladly I even downloaded the original md5 from the first package.

I have downloaded the 6.1.4 package but not installed it. If there is a fresh release I can compare the content of the new package with the abandoned 6.1.4-package.