add virtio driver

[rayqusa]

hi, I know it seem ridiculous. but please add virtio driver so the installer can read disk from vultr block storage. it can installed, but cant read vultr drive

thank you

[rayqusa]

[PeterSuh-Q3]

It is already included in the integrated module pack.

https://github.com/PeterSuh-Q3/arpl-modules/blob/main/geminilake-4.4.180/virtio.ko

https://github.com/PeterSuh-Q3/arpl-modules/blob/main/geminilake-4.4.302/virtio.ko

[rayqusa]

but it still cant read vultr block storage

[PeterSuh-Q3]

but it still cant read vultr block storage

What is a vultr drive? Do you mean a virtual drive that exists in the cloud?

I had a quick look at the related stuff on the XPE forum. Below are the related searches. It seems that users who tried at the time were not successful. https://xpenology.com/forum/search/?q=vultr&quick=1

[rayqusa]

The last trial is 2019 and using Jun loader. If you been insert the driver, it might need a workaround

[PeterSuh-Q3]

I also seem to have tested it for a while in vultr at the time. I don't think I've even seen the storage at that time. I'll take the time to recreate it and tell you what's causing it. Or can I monitor your cloud for a second?

[rayqusa]

I have used 2 quota free trial this month. I am giving up so created a ticked here. how to create this issues?

1. download vmdk file from this repository
2. convert it into RAW
3. upload to dropbox
4. go to vultr > Orchestration > snapshot
5. give download link from dropbox.
6. if the given link fail to download by vultr, it bit tricky. download the file to your computer, then catch the downloadable link and paste to vultr link
7. go to cloud storage > create block storage > choose HDD > pick 40GB
8. go to deploy server > choose anything. pick from snapshot
9. after server running, go to block storage > then attach to the deployed server
10. go to compute. use the GUI to setting up loader
11. restart after setting up loader
12. enter your public IP:5000
13. viola, the synology cant read your cloud storage

[rayqusa]

fyi I havent try this one since I think it is unnessecary. and we have not create root access to synology

[PeterSuh-Q3]

fyi I havent try this one since I think it is unnessecary. and we have not create root access to synology

Looking at this image, I think I know why it can't find the storage. I need to analyze the script a bit more, but It seems that the part that only /dev/sd# is searched for as storage was hard-coded in pocopico's tcrp script or redpill. It looks like /dev/vd# is not being found.

[rayqusa]

would you like create special .raw files for vultr that search /dev/vd#? that would be fantastic, since I cant code

Thank you

[rayqusa]

hmm, it seem we can use digital ocean for this case. they use /dev/sda type

[PeterSuh-Q3]

Could you try creating a mount point with /dev/sd# first?

[rayqusa]

Could you try creating a mount point with /dev/sd# first?

for which? vultr? we cant choose. for digitalocean never try. going to try and give you an update

[rayqusa]

same with digital ocean

[rayqusa]

holy molly, it can read the hdd using broadwell. I am testing several thing right now. it is DO thought

I realize after read this. since I using 920 and 918, it cant read RAID/SCSI/HBA Controller

[rayqusa]

even it can detecting the HDD, it cant be installed. the reason as pict below. I have try DS3622xs and DS3622xs+

I have skimming in the forum that this happen because the system automatically update hence rejected by synology server

[rayqusa]

it this method successful, we have created onedrive or Gdrive. using synology sharesync and tailscale we can make sure our Nas with limited bandwidth and dynamic IP can serve our need.

[PeterSuh-Q3]

r1000 / v1000 is also a Device-Tree based model, so HBA cannot be used. If the automatic installation of the DSM Pat file does not proceed smoothly, Try using the separately downloaded Pat file for manual installation.

[PeterSuh-Q3]

However, seeing the phenomenon that it stops around 55 or 56% of 100% seems to be a situation I have experienced many times. This is not a problem with the PAT file. I think the SATA DOM bootloader is being used because it is virtually mounted. There is a problem where the three FAT partitions in this bootloader are not mounted properly in REDPILL. It seems that Chinese developers continued to improve this part until 3 months ago. But it's still not perfect. This problem still persists and there is no solution.

[rayqusa]

I am using manual install upload from my computer. I think it is time to move to another loader. Going to inform you if another loader successful

[rayqusa]

it seem your loader that only one can run up to installing pat, the other cant