phone guy

As an example, if your card does jbod or it mode, if you put that card and drives in a windows pc, it should see all those drives as independent drives automatically like they are connected to the local sata ports, and you should see serial/smart data aswell. if not, get a new card. Or find someone who is using your card in an xpen, truenas, unraid setup. in the end, we all want each drives passed thru to the host os. Some cards do it, while others just dont.

Many people got it working under proxmox. If you are getting 55% error, you have your proxmox settings wrong, or your loader (usb/sata) is visible dsm install process, and it shouldnt be. Try again. Look in my signature theres a how to redpill proxmox guide I wrote, I prefer to use a virtual usb as loader, because its simple, and it always works. Others like using a vdmk disk, which is still virtual. Real boxes use a usb type module, so that what I use...plus it works. Last make sure your cpu can handle whichever platform your testing (3221) must have fma3 or be haskell gen or newer. Very your methods, you missed something. good luck

@iceman your hba card must support IT mode to be used. IT mode does individual drive pass through to the host/os. Raid card do not, they handle all the drives, and then the host/os sees the card as 1 big storage device. (this explanation is a oversimplified, but it gets the point across) The card needs to pass each and every drive directly through to the os, so the os sees drive1/2/3/4 instead of "megaraid1" drive. So either see if your card has a jbod mode, or initiate target (IT) mode. if those are not possible, you need a it mode hba card.

I tried to PM you, says pocopico can not receive messages ? I have a baremetal nas now running tcrp 08.xx dsm7.1u4 ds918 and a proxmox server, running 8 drives on lsi hba card, tcrp 08.xx dsm7.1u4 PM me if I can help.

I know people have not had success with HBA/918 - however, 3622 with HBA works fine. The easier hurdle would be to find a way to transcode on 3622. I do not use transcoding on my setups, but there were a few software/docker mods that may lead you in the right direction. Or if all else fails, setup your media server (emby/plex/whatever) on a system that does transcoding as needed, and just have the nas handle storage - that's basically what I do, but I don't use transcoding - I direct play everything to my tv's. I remember seeing some ffdshow (?) docker that may help, look around in the software section, or re-think your media server situation, if you want to use HBA. Another option would be to use SATA AHCI cards instead of the HBA cards... @IG-88 has done several posts about sata cards and which chipsets give maximum performance and stuff like that. Basically you can't use a sata card that has a multiplexer, and I believe those sata pci cards have either a 4 drive or 5 driver per controller chip limit, so when you see one that says it can handle 10 drives, it most likely using a multiplexer unless the card has multiple controllers chips. Switching to a sata ahci pci card will work with 918 and then you can have the drive slots and transcoding. Hope that helps... good luck.

@pocopico Are there any clear instructions to update to the official 7.1.1-42962 ?

https://github.com/pocopico/tinycore-redpill https://github.com/pocopico/tinycore-redpill/blob/main/tinycore-redpill-uefi.v0.8.0.0.img.gz

Again I'll ask, as opposed to what? I mean a nas, a raid array, a shr array, is a collection of disks with or without parity. You either use a mirror, or 1 or 2 drive parity, either 2 hdds or 16 disks. I am not missing the point, or maybe I am? but you are missing my question...which is what other options are there? Having 16 disks only improves iops over say 4 disks. not "proof against loss". afaik besides the graphic, I see no difference between platforms (except quicksync maybe, and lsi card compatibility). I am happy to see the other models being offered by @Peter Suh and thankful to him for developing them, I am trying to establish what other safety against loss one model/platform offers over another? I personally am running a 3 copies of data (main unit on shr1 with 2 backups to two other nas devices as hb and fsync + snap-reps, so 3 copies of data)

ok @merve04 no excuse! keep us updated when you update successfully

as apposed to what exactly? (and the max disk is 16 btw on 3622, but I think on any? only difference being the graphics. I run a 918 on a 5 bay too) { "extra_cmdline": { "pid": "pid", "vid": "vid", "sn": "serial", "mac1": "mac", "SataPortMap": "6", "DiskIdxMap": "00" }, "synoinfo": { "internalportcfg" : "0xffff", "maxdisks" : "16", "support_bde_internal_10g" : "no", "support_disk_compatibility" : "no", "support_memory_compatibility" : "no" }, "ramdisk_copy": { } }

