phone guy

@Peter Suh Nevermind, I got it. I did have an issue, but here is what I did for anyone else who may want to use this to update a headless system like this one is. I have included the PuTTY logs for you to review. You have to install grubmenu on the sudo -i root, otherwise I got a permission denied. I had to be in root@dsm:~# to install and execute grubmenu. You can see I had to sudo -i and verify I was at the right level where Xpenology_backup was located. However, ./grubmenu.sh 3 did not make the system boot back to TC - I didn't catch it in PuTTY but it said it was going to reboot to usb - reinstall DSM (see log below) root@DSM:/# cd tmp root@DSM:/tmp# ./grubmenu.sh 3 -ash: ./grubmenu.sh: Permission denied root@DSM:/tmp# sudo ./grubmenu.sh 3 sudo: unable to execute ./grubmenu.sh: Permission denied root@DSM:/tmp# sudo -i root@DSM:~# ls Xpenology_backup root@DSM:~# curl --location "https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/grubmenu.sh" --output grubmenu.sh; chmod +x grubmenu.sh; % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 2441 100 2441 0 0 4454 0 --:--:-- --:--:-- --:--:-- 19373 root@DSM:~# ls grubmenu.sh Xpenology_backup root@DSM:~# ./grubmenu.sh 3 Mounting /dev/synoboot1 to /mnt/localdiskp1 grub boot partition mounted normally. Entries in Localdisk bootloader : ======================================================================= menuentry 'RedPill DS918+ v7.1.0-42661 (USB, Verbose)' { menuentry 'RedPill DS918+ v7.1.0-42661 (SATA, Verbose)' { menuentry 'Tiny Core Image Build' { Setting default boot entry to USB Re-Install DSM / Tiny Core Image Build root@DSM:~# So, luckily I waited until I was at the location of this device, I was going to try to do this over a remote session/team viewer, but I waited until I was actually at this location to do this upgrade. After I gave it the command ./grubmenu.sh 3 (and missed the response it was going to boot usb to re-install dsm) and manually installed the 7.1u4 update inside DSM, when it rebooted, it did NOT go to TC - it booted back USB and was stuck in a loop, I used advanced ip scanner to detect it was booting back to it's DSM spoofed mac (the one i configued in user_config.json), so I had to hook up a keyboard (no monitor, this box doesn't have any video out) power cycled the box and continued to hit down arrow ⬇️ for about 10 seconds, then I hit enter, which did boot to TC, again I used advanced ip scanner and found the "real mac" printed on the device and its current ip. I proceeded to TC/SSH and ./rploader.sh backup/update/fullupgrade/postupdate commands, then I had to install grubmenu.sh again using: curl --location "https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/grubmenu.sh" --output grubmenu.sh; chmod +x grubmenu.sh; This installs grubmenu.sh inside TC (because before it's installed on DSM which is not mounted inside TC). Then I did ./grubmenu.sh 1 and it echo back with the following, I sudo reboot and DSM booted back to an updated DSM 7.1u4 as normal. I am not sure this was necessary, as I did not ls to see if grubmenu.sh was installed? so I made sure it was installed. This may not have been needed? tc@box:~$ curl --location "https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/grubmenu.sh" --output grubmenu.sh; chmod +x grubmenu.sh; % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 2441 100 2441 0 0 4158 0 --:--:-- --:--:-- --:--:-- 4158 tc@box:~$ ./grubmenu.sh 1 Mounting /dev/sdd1 to /mnt/localdiskp1 grub boot partition mounted normally. Entries in Localdisk bootloader : ======================================================================= menuentry 'RedPill DS918+ v7.1.0-42661 (USB, Verbose)' { menuentry 'RedPill DS918+ v7.1.0-42661 (SATA, Verbose)' { menuentry 'Tiny Core Image Build' { Setting default boot entry to USB tc@box:~$ sudo reboot SO: I am not sure why ./grubmenu.sh 3 did NOT make it boot back to TC, but I included the putty log for you to see. Had that worked, this would have been a breeze. Because that didn't do what it was supposed to do, I'm glad I was here to figure it out and fix it, but something went wrong? not sure what. I wanted to tell you and give you the feedback considering I know how hard you work in your scripts. Thank you for your continued efforts!

