phone guy
-
Posts
398 -
Joined
-
Last visited
-
Days Won
3
Posts posted by phone guy
-
-
On 9/19/2022 at 1:40 AM, Kyar said:
Hello someone succeeded to install on Proxmox server ?
I tried many method and all times "corrupted files" at 55%
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.
-
2 hours ago, pocopico said:
I need a tester for TCRP friend. Ideally one with a running system that needs to upgrade to TCRP Friend. If anyone is interested PM me.
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 ?
-
5 hours ago, wifi75 said:
hello tiny core red pill image it's not avilable, how I can download?
https://github.com/pocopico/tinycore-redpill
https://github.com/pocopico/tinycore-redpill/blob/main/tinycore-redpill-uefi.v0.8.0.0.img.gz
-
1
-
-
14 hours ago, mgrobins said:
yeah Im aware of that; also the flexibility of using the config settings to use what you want.
I think phone guy missed the point I was making. Most people won't have to worry about the GUI not matching their physical disks.
(Many people also consider a RAID array to be safe backup, or have no appreciation of the risks with rebuilds and disk failure... another point I was alluding to with the remarks about using only a few large disks).previous quote: I think a lot of NAS owners go and buy a few of the biggest disks they can and think they are proof against loss
.
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)
-
16 hours ago, merve04 said:
Thank you for your input on this, yes I have time to wait for a definitive answer.
15 hours ago, pocopico said:It doesn’t really matter what you enter here as long as it is a valid platform
ok @merve04 no excuse! keep us updated when you update successfully
-
1 hour ago, mgrobins said:
I guess most people will be fine with the retail versions - DS3622 being the largest. No compatibility restrictions and up to 12 disks.
I think a lot of NAS owners go and buy a few of the biggest disks they can and think they are proof against loss
.
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": { } } -
21 hours ago, merve04 said:
I much appreciate your reply on this, but once again i feel nervous about what to enter in "<yourplatform>", hence why i ask is inputing "geminilake-7.1.0-42661" the correct value for the process?
Thanks again.
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_42661You 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.
-
22 minutes ago, merve04 said:
Unfortunately I couldn’t tell y’a what exactly it does, and I’m still in the dark in the correct command procedure for applying an update to DSM. I’ve read if you don’t do it, machine goes in an infinite loop.
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.
-
28 minutes ago, merve04 said:
Not sure, but I’ve seen this posted several times, I’ve used it myself when building the loader in TC. I guess I figure since dva1622 is based of Geminilake that it would be the command line to use for post update. But I’m really not sure if it’s correct as when building the loader I never used the word “geminilake” in any of the commands.
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.
-
On 8/11/2022 at 4:59 PM, nexuscan said:
Hello to all,
I installed proxmox on baremetal and on that I installed one year ago DSM 7.0.1-42218 Update 3 with redpill (I dont know which version of redpill I have on the server).
Can someone help me: How to upgrade from DSM 7.0.1-42218 Update 3 to DSM 7.1-42661 on proxmox (or to 7.1.1-42951 RC)
Thanks,
Cheers!
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. 😉
-
1
-
18 hours ago, merve04 said:
For those who have update to latest version of DSM, if the following command correct?
Thanks in advance
./rploader.sh update sudo ./rploader.sh postupdate geminilake-7.1.0-42661 exitcheck.sh reboot
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?
-
3 hours ago, pocopico said:
I think RC is not a good idea anyway. They may shift the release level on final release. Please standby for final release for production systems
Yep, what he said.
10 hours ago, gadreel said:There is but you do not want to take that road.
You have to play with the disk mapping which most of the time is trial and error moving the disks around.
I recommend you to leave it as is...
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.
-
48 minutes ago, vbap said:
I am now considering converting my main NAS from tcrp-on-esxi to arpl-on-esxi...
@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.
-
2
-
-
On 8/8/2022 at 4:42 AM, phone guy said:
So you are if your at U3 already, you could update to U4 without running post update. If your on 7.1-u2,after manual update to u3 u4 then yes do the post update... That's what I'm hearing you say 😉
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. 👍
-
2
-
-
21 hours ago, Franks4fingers said:
Thanks for the info @phone guy
I presume by this I would have to remove the 3 drives that make up my SHR drive array today then........
Install a spare drive and then get Proxmox followed by TCRP followed by a generic Synology instance installed and running via your guide then.....
Start the process to install one new drive and complete the migration piece?
Just trying to get it clear in my head as to the high level steps as that makes it easier when doing the lower level steps.
Cheers
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!
DVA3221 loader development thread
in Developer Discussion Room
Posted · Edited by 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.