I personally have not built or used a dva1622 except to test if it would load on my cpu, but taken from the first page of this thread, I have to assume the correct postupdate command to update dsm7.1 to 7.1u4 on a dva1622 is: ./rploader.sh postupdate dva1622_42661 You might wait until @pocopico or another user confirms this. But I see no reason this would not be the case. <yourplatform> for dva1622 is dva1622_42661

I wrote this in another thread, someone asked how to update from DSM7.0 to DSM7.1 Update 4 on Proxmox, so I am posting these instructions here to, if it helps anyone in the future. This won't reflect everyone's situation, these were just the directions for this particular user, but the general method is applicable for upgrades from 7.0 to 7.1. FIRST: If at all possible, backup any important data because sometimes bad things happen, period! (ok, now that's out of the way proceed at your risk) Establish which platform your build is for (DS918/DS3622/etc). Establish what your current redpill booting method is (USB/SATA). I am going to assume you know the basics of building a loader from here on out, like SSH, watching boot screens and grub menu's in proxmox, etc... Verify you have a Serial port 1 console added to your DSM VM in Proxmox. If you don't have one, add it in proxmox now, this helps verify everything is working as expected, and takes the guess work out. If you don't have a Serial console on your DSM VM, add it and reboot the working DSM VM and open the serial console quickly by double clicking on the name of the VM or right clicking on the name of the DSM VM and open the console (this will open a new tab or window depending on your browser), and watch it so you can see what it says and looks like on a successful working DSM boot, it will fly by lines of code and processes which is normal and when its done successfully booting you will see it echo "DSM Login:" or something like that, and just a few lines above that it will show you the IP of your dsm vm. At this point you should have seen what the console will look like on a successful DSM boot. Reboot your DSM VM back to TinyCore by watching the boot screen grub menu in proxmox and pressing the down arrow on the keyboard to the last grub menu item that says TINYCORE and press Enter, SSH into your TinyCore session and do the following commands: ./rploader.sh backup now ./rploader.sh update now ./rploader.sh fullupgrade now Now reboot your DSM VM again back to DSM by selecting your original loader boot method (USB/SATA) the upgrade you just did will not affect your current working system at this point, go to synology.com and download the 7.1 with update 1 file for your platform, this file will be about 300mb in size. Also download the 7.1u4 file for your platform, this file will only be about 50mb in size. Manually update your system to 7.1u1 (the big file only) inside DSM (control panel->upgrade) and allow it to restart. Depending on how and when you created your first original Redpill, it should work without issue. If you run into a problem at this stage, I'll add something at the bottom, but it should work, as I remember 7.0.1 and 7.1 both worked at the same time so you'll be fine. You can open the serial console in proxmox during the booting and watch its display to verify its booting normal with the DSM LOGIN: as the sign of successful update, just like it did before. Now, at this stage, you should have an updated/fullupgrade redpill tinycore, a working DS#### platform running DSM7.1u1. At this point you can manually upgrade to the 7.1u4 the small 50mb file only. When the system reboots, click back to proxmox and during its reboot, again, boot to TinyCore (last menu item) and SSH into your TinyCore session and run the ./rploader.sh postupdate <platform> command. That will do its thing, update your loader, restore the backup you made earlier and work. Reboot again, go back to proxmox and boot whatever your normal boot method was (USB or SATA whichever you used originally) and you should have a working DSM7.1u4. Hold off on the 7.1.1RC until it's official, that's my suggestion. ./rploader.sh postupdate <platform> In the unlikely event your DSM7.1u1 doesn't start up correctly after the manual update, you can boot into tinycore, ssh in, and do a ./rploader.sh restoresession command, add whatever ext drivers you had before (nic, etc) and the build command, as an example: ./rploader.sh build broadwellnk-7.1.0-42661 and reboot, and the restore should retain your serial/mac numbers and you will boot to 7.1u1 no matter what now, and you can proceed to step 7 to update to 7.1u4.

If you're talking about the 7.1u4 update, it's pretty simple... assuming you are on 7.1, you download the 7.1u4 update for your platform go to synology.com and get the 7.1 update 4 file for your platform (dva1622-7.1u4) which should be around 50mb. Do the manual upgrade inside DSM, on the reboot, at the grub menu, press down arrow on the keyboard to the bottom item which is boot into tinycore, ssh in to your tinycore session and do these commands ./rploader.sh backup now ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh postupdate <yourplatform> reboot and change grub menu back to original loader method That's pretty much it. Has worked for me on DS918 (apollolake-7.1.0-42661) and DS3622 (broadwellnk-7.1.0-42661) and boom, 7.1u4! EDIT: I literally just wrote this full guide for a guy trying to upgrade from 7.0 to 7.1u4, its super detailed, so if you need any more guidance, just ask.

I have never used that command (exitcheck.sh) in any of my builds, test builds, etc. Never saw that mentioned before. Thanks for the reply.

As far as I know, this kind of information is saved on the DRIVE not in DSM. There are some reports of clearing smart data on certain drive manufactures (google it) but this WILL NOT cure any potential problems you have/had with your drives. If smart is reporting it, its probably accurate. Tampering with the smart data could potentially damage your drives, so I would not suggest it.

If it were me, here's how I would do it. (there is probably easier way, but this is how I would do it without fear) FIRST: If at all possible, backup any important data because sometimes bad things happen, period! (ok, now that's out of the way proceed at your risk) Establish which platform your build is for (DS918/DS3622/etc). Establish what your current redpill booting method is (USB/SATA). I am going to assume you know the basics of building a loader from here on out, like SSH, watching boot screens and grub menu's in proxmox, etc... Verify you have a Serial port 1 console added to your DSM VM in Proxmox. If you don't have one, add it in proxmox now, this helps verify everything is working as expected, and takes the guess work out. If you don't have a Serial console on your DSM VM, add it and reboot the working DSM VM and open the serial console quickly by double clicking on the name of the VM or right clicking on the name of the DSM VM and open the console (this will open a new tab or window depending on your browser), and watch it so you can see what it says and looks like on a successful working DSM boot, it will fly by lines of code and processes which is normal and when its done successfully booting you will see it echo "DSM Login:" or something like that, and just a few lines above that it will show you the IP of your dsm vm. (if you look at my signature at the bottom of this message there is a link to the guide for installing redpill on proxmox, and it shows how to add a serial console with pictures and everything). At this point you should have seen what the console will look like on a successful DSM boot. Restart/Reboot your DSM VM back to TinyCore by watching the boot screen in proxmox and pressing the down arrow on the keyboard to the last grub menu item that says TINYCORE and press Enter, SSH into your TinyCore session and do ./rploader.sh to establish which version of rploader.sh you are running (this really doesn't matter, but if you want to know which version you started from). While you are there, you can do the backup, update and fullupgrade of rploader. Commands are ./rploader.sh backup now / ./rploader.sh update now / ./rploader.sh fullupgrade now . Let it do it's thing and this will get you to the latest stable release of Redpill, which you will need to install 7.1u4. ./rploader.sh backup now ./rploader.sh update now ./rploader.sh fullupgrade now Now reboot your DSM VM again back to DSM by selecting your original loader boot method (USB/SATA) the upgrade you just did will not affect your current working system at this point, go to synology.com and download the 7.1 with update 1 file for your platform, this file will be about 300mb in size. Also download the 7.1u4 file for your platform, this file will only be about 30mb in size. Manually update your system to 7.1u1 (the big file only) inside DSM (control panel->upgrade) and allow it to restart. Depending on how and when you created your first original Redpill, it should work without issue. If you run into a problem at this stage, I'll add something at the bottom, but it should work, as I remember 7.0.1 and 7.1 both worked at the same time so you'll be fine. You can open the serial console in proxmox during the booting and watch its display to verify its booting normal with the DSM LOGIN: as the sign of successful update, just like it did before. Now, at this stage, you should have an updated/fullupgrade redpill tinycore, a working DS#### platform running DSM7.1u1. At this point you can manually upgrade to the 7.1u4 the small 30mb file only. When the system reboots, click back to proxmox and during its reboot, again, boot to TinyCore (last menu item) and SSH into your TinyCore session and run the ./rploader.sh postupdate <platform> command. That will do its thing, update your loader, restore the backup you made earlier and work. Reboot again, go back to proxmox and boot whatever your normal boot method was (USB or SATA whichever you used originally) and you should have a working DSM7.1u4. Hold off on the 7.1.1RC until it's official, that's my suggestion. ./rploader.sh postupdate <platform> In the unlikely event your DSM7.1u1 doesn't start up correctly, you can boot into tinycore, ssh in, and try the ./rploader.sh postupdate <platform> command now and reboot back to DSM, but I don't think this will be an issue. If you still can not get back into DSM after the 7.1u1 update and the postupdate command, simply re-build the loader with your fully current and updated redpill. Do a ./rploader.sh restoresession command, add whatever ext drivers you had before (nic, etc) and the build command, as an example: ./rploader.sh build broadwellnk-7.1.0-42661 and reboot, and the restore should retain your serial/mac numbers and you will boot to 7.1u1 no matter what now, and you can proceed to step 7 to update to 7.1u4. Good luck! Post your results, Mark this reply as ANSWERED and press the thanks button. 😉