@Peter Suh ./grubmenu.sh says permission denied ... so steps I followed are: Login to DSM via SSH (windows putty app) using my user credentials. sudo -i and re-enter my password change dir to tmp (cd tmp) [root@dsm:/tmp] I downloaded using curl --location "https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/grubmenu.sh" --output grubmenu.sh; chmod +x grubmenu.sh; I tried ./grubmenu.sh 3 and I got permission denied so I again issued chmod +x grubmenu.sh I did a ls to list directory, and grubmenu.sh is green I tried sudo ./grubmenu.sh 3 and again permission denied So I don't know what do to now.

Dude, I never thought of that 😂 That's priceless.

@Peter Suh To make sure before I start this process, can you verify this will do what I want? I will install this in DSM using SSH. Update DSM to latest update U4 grubmenu 3 and reboot to TC SSH to TC and run postupdate command in TC grubmenu 1 (to boot USB) reboot back to DSM and I should be good, am I correct? This is a headless system with no video out, so I will not be able to see the grubmenu - I hope this works the way I expect. I will wait until I hear back from you before I start the process... THANKS!

I can tell you from experience, igpu passthrough in proxmox is tricky at best. Discrete gpu passthrough is much easier (ie: dedicated video card). iGPU passthrough is not impossible but very finicky. At least that was my personal experience, you may have better luck. I personally tried with an i7 4790 (if I remember right) and simply could not make windows work with the igpu. It would see it, and BSOD trying to install drivers for it. Again, my experience, not necessarily your experience. As to the 1070 card, someone earlier in this thread said there was a way to install an earlier version of SS, then un-install and re-install newer version to get drivers for older/other nvidia cards to work, but I never tried so - you would have to look back through the pages and see if that works, or as @Orphée said, maybe 3219 model may be better solution. Be sure to keep us posted what you try and what works and what doesn't - that's how we all learn.

I personally never use RC's of any software, operating systems, nas os, mobile os, nothing. When a build hits the RC stage, its not long before the actual release comes along, and in my opinion, its better to wait for the actual release. Plus it will be easier in the long run for users to upgrade from a current released version of DSM to another released version of DSM. My advice to all is skip the RC and wait for the official release and the magic will happen.

