Jump to content
XPEnology Community

phone guy

Member
  • Posts

    398
  • Joined

  • Last visited

  • Days Won

    3

phone guy last won the day on July 24 2022

phone guy had the most liked content!

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

phone guy's Achievements

Super Member

Super Member (5/7)

104

Reputation

  1. 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.
  2. 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
  3. @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.
  4. 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.
  5. 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.
  6. @pocopico Are there any clear instructions to update to the official 7.1.1-42962 ?
  7. https://github.com/pocopico/tinycore-redpill https://github.com/pocopico/tinycore-redpill/blob/main/tinycore-redpill-uefi.v0.8.0.0.img.gz
  8. 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)
  9. ok @merve04 no excuse! keep us updated when you update successfully
  10. 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": { } }
  11. 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
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...