what is exitcheck.sh ?

Is it possible to add jun mode to an already made loader? or just rebuild with same user/info and add jun to build?

Yep, what he said. Yep, what he said. Good work fellas, keeping everybody straight and narrow!🤣

Subject says it all. Can you use SAS drives in a redpill build, not SATA. Of course using a SAS hba card.

I have a couple questions about DVA3221. Does ram play a part in how well the AI work or function of the Nas/nvr in general? How much ram are you guys using? What's acceptable? 8gb? 4gb? 32gb? What cameras are acceptable? Does it only work with ip cameras? Is there any certain specific for a camera to look for? I've got a 5mp system of HD over analog cctv cameras now, the cameras are BnC, so I'm sure there's no way to use these 8 cameras? Not even sure how to interface them to a pc but even if that were possible I'm sure it wouldn't work in a Synology build, but maybe something that might convert them into something addressable on the network? Not sure. Well that's it for now. Thanks to anyone for replying.

918 + HBA = problems. I use ds3622 broadwellnk platform with HBA + 8 hdds and I get real smart data/serial/etc from hdds, but I do not need or use quicksync... so I can see the problem. I wanted to let you know, for sure, hba and 3622 platform works fine...Sorry I have nothing productive to add, I hope you are able to get it sorted.

@pocopico@fbelavenuto I am glad ARPL is excellent, because it is! but is there any reason to change or update from existing TCRP builds to ARPL? btw: one of my favorite parts of arpl is that once its booted successfully, it shows the login ip of your dsm instance. Thats a winner, and I am sure that screen saves a lot of guess work especially for beginners.