In theory, if all DSM data is all on separate drives, like you have drives 2, 3 and 4 all dedicated drives for dsm, if you installed proxmox, and successfully build a redpill loader, you should be able to pass thru those individual drives, insert them one at a time, and it (dsm7) should ask you to migrate them from your previous build. It would be like pulling the drives from a 918 DSM6 and putting them into a new 918 or 920 DSM7 or whatever. I would always suggest backing up your data before anything, because you should, mistakes and bad things happen all the time. So backup to be safe. But if you install proxmox, go thru the steps with a virtual 30gb drive in proxmox, make sure you got your loader working (network, any add-ons, etc), then you can remove the virtual 30gb test drive in proxmox, follow the steps to pass thru your data set drives inside proxmox (google it), when you power back up redpill inside proxmox it will see them (make sure they are in the right order to be safe, though it shouldn't matter but its easy to do, so do it anyway) and ask to migrate them... it should be fairly simple. Good luck.

I believe the answer is YES. should be natively supported as AHCI device.

Well, I tried adding the ip of ds3622 to host file, flushed dns and restarted windows. No change, but I was able to take some screen shots to show the speed difference. I swear, I'm not crazy 🤣 I tried to get the address bar in the pictures so you can see the device name vs the IP. The IP transfers faster. Dont know why. I have to assume its a windows issue? But no clue what issue that might be.

I guess is the grand scheme of things, redpill will always be considered test software, unstable, not for production use....? But most of us here consider it stable enough for our needs. I have an 8 bay system as my main backup server for my real syno hardware...plus 3 other re-purposed nas boxes now converted to redpill 7.1U3 so.... I would say its rock solid, but YMMV. I know some people run into little problems like getting certain apps to authorize (advanced media extensions comes to mind), which affects HEVC and AAC, but there are work arounds. I remember seeing someone say VMM was giving them issues, but I am not sure.... I would say try it yourself, under your specific needs and you tell us if its ready for prime time in your opinion.

If the upgrade is failing inside dsm, maybe you downloaded the wrong update file. THIS LINK is for U4 for the DS3622xs+, I assume you can update directly to u4 from u1? I never tried it so I don't know for sure that would work. If that file fails under dsm, you may have to upgrade to U2, then U3 <run postupdate> and then U4. I know after U3 update you will have to reboot to TC and do backup/update/full upgrade/postupdate commands. I am not 100% sure if that step is required for U4, as I have personally not done that update yet. but I know it is required for U3. Good luck

Here is a guide to install redpill on proxmox with pictures to follow, be sure to edit any filenames with newest released versions (ie: tcrp 046 to tcrp 0800 for example). As for hard drive, remember proxmox needs a boot drive, so you can not eliminate lvm, better to passthru another hdd for dsm, or build redpilll baremetal and bypass proxmox all together. proxmox guide:

I only say : from 7.1 u3 to u4, it seems no need to do postupdate after GUI update. 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 😉

The thing was, if the name was in the destination address bar the speeds were slow, if the IP was in the address bar the speed was fast. Both ip. I'm not 1000% sure which one is the name (ds3622) but I would have to imagine it's 100,because 101 was just added. It's like by using the name in the destination address is the issue, switch to IP for the address makes it nearly twice as fast? I don't see this on genuine sybo boxes, only on my redpill box. I'm not even sure it's a redpill thing? It might just as easily be a windows thing? Having to resolve "ds3622" to an up slowing it down? That's why I asked, I have no clue... I'm willing to test suggestions. Just tell me what to test.

I have a kind of related question for everybody.... I have a proxmox redpill DS3622 build. Running paravirtual NIC in Proxmox with V9F ext drivers. I also have a PCI passthru Ethernet port, I used one of the intel ports onboard from the server motherboard. Both work fine, the Intel NIC in pci pass thru didn't require any additional ext drivers to work. Each has its own different IP, they are not bonded, so I know which port I am using. I am getting different smb speeds when copying over the network in Windows. Scenario 1: In windows, open network, open icon for DS3622, open temp shared folder, now drag and drop 1.1gb file.. I get a maximum transfer of 60mb/sec (\\ds3622\temp) Scenario 2: Change location in windows explorer to direct ip (\\192.168.1.100\temp) I get 110mb/sec. The proxmox virtual nic is ip 100, and the pci passthru is ip 101 (\\192.168.1.101\temp), same speeds on either direct ip. So if the window shows a direct ip in the location, the speed is nearly doubled. If it show ds3622 its about half speed...? any clue? This is a repeatable experiment. I get similar results from different pcs on the lan, different files, and the results almost always the same, give or take a few mbs/sec

Are you saying you can make 918/DVA3221 work on cpu older than Haswell? (xeon E5-2650v2) ???

Wanted to add some info here. I recently changed the motherboard in my proxmox server, where my DS3622xs+ redpill lives. Previously I had a motherboard and PCI HBA card (H710), the new motherboard has a build-in HBA (well, I flashed it to HBA). So after flashing the IT mode FW, and using LSIUTIL, with many thanks to @exodius for this great topic, I reconnected all 8 of my drives to the motherboard SFF HBA ports, and booted back to proxmox and my dsm instance. It originally came up showing all 8 drives, all green, but the serial number order was all off, but DSM didn't complain (which I thought was strange). So all my drives are labelled with serial numbers from Seagate (ironwolf's) and I labelled them with drive slot numbers (1-8). So after bootup drive 1 was now 3, 2 was now 8, etc, etc... but dsm said the array was healthy and no errors. (remember I changed motherboards, and now using built in HBA vs PCI card HBA before) I didn't like that since I had them labelled just because of this. So, I powered down, restarted DSM and it booted to a DSM desktop with no drives (I didn't think it would but it did), and I re-attached each drive from 1 thru 8 one drive at a time and they all re-appeared in the correct slot order and cable order, which was not the case when it powered up with all 8 attached on initial power up. So now all are serial correct, slot correct, numbered correct, and cable correct (drive 1 is SFF port A cable P1 and so on) I just wanted to thank the OP again for this trick, and share my experience as it may help someone in the future, if your drives end up out of order, disconnect them all and re-attached (insert) them 1 drive at a time from drive 1 and continue thru until the end, that should get them back in the correct order.

