gquiring Posted April 14, 2021 Share #1 Posted April 14, 2021 I ran into a really weird issue recently. I have qty 3 TheCUS N5550's running DSM 6.x using Jun's loader 1.03b. I used one of these NAS drives to stream movies to Kodi, it works perfectly. I decided to take another TheCUS N5550 and it would constantly stutter trying to play any video on Kodi or a Windows PC. I then tried a 3rd TheCUS N5550 and it had the same problem. So why did one work and two did not? I went through all the settings and everything was identical. They are all plugged into the same network switch. The only difference was two of the three TheCUS's had Cruzer USB sticks for Jun's loader, the working TheCUS had a Sandisk. I then built two new USB sticks using Sandisk. Now the other TheCUS's work fine. Why would a USB stick influence the performance of the NAS? Quote Link to comment Share on other sites More sharing options...
IG-88 Posted April 14, 2021 Share #2 Posted April 14, 2021 17 hours ago, gquiring said: Why would a USB stick influence the performance of the NAS? the usb flsh drive itself is just for loading the kernel, dsm even unmounts the usb after starting dsm i see some possible sources 1. the usb device itself is producing some kind interference to the system - you could check that by using the old usb again, check if the problem is there and then remove the usb and check again, as long as you dont reboot the nas the usb is not needed 2. driver problems, maybe you used a different extra.lzma containing different driver versions (mainly nic driver) - but i thing thats unlikely also to make sure there are no other interference's i would disconnect the other nas from network when testing btw cruzer is a sandisk brand (i'm using sandisk cruzer fit and ultra fit for my nas) Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 14, 2021 Author Share #3 Posted April 14, 2021 I got the name wrong, they are Transcend USB sticks. Not that it should matter but I'm still royally confused over the whole thing. It got more confusing when I pulled the working drives and wanted to build DSM on a single drive for some testing. With the Sandisk USB it refused to load DSM, always spitting out error 13, file corrupt. Yet with the other drives it works. ???? After several tries and reading that many times the error 13 is the PID/VID I got crazy and said let's see what happens if I set the PID=0000 and the VID=0000 in the grub.cfg. It worked, I was able to load DSM. So when/why is the PID/VID actually used, I had always assumed if they were wrong nothing would work. Quote Link to comment Share on other sites More sharing options...
IG-88 Posted April 14, 2021 Share #4 Posted April 14, 2021 1 hour ago, gquiring said: After several tries and reading that many times the error 13 is the PID/VID I got crazy and said let's see what happens if I set the PID=0000 and the VID=0000 in the grub.cfg. It worked, I was able to load DSM. So when/why is the PID/VID actually used, I had always assumed if they were wrong nothing would work. interesting, what do you see as usb vid/pid when you use a live linux from the usb in question on the CUS (checking if bios of CUS does anything unusual to usb device)? wrong vid/pid would also prevent dsm from starting properly (not just installing) - at least on my systems, it does not show up in network and serial console show "mount faild" i doe remember some people having vid/pid right and getting error 13 on install can you check one anotheer wrong then 0000/0000 like 1111/1111 just to make sure 0000/0000 is not special? Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 14, 2021 Author Share #5 Posted April 14, 2021 Changed the PID=1111 VID=1111, boots and works no issues. I did not try and load DSM, it took the current disk, did a recovery, rebooted to DSM Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 15, 2021 Author Share #6 Posted April 15, 2021 (edited) This makes zero sense. I tried installing a fresh copy of DSM with the 1111/1111 and got error 13. I pulled the USB and stuck the 0000/0000 in there and got error 13. What really concerns me is I cannot install DSM 6.2.4 on any of my TheCUS's it won't work. If you try and install anything less than 6.2.4.25426 it won't let you. It apparently is going out the Internet and checking something. So I blocked the IP for the TheCUS in the firewall to not allow any Internet and then the install won't even run! So if Synology would bite the dust someday we cannot reinstall the OS. So what happens when Synology says the minimum install is 6.2.4, manual installs won't work. Edited April 15, 2021 by gquiring Quote Link to comment Share on other sites More sharing options...
IG-88 Posted April 15, 2021 Share #7 Posted April 15, 2021 22 minutes ago, gquiring said: Changed the PID=1111 VID=1111, boots and works no issues. I did not try and load DSM, it took the current disk, did a recovery, rebooted to DSM if you started dsm with 1111,1111 too then it seems like every other vid/pid then the real one does work, pretty odd as its usually the other way around i guess thats something only jun himself could answer as its seem closely related to how the loader works (code wise) Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 15, 2021 Author Share #8 Posted April 15, 2021 Something seemed too obvious to me and sure enough I got part of it figured out. Something is changing the USB stick contents! The 0000/0000 stick would no longer install DSM. I took it back to the Windows PC and rewrote the image. Stuck it back in the TheCUS and DSM loaded with no issues. Quote Link to comment Share on other sites More sharing options...
bearcat Posted April 18, 2021 Share #9 Posted April 18, 2021 On 4/15/2021 at 2:16 AM, gquiring said: What really concerns me is I cannot install DSM 6.2.4 on any of my TheCUS's it won't work. ... You *do* know that there is a known issue in regards to 6.2.4? No one has been able to install/run that on *any* non-syno hardware (none validated installs). Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 18, 2021 Author Share #10 Posted April 18, 2021 4 hours ago, bearcat said: You *do* know that there is a known issue in regards to 6.2.4? No one has been able to install/run that on *any* non-syno hardware (none validated installs). No kidding, I am fully aware of that issue. I just wanted to point out Synology limits what version you can install (that I was not aware of). So what happens when the minimum dated install is 6.2.4, that is what I am talking about. Quote Link to comment Share on other sites More sharing options...
flyride Posted April 19, 2021 Share #11 Posted April 19, 2021 On 4/14/2021 at 5:20 PM, IG-88 said: if you started dsm with 1111,1111 too then it seems like every other vid/pid then the real one does work, pretty odd as its usually the other way around i guess thats something only jun himself could answer as its seem closely related to how the loader works (code wise) AFAIK VID/PID tells real Syno code what the bootloader device is so that it hides it properly. Since it is hardcoded and the VID/PID is Synology's it is a simple way for Syno to ensure DSM doesn't run on non-Synology hardware (except if hacked). VID/PID error is essentially their code rejecting non-Syno hardware. 3 hours ago, gquiring said: No kidding, I am fully aware of that issue. I just wanted to point out Synology limits what version you can install (that I was not aware of). So what happens when the minimum dated install is 6.2.4, that is what I am talking about. Anytime you attempt a (6.2.4) install on a loader device, it will write those files to the loader and then it cannot install a version earlier than that. It doesn't matter if it worked or not. So just write a new clean loader from a fresh download and this problem you have will be gone. This is the way it's always been. 1 Quote Link to comment Share on other sites More sharing options...
IG-88 Posted April 19, 2021 Share #12 Posted April 19, 2021 14 hours ago, flyride said: AFAIK VID/PID tells real Syno code what the bootloader device is so that it hides it properly. Since it is hardcoded and the VID/PID is Synology's it is a simple way for Syno to ensure DSM doesn't run on non-Synology hardware (except if hacked). VID/PID error is essentially their code rejecting non-Syno hardware. its "masking" it to show it as f400/f400 to the system - can be seen when using lsusb 1-7 f400:f400:0100 00 2.10 480MBit/s 224mA 1IF (SanDisk Ultra Fit) and just to make sure some readers of the thread don't get the wrong idea, its not just the usb vid/pid beside other things dsm also checks the presence of pci devices too to make sure its running on the "right" hardware (the loader "generates" them, can be check with lspci -k), so just having a (reprogrammed) usb with f400/f400 is of no use (but can be in some cases for original units when the original usb dom is broken) the "impossible" thing here is that it did not work with the vid/pid of the usb but with any other, as if the code logic was inverted the 6.2.4 was a recent addition in that thread we had cases where people had the right usb vid/pid and got error13, maybe they would have got it working by deliberately mismatching the usb vid/pid - for obvious reasons i never suggested something like that (maybe next time , seems to be a rare case) Quote Link to comment Share on other sites More sharing options...
bearcat Posted April 24, 2021 Share #13 Posted April 24, 2021 On 4/19/2021 at 12:53 AM, gquiring said: I am fully aware of that issue On 4/18/2021 at 8:23 PM, bearcat said: What really concerns me is I cannot install DSM 6.2.4 No kidding, if you are fully aware of that issue, why does it really concerns you ? Just as flyride said, that is "working" as expected, and not a Synology restriction. On 4/19/2021 at 4:24 AM, flyride said: Anytime you attempt a (6.2.4) install on a loader device, it will write those files to the loader and then it cannot install a version earlier than that. Quote Link to comment Share on other sites More sharing options...
gquiring Posted April 24, 2021 Author Share #14 Posted April 24, 2021 30 minutes ago, bearcat said: No kidding, if you are fully aware of that issue, why does it really concerns you ? Just as flyride said, that is "working" as expected, and not a Synology restriction. If you can't get what I am trying to say I suggest you move on to troll some other thread. 1 Quote Link to comment Share on other sites More sharing options...
bearcat Posted April 25, 2021 Share #15 Posted April 25, 2021 @gquiring If I don't get what you are "trying to say", maybe you are not expressing yourself well. No one is trolling here (unless you are?). 1 - You state you are concerned that you can not install 6.2.4 2 - You state that you are fully aware of the issue in regards to 6.2.4 Why in the world are you concerned about not being able to install 6.2.4? is my question to you. If you for some reason *need* 6.2.4 (or "better") for now, get yourself a real Synology. Do not expect a working bootloader for 6.2.4 to surface until *after* the release of DSM7. 1 Quote Link to comment Share on other sites More sharing options...
asheenlevrai Posted July 7, 2021 Share #16 Posted July 7, 2021 On 4/25/2021 at 11:13 PM, bearcat said: Do not expect a working bootloader for 6.2.4 to surface until *after* the release of DSM7. Interesting... Does that mean that XPEnology is intentionally staying 1 version behind the current DSM version? For "political" reasons or something? (I'd be totally comfortable with this, just curious...) Thanks -a- Quote Link to comment Share on other sites More sharing options...
gquiring Posted July 7, 2021 Author Share #17 Posted July 7, 2021 59 minutes ago, asheenlevrai said: Interesting... Does that mean that XPEnology is intentionally staying 1 version behind the current DSM version? For "political" reasons or something? (I'd be totally comfortable with this, just curious...) Thanks -a- It's not political. The person who developed the loader lost interest in maintaining it. He won't release the source code for the loader. If he would release the source code I am sure someone else could keep it current. 1 Quote Link to comment Share on other sites More sharing options...
asheenlevrai Posted July 7, 2021 Share #18 Posted July 7, 2021 12 minutes ago, gquiring said: It's not political. The person who developed the loader lost interest in maintaining it. He won't release the source code for the loader. If he would release the source code I am sure someone else could keep it current. Are you talking about Jun? @jun? Does that mean XPEnology is more or less a dead end now? I'm asking because I just found out about it and I am currently switching most of my older DSes to Xpen rigs. I might reconsider if there is no way forward for Xpen. I hope the source code for the loader is released if this is the case. This is a great project. Best, -a- Quote Link to comment Share on other sites More sharing options...
gquiring Posted July 7, 2021 Author Share #19 Posted July 7, 2021 Just now, asheenlevrai said: Are you talking about Jun? @jun? Does that mean XPEnology is more or less a dead end now? I'm asking because I just found out about it and I am currently switching most of my older DSes to Xpen rigs. I might reconsider if there is no way forward for Xpen. I hope the source code for the loader is released if this is the case. This is a great project. Best, -a- Yes Jun. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.