Answer my own question for anyone else curious, updating from 7.1u3 (already did the postupdate process for u3) YES you can safely update to u4 without going back to TC, no need to re-run postupdate process again. 👍

Well, I wouldn't say you physically need to remove them per se, you will need a boot drive to install and build you proxmox obviously. Then once you get a working proxmox, you build your redpill loader using whatever method you feel comfortable using, my guide is just the way I did it.. at that time I could not find a english guide, so I wrote one to help others. I pieced mine together from other language posts and videos. But once you get a proxmox up and running, then redpill up and running, at that point you can passthrough your individual disk to your dsm instance inside proxmox (google it or read thru the proxmox wiki or forums). You can either pass thru the disks or a sata controller or whatever you want, I personally pass thru a PCI HBA card, which gives me 8 sata ports and I get real smart data from the HDDs and everything. HBA cards flashed to IT mode can be had on eBay for about $50USD with cables (search ebay for HBA IT MODE)... mounting 8 HDDs is another matter but that's all up to you. if you pass the disks, as I understand it, you won't get smart data from the HDDs, which is why I used the HBA - but that's not the only way to do it. But either way WILL work in DSM just fine. edit: To be clear, you can pass all 3 disks at the same time (your SHR array), when you bootup redpill with the disks passed thru to DSM, dsm should see them as previously used in another dsm, and if the serial/model numbers are different (from your first dsm #1 to your new dsm #2) it will ask to migrate them to your new synology, if the serial/model numbers are the same it will either work or ask to repair them first and then work. Anyway, at this point you should have a dedicated proxmox boot drive, a working redpill VM, so after you remove your 30gb virtual drive and pass your existing SHR disks to redpill/proxmox (while DSM VM is OFF obviously), when you boot up and log into you DSM, storage manager should see your drives and ask you to migrate them or re-assemble/repair them in to your current setup. Yeah, it shouldn't be too difficult. BE SURE TO BACKUP YOUR DATA JUST IN CASE. Because bad things happen, period. If I can help, let me know. GOOD LUCK!