I would be surprised if its not strictly enforced on that model considering its target audience. There are ways around the compatibility list, but it will revert back after certain upgrades I've been told. Its just modifying the list that contains the compatible drives, you just add your drive to the list. Google it, its posted in several places as people use that trick on real hardware too.

What I need personally is, the DSM has a custom mac and I know which IP it is, or you can find it easy with find.synology.com. But when the baremetal system boots with TC, it uses the real hardware mac, so the IP changes, and that box is headless, so I can not load terminal and use ifconfig to see ip. If TC could use the same mac, it would boot with the same ip as dsm, so I would know where it is. Otherwise I have to search the dhcp server for the genuine hardware mac address to find the ip tc gets. But I understand pocopico has to edit anything with tc. I just need a better way to find the ip of tc when it boots headless. I dont know of any tricks to do that.

Excellent, I was looking for something exactly like this. I would like to make a request @Peter Suh can you add a way to edit the mac address during a tinycore session? That way when a baremetal build boots to tc, it would have the same ip as it does when it boots usb/sata to DSM, and it will be simple to find.

Did you install the ext (drivers) for whichever network you are emulating in unraid? I think there is a step by step tutorial for unraid in the tutorials section

I could do this, but I just saw the post somewhere here describing how to do exactly this process I described, I am on the hunt for that right now... if I dont find that, I may re-do that box as a DS920-JUN mode device, its a 4 bay with Pentium CPU so it will perform just like a 920, or close enough. But thanks for the advice. As I said, its remote, I dont always have physical access to this device. Thats why I am trying to do it this way. And as my reply above, I literally just saw a post explaining these needed steps, and I mistakenly did not bookmark the right post. For now I'm on a mission.

Happy to help when I know the answer 🖖

I have a question, this was discussed before and I thought I bookmarked it, but I was wrong. I have a remote headless baremetal build, and I need to edit the grub menu so on reboot it will boot back to TC automatically, so I can run the postupdate command, then edit the grub again so it will automatically boot from usb. I cant seem to find that post again. This would be my steps Edit grub to boot TC by default Update DSM to U3 and reboot into TC Connect to TC SSH run the postupdate commands Edit grub while in SSH of TC to boot USB by default Reboot and boot back to DSM as usual

Just FYI, I tested DVA1622 on my Proxmox, but the acpid arpl installed did not work on that build (dva1622). I had the same issue in TCRP and DS3622xs+ (my production build I am using daily). I had to use another acpid for 3622 under tcrp for it to work. I have not tested it with ARPL, but the acpid I used with @pocopico tcrp on 3622 (thanks to @dodo-dk) ./rploader.sh ext broadwellnk-7.1.0-42661 add https://raw.githubusercontent.com/dodo-dk/rp-ext/main/acpid/rpext-index.json Again I have not tested this with ARPL, just saying this was the only acpid that would shutdown my DS3622xs+ loader made with TCRP when I hit shutdown in Proxmox.