Mikael Juber Posted January 8 #51 Posted January 8 3 minutes ago, Peter Suh said: What type of media did you record the img file to? A USB stick? Do you have any additional external storage on your GEN10? yes... USB stick... no other external... 2 x internal SATA HDD, 2 x EVO970 plus on startech (PEX8M2E2) PCIE NVME card Quote
Peter Suh Posted January 8 #52 Posted January 8 (edited) 17 minutes ago, Mikael Juber said: yes... USB stick... no other external... 2 x internal SATA HDD, 2 x EVO970 plus on startech (PEX8M2E2) PCIE NVME card Which image from this list did you use? Is it the first mshell.img? And is your BIOS using Legacy (CSM) or UEFI boot? Edited January 8 by Peter Suh Quote
Mikael Juber Posted January 8 #53 Posted January 8 @Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick, but the nvme still not show on storage manager V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" already edit to V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" but when reboot it come back again to original... any option...? Quote
Peter Suh Posted January 8 #54 Posted January 8 1 minute ago, Mikael Juber said: @Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick, but the nvme still not show on storage manager V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" already edit to V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" but when reboot it come back again to original... any option...? The Synology model you are using now is DS3622xs+, right? I will come back after looking into how the program handles /etc.defaults/extensionPorts and how to find out the exact PCI address. I haven't used it for a long time, so my memory is hazy. Quote
Peter Suh Posted January 8 #55 Posted January 8 8 minutes ago, Mikael Juber said: @Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick, but the nvme still not show on storage manager V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" already edit to V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" but when reboot it come back again to original... any option...? /etc.defaults/synoinfo.conf Find the two items below and change them like this. supportnvme="yes" support_m2_pool="yes" Quote
Peter Suh Posted January 8 #56 Posted January 8 21 minutes ago, Mikael Juber said: @Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick, but the nvme still not show on storage manager V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" already edit to V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" but when reboot it come back again to original... any option...? Verify the address value once more with the results of the command below. ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme0n2 cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 cat /sys/block/nvme0n2/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 Quote
Peter Suh Posted January 8 #57 Posted January 8 (edited) 25 minutes ago, Mikael Juber said: @Peter Suh i manage to install and running DSM with your mshell, i change the USB Stick, but the nvme still not show on storage manager V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" already edit to V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" but when reboot it come back again to original... any option...? As long as the disks addon is used, it will just keep reverting to the wrong values on every reboot. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/disks/releases/install.sh#L384 Let me think about the method. Please answer my question first. Edited January 8 by Peter Suh Quote
Peter Suh Posted January 8 #58 Posted January 8 (edited) @Mikael Juber As of now, there seems to be a bug in the way disks addon handles /etc.defaults/extensionPorts. I think it would be better to change the Synology model to another one and migrate. These are completely different models that recognize the NVMe Cache. I recommend changing to the DS1621xs+, which is a Broadwellnk platform similar to the DS3622xs+. https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/disks/releases/install.sh#L460C50-L460C59 Edited January 8 by Peter Suh Quote
Mikael Juber Posted January 8 #59 Posted January 8 1 hour ago, Peter Suh said: Which image from this list did you use? Is it the first mshell.img? And is your BIOS using Legacy (CSM) or UEFI boot? using the first shell.img and UEFI boot Quote
Mikael Juber Posted January 8 #60 Posted January 8 1 hour ago, Peter Suh said: /etc.defaults/synoinfo.conf Find the two items below and change them like this. supportnvme="yes" support_m2_pool="yes" yes... already like that... no need to change it 1 hour ago, Peter Suh said: Verify the address value once more with the results of the command below. ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme0n2 V1902@Synology:/$ ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme1n1 i think it verified... Quote
Mikael Juber Posted January 8 #61 Posted January 8 (edited) 1 hour ago, Peter Suh said: cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 cat /sys/block/nvme0n2/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 this 2 command not show anything V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4 -sh: grap: command not found V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 cat: /sys/block/nvme0n2/uevent: No such file or directory V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme1n1 V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" Edited January 8 by Mikael Juber Quote
Mikael Juber Posted January 8 #62 Posted January 8 (edited) on the setup i think the Loader get the address correctly... already migrate to DS1621xs+... but still no luck showing the NVME drive on Storage Manager Edited January 8 by Mikael Juber Quote
Peter Suh Posted January 8 #63 Posted January 8 (edited) 1 hour ago, Mikael Juber said: this 2 command not show anything V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4 -sh: grap: command not found V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 cat: /sys/block/nvme0n2/uevent: No such file or directory V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme1n1 V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" A peculiarity of this card is that the disk add-on for REDPILL cannot find the PHYDEVPATH in /sys/block/nvme0n1/uevent. You can see what addons are there with the following command: cat /sys/block/nvme0n1/uevent Currently, all kinds of loaders ARC/RR/MSHELL use this disks as a common mandatory addon, so there is currently no way to exclude it and do the manual configuration you want. https://github.com/AuxXxilium/arc-addons/blob/main/disks/install.sh#L424 I will provide a script that can remove the disks addon from mshell. I think you should go back to DS3622xs+ and keep the settings you mentioned above. Edited January 8 by Peter Suh Quote
Peter Suh Posted January 8 #64 Posted January 8 @Mikael Juber If you see the loader build menu of mshell, log in with a separate ssh utility as tc/P@ssw0rd account and try the command below. After using this command, you need to rebuild the loader. After building the loader, disks should disappear from addons like this. When rebuilding, be sure to re-execute the menu with the ./menu.sh command in the SSH utility. You should never use the menu that appears in the xterminal. sed -i "3485s/^/# /" /home/tc/functions.sh sed -i '3513s/.*/ echo/' /home/tc/functions.sh jsonfile=$(jq 'del(.disks)' /home/tc/redpill-load/bundled-exts.json) && echo $jsonfile | jq . > /home/tc/redpill-load/bundled-exts.json Quote
Mikael Juber Posted January 8 #65 Posted January 8 49 minutes ago, Peter Suh said: You can see what addons are there with the following command: cat /sys/block/nvme0n1/uevent V1902@Synology:/$ cat /sys/block/nvme0n1/uevent MAJOR=259 MINOR=3 DEVNAME=nvme0n1 DEVTYPE=disk PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0 PHYSDEVBUS=pci PHYSDEVDRIVER=nvme V1902@Synology:/$ cat /sys/block/nvme1n1/uevent MAJOR=259 MINOR=0 DEVNAME=nvme1n1 DEVTYPE=disk PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:08.0/0000:0b:00.0 PHYSDEVBUS=pci PHYSDEVDRIVER=nvme 26 minutes ago, Peter Suh said: sed -i "3485s/^/# /" /home/tc/functions.sh sed -i '3513s/.*/ echo/' /home/tc/functions.sh jsonfile=$(jq 'del(.disks)' /home/tc/redpill-load/bundled-exts.json) && echo $jsonfile | jq . > /home/tc/redpill-load/bundled-exts.json will try... Quote
Peter Suh Posted January 8 #66 Posted January 8 1 hour ago, Mikael Juber said: this 2 command not show anything V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grap 'PHYDEVPATH' | cut -d'/' -f4 -sh: grap: command not found V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme0n2/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 cat: /sys/block/nvme0n2/uevent: No such file or directory V1902@Synology:/$ cat /sys/block/nvme0n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ cat /sys/block/nvme1n1/uevent | grep 'PHYDEVPATH' | cut -d'/' -f4 V1902@Synology:/$ ls -d /sys/block/nvme* /sys/block/nvme0n1 /sys/block/nvme1n1 V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:00:01.0" pci2="0000:00:01.0" There is a typo. It is PHYSDEVPATH not PHYDEVPATH. S is missing. Anyway, it seems like the result is getting the wrong BUS ID value (0000:00:01.0). cat /sys/block/nvme0n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 0000:00:01.0 cat /sys/block/nvme1n1/uevent | grep 'PHYSDEVPATH' | cut -d'/' -f4 0000:00:01.0 Quote
Peter Suh Posted January 8 #67 Posted January 8 @Mikael Juber The NVMe bus ID value may not be the last value you know (0000:09:00.0, 0000:0b:00.0). You can infer it with the following commands: lspci -nnq lspci -tvnnq Quote
Peter Suh Posted January 9 #68 Posted January 9 (edited) @Mikael Juber I think the part where the PCI BUS ID is taken from the disks addon needs to be improved, so I'm currently redesigning the fix. The last value in the device pass seems to be the PCI BUS ID, but the problem seems to be that the value right before it (the 4th field) is being taken by fixing it. I'm currently conducting my own test with my NVMe device. It has to do with the depth of the device pass. Usually, it's reported up to 3 depths, but in your case, it should be used up to 5 depths. PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0 PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0 If the same phenomenon as yours doesn't occur with my device, can I request a test? Edited January 9 by Peter Suh Quote
Peter Suh Posted January 9 #69 Posted January 9 2 hours ago, Peter Suh said: @Mikael Juber I think the part where the PCI BUS ID is taken from the disks addon needs to be improved, so I'm currently redesigning the fix. The last value in the device pass seems to be the PCI BUS ID, but the problem seems to be that the value right before it (the 4th field) is being taken by fixing it. I'm currently conducting my own test with my NVMe device. It has to do with the depth of the device pass. Usually, it's reported up to 3 depths, but in your case, it should be used up to 5 depths. PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0 PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0 If the same phenomenon as yours doesn't occur with my device, can I request a test? This is the intermediate result of the test. You can use both of the last BUS IDs for the PCI BUS ID. They are both recognized as unique values, so there seems to be no problem. My case is as follows, and your case will probably be like this. 0000:00:15.0 or 0000:03:00.0 PHYSDEVPATH=/devices/pci0000:00/0000:00:15.0/0000:03:00.0 0000:08:00.0 or 0000:09:00.0 PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0 However, I plan to use the output of the command below in my script to get the actual PCI BUS ID that Linux is pointing to: lspci -d ::108 Quote
Peter Suh Posted January 9 #70 Posted January 9 @Mikael Juber I have fixed the bug in disks addon and completed the redistribution. I tested it by mounting 3 nvme in vmware as follows. All 3 are recognized normally. https://github.com/PeterSuh-Q3/tcrp-addons/commit/0349887101cdd667e469326bbf5ac89321642309 # cat /etc.defaults/extensionPorts [pci] pci1="0000:03:00.0" pci2="0000:0b:00.0" pci3="0000:13:00.0" # lspci -d ::108 0000:03:00.0 Class 0108: Device 15ad:07f0 0000:0b:00.0 Class 0108: Device 15ad:07f0 0000:13:00.0 Class 0108: Device 15ad:07f0 Your case should be within the normal operating range now. Please stop using the script that excludes disks addon that I told you about yesterday and try using the modified disks. The command below is a script that restores the state worked on with 3 commands yesterday. curl -kLO https://github.com/PeterSuh-Q3/tinycore-redpill/raw/main/functions.sh Quote
Mikael Juber Posted January 9 #71 Posted January 9 @Peter Suh just got back from work... I don't got to do anything from last time you told me... So i don't need to run script... Since you already fix this bug, so what can must do now...? Download latest image and do the loader build again...? Quote
Peter Suh Posted January 9 #72 Posted January 9 54 minutes ago, Mikael Juber said: @Peter Suh just got back from work... I don't got to do anything from last time you told me... So i don't need to run script... Since you already fix this bug, so what can must do now...? Download latest image and do the loader build again...? The latest image will be updated automatically the moment menu.sh is executed. With this update, just rebuild the loader and check if the disks addon is visible again like I captured yesterday. Now, as I expected, you should see the cache. Please share your results. Your case is special. Quote
Mikael Juber Posted January 10 #73 Posted January 10 (edited) @Peter Suh i re-build the loader, and the address now correct V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" V1902@Synology:/$ sh-4.4# cat /sys/block/nvme0n1/uevent MAJOR=259 MINOR=0 DEVNAME=nvme0n1 DEVTYPE=disk PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:00.0/0000:09:00.0 PHYSDEVBUS=pci PHYSDEVDRIVER=nvme sh-4.4# cat /sys/block/nvme1n1/uevent MAJOR=259 MINOR=4 DEVNAME=nvme1n1 DEVTYPE=disk PHYSDEVPATH=/devices/pci0000:00/0000:00:01.0/0000:07:00.0/0000:08:08.0/0000:0b:00.0 PHYSDEVBUS=pci PHYSDEVDRIVER=nvme but still no nvme on storage manager... getting intresting... Edited January 10 by Mikael Juber Quote
Mikael Juber Posted January 10 #74 Posted January 10 (edited) supportnvme="yes" support_m2_pool="yes" this already like that on synoinfo.conf re-build to DS1621xs+ or the PCIe card not recognize...? Edited January 10 by Mikael Juber Quote
Peter Suh Posted January 10 #75 Posted January 10 (edited) 21 minutes ago, Mikael Juber said: supportnvme="yes" support_m2_pool="yes" this already like that on synoinfo.conf re-build to DS1621xs+ or the PCIe card not recognize...? V1902@Synology:/$ cat /etc.defaults/extensionPorts [pci] pci1="0000:09:00.0" pci2="0000:0b:00.0" Are these values checked from the beginning without any separate editing? And this time you should go back to DS3622xs+. If you don't see DS3622xs+ either Please try DVA3221 too. I will check the issue with DS1621xs+ separately. Edited January 10 by Peter Suh Quote
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.