RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

On 8/19/2021 at 12:01 PM, ThorGroup said:

It's recommended to use q35 for everything (not just here). It's a much newer platform and support a proper PCIe passthrough.

I see you're recommending changing VirtIO to e1000e - is the VirtIO broken on unRAID?


I've build RedPill and everything it running as intended, but I can't get any other vNIC to work except e1000e.

Both virtio and virtio-net aren't recognized. Anyone else tried this on UnRAID and gotten them to work? Would be nice to test higher speeds then 1Gbps.

Link to post
Share on other sites
1 hour ago, NeoID said:


I've build RedPill and everything it running as intended, but I can't get any other vNIC to work except e1000e.

Both virtio and virtio-net aren't recognized. Anyone else tried this on UnRAID and gotten them to work? Would be nice to test higher speeds then 1Gbps.

As far as I remember... Unraid Virtio were working fine. I doubt they changed anything to caused such issue.

Link to post
Share on other sites
7 hours ago, NeoID said:

At this point its unlikely that ThorGroup returns. Most likely due to personal reasons given that the repository is still active and the rather sudden silence after spending so much time responding to comments and giving long and incredible intriguing changelogs. I'm sure someone knows more, but nothing has been posted as of yet. Whether or not it's dead or just on hold all depends if someone else takes over the project. 

all speculation and guessing

i have one more, maybe its just one person and he/she had invested some time to make a working loader for 6.2.4/7.0 and as its working, all is documented and source is available there is no need to do more, drivers and other things can be delivered through other channels

and if there is need for more coding, all the documentation, source and forks can help to go on

i guess we are fine atm, working loader, source, documentation and next thing might be a pre-build loader or a (cloud/hosted) click and build solution to make it more accessible - either way the one doing this would be the one sticking his neck out

  • Confused 1
Link to post
Share on other sites
12 minutes ago, IG-88 said:

all speculation and guessing

i have one more, maybe its just one person and he/she had invested some time to make a working loader for 6.2.4/7.0 and as its working, all is documented and source is available there is no need to do more, drivers and other things can be delivered through other channels

and if there is need for more coding, all the documentation, source and forks can help to go on

i guess we are fine atm, working loader, source, documentation and next thing might be a pre-build loader or a (cloud/hosted) click and build solution to make it more accessible - either way the one doing this would be the one sticking his neck out

 

@IG-88 I would not agree more to your assumption...

In addition I know a lot of posts they mention that the loader is still under development, still on alpha stage etc... and you should not use this loader with the data that matter most to you. IMHO it does not matter if it's Red Pill or Jun's loader, the risk is always there, if you worry much about your data then it's better to buy an actual Synology...

Link to post
Share on other sites
1 hour ago, IG-88 said:

at least have some logs ready to post here

1st thing to check is logs and if does not make sense to you post it here

 

I'll look into dmesg and other logs to see if I can spot anything. I'm just testing out unRAID and I haven't found any way of getting serial output from it yet for easier debugging

Link to post
Share on other sites


bromolow_user_config.json:

{
  "extra_cmdline": {
    "vid": "0x46f4",
    "pid": "0x0001",
    "sn": "*******",
    "mac1": "xxxxxxxxxxxx",
    "mac2": "xxxxxxxxxxxx",
    "mac3": "xxxxxxxxxxxx",
    "netif_num": 3
  },
  "synoinfo": {},
  "ramdisk_copy": {}
}

 

bundled-exts.json:

{
  "thethorgroup.virtio": "https://github.com/jumkey/redpill-load/raw/develop/redpill-virtio/rpext-index.json",
  "thethorgroup.boot-wait": "https://github.com/jumkey/redpill-load/raw/develop/redpill-boot-wait/rpext-index.json"
}

 

unRAID xml:

...
    <interface type='bridge'>
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <source bridge='br0'/>
      <model type='e1000e'/>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <source bridge='br0'/>
      <model type='virtio-net'/>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='xx:xx:xx:xx:xx:xx'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </interface>
...


lsmod:
 

virtio_balloon          4629  0
virtio_scsi             9753  0
virtio_net             18933  0
virtio_blk              8528  0
virtio_pci              6925  0
virtio_mmio             3984  0
virtio_ring             8912  6 virtio_blk,virtio_net,virtio_pci,virtio_balloon,                                                                            virtio_mmio,virtio_scsi
virtio                  3602  6 virtio_blk,virtio_net,virtio_pci,virtio_balloon,                                                                            virtio_mmio,virtio_scsi

 

dmesg:

https://pastebin.com/BS0Br3nD

 

I can see that only the first vNIC works (e1000e), the other two do not show up in DSM and there is nothing in the dmesg-logs as far as I can tell. lspci lists them:

0000:03:00.0 Class 0200: Device 8086:10d3
0000:04:00.0 Class 0200: Device 1af4:1041 (rev 01)
0000:05:00.0 Class 00ff: Device 1af4:1045 (rev 01)
0000:06:00.0 Class 0200: Device 1af4:1041 (rev 01)
0000:07:00.0 Class 0780: Device 1af4:1043 (rev 01)
0001:07:00.0 Class 0106: Device 1b4b:9235 (rev 11)



 

Edited by NeoID
Link to post
Share on other sites
On 12/21/2021 at 1:46 PM, pocopico said:

I surely can see 8 drives configured on a VM with the following lspci

 

0000:0b:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS1068 PCI-X Fusion-MPT SAS (rev 01)
        DeviceName: SCSI0
        Subsystem: VMware Device 1976
        Kernel driver in use: mptsas
0000:13:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS1068 PCI-X Fusion-MPT SAS (rev 01)
        DeviceName: SCSI1
        Subsystem: VMware Device 1976
        Kernel driver in use: mptsas

 

For LSI SAS you should use the mptsas extension and for vmware paravirtual you need to use the :

https://raw.githubusercontent.com/pocopico/rp-ext/master/mptsas/rpext-index.json

 

For vmware paravirtual scsi :

https://raw.githubusercontent.com/pocopico/rp-ext/master/vmw_pvscsi/rpext-index.json

 

@pocopico Ahh, okay, I was using mpt2sas so I changed to using mptsas extension BUT I am still getting no drives detected when trying to install DSM. If I switch the virtual HDD to a SATA controller then it shows up as available to install DSM on.... So that being said, since I am using the correct driver now (mptsas) for LSI SAS virtual SCSI in ESXi.... is there something else I need to use to get virtual HDDs as SCSI to show up for DSM install? I also added the vmw_pvscsi extension to same loader and if I attach the same virtual HDD to a paravirtual SCSI controller, I get the same result, no drives detected for DSM install. Hoping I am just missing something simple here...

 

EDIT: If I telnet into the VM when DSM loader boots, and run lsmod, it does show mptsas and vmw_pvscsi modules in that list. But I can't seem to run lspci in telnet console to check that way, the command isn't found. And here is the full output: https://pastebin.com/NyfN3N2R

 

Seems like there is a point it does detect the SCSI disk because it decides to ignore it for a shim (which is correct I am assuming?), and then later on down when it runs the check mptsas script from the extension it says the module is not loader.... So maybe the mptsas and vmw_pvscsi modules really aren't getting loaded fully for some reason?

 

Module                  Size  Used by    Tainted: PF 
usbhid                 26503  0 
hid                    79391  1 usbhid
bromolow_synobios      70388  0 
adt7475                30106  0 
i2c_i801               11053  0 
nfsv3                  23713  0 
nfs                   130128  1 nfsv3
lockd                  72839  2 nfsv3,nfs
sunrpc                202956  3 nfsv3,nfs,lockd
i40e                  350790  0 
ixgbe                 274157  0 
igb                   180080  0 
i2c_algo_bit            5168  0 
e1000e                212512  0 
dca                     4576  2 ixgbe,igb
vxlan                  17560  0 
ip_tunnel              11368  1 vxlan
vfat                   10287  0 
fat                    51522  1 vfat
sg                     25890  0 
etxhci_hcd            135146  0 
vmxnet3                38645  0 
vmw_pvscsi             16080  0 
mptsas                 38167  0 
mptscsih               17934  1 mptsas
mptbase                62090  2 mptsas,mptscsih
usb_storage            48966  0 
xhci_hcd               85621  0 
uhci_hcd               23950  0 
ehci_pci                3904  0 
ehci_hcd               47493  1 ehci_pci
usbcore               208589  7 usbhid,etxhci_hcd,usb_storage,xhci_hcd,uhci_hcd,ehci_pci,ehci_hcd
usb_common              1560  1 usbcore
redpill               146375  0 

 

Edited by ilovepancakes
Added more details via telnet
Link to post
Share on other sites
1 hour ago, ilovepancakes said:

EDIT: If I telnet into the VM when DSM loader boots, and run lsmod, it does show mptsas and vmw_pvscsi modules in that list. But I can't seem to run lspci in telnet console to check that way, the command isn't found. And here is the full output: https://pastebin.com/NyfN3N2R

 

It could be because it goes way after the 15 drives limit , all the way up to SDAE 

 

Try to limit that with SataPortMap and DiskIdxMap ? I'm using SataPortMap=58 and DiskIdxMap=0A00

 

[ 3.105311] <redpill/scsi_notifier.c:91> Triggering SCSI_EVT_DEV_PROBED notifications - sd_probe() exit=0

[ 3.105465] sd 30:0:0:0: [sdae] 104857600 512-byte logical blocks: (53.6 GB/50.0 GiB)

-----

[ 3.107216] sd 30:0:0:0: [sdae] Attached SCSI disk

 

 

Edited by pocopico
Link to post
Share on other sites
2 hours ago, pocopico said:

 

It could be because it goes way after the 15 drives limit , all the way up to SDAE 

 

Try to limit that with SataPortMap and DiskIdxMap ? I'm using SataPortMap=58 and DiskIdxMap=0A00

 

[ 3.105311] <redpill/scsi_notifier.c:91> Triggering SCSI_EVT_DEV_PROBED notifications - sd_probe() exit=0

[ 3.105465] sd 30:0:0:0: [sdae] 104857600 512-byte logical blocks: (53.6 GB/50.0 GiB)

-----

[ 3.107216] sd 30:0:0:0: [sdae] Attached SCSI disk

 

 

 

So that helped sort of. Using vmw_pvscsi virtual disks, I can get them to show up in DSM. BUT, If I use DiskIdxMap=0A00 and SataPortMap=58 (with the loader on SATA 0:0 and first data disk on SCSI 0:0) the loader disk doesn't show up at all, which is fine and normal with SATA boot entry on RedPill. And the single SCSI data disk shows up as "Drive 6" in DSM. If I change the SataPortMap to equal just "1" the SCSI virtual disk moves to "Drive 2" on DSM.

 

This is all fine so far. But here is where it gets weird. If I add additional virtual disks to the same SCSI controller, they show up in Storage Manager but aren't usable for various reasons, mainly related to the Health status not showing up or showing "Not Supported" so something is failing with the SMART shim in redpill I guess? For example, if I leave DiskIdxMap=0A00 and SataPortMap=1 I see Drives listed on 2-7 (after adding a total of 6 virtual SCSI disks in ESXi). But, Drive 3-7 can't be used for a Storage Pool as the health status fails. Drive 2, the original drive DSM is installed on, shows Healthy and can be used.

 

If I change SataPortMap to 58, like you use, now only 3 disks total show up in Storage Manager rather than all 6. And they show up as Drives 6-8 with only Drive 7 showing up as "Healthy" and being usable. If I reboot, Drive 7 and 8 show healthy now, if I reboot again, only Drive 8 shows healthy. So clearly, something is going on with the SMART shim. I do notice that for the drives that show healthy, when they do, it shows a serial number for the virtual disk and a firmware version. I wonder if this is being reported by ESXi since it is paravirtual SCSI disks? If so, could there be a condition where the SMART shim is conflicting with some sort of partial SMART data ESXi is actually presenting to DSM?

 

To test that theory, I changed the virtual SCSI controller to LSI SAS instead of Vmware Paravirtual. With SataPortMap at 58 (to test original scenario) only 3 of the 6 data disks show up, with the listing starting at Drive 6. But they all show "Healthy". With SataPortMap=1 all 6 disks show up, starting at Drive 2 in Storage Manager, and all 6 are "Healthy" BUT when creating a storage pool, it fails. It just says DSM failed to create the storage pool using 1 more disks. And this is the case whether I try RAID1, RAID5, or even just a basic storage pool with 1 disk. It just doesn't like making a storage pool using a SCSI virtual disk....

 

Could it be the SataPortMap setting or DiskIdxMap? Is there another setting I could be missing. My config.json just has those two values defined plus a serial and mac of course. Extensions installed are the default TTG ones (boot-wait and virtio) plus vmxnet3, mptsas, and vmw_pvscsi.

Link to post
Share on other sites

Hello,

 

I have a DELL Optiplex 3020 with three SATA Ports:

 

SATA0: 128 GB SSD. ---> Visible in DSM7 as Disk#1

SATA1: 1 TB HDD.     ---> Visible in DSM7 as Disk#6

SATA2: 2 TB HDD.   ---> Visible in DSM7 as Disk#2

 

I used this config:

        "DiskIdxMap": "0",

        "SataPortMap": "8",

        "SasIdxMap": "0"

 

Could you please tell me, how to remap to

 

SATA0 -> Disk#1

SATA1 -> Disk#2

SATA2 -> DISK#3

 

Edited by pipsen
Link to post
Share on other sites
12 minutes ago, ilovepancakes said:

 

So that helped sort of. Using vmw_pvscsi virtual disks, I can get them to show up in DSM. BUT, If I use DiskIdxMap=0A00 and SataPortMap=58 (with the loader on SATA 0:0 and first data disk on SCSI 0:0) the loader disk doesn't show up at all, which is fine and normal with SATA boot entry on RedPill. And the single SCSI data disk shows up as "Drive 6" in DSM. If I change the SataPortMap to equal just "1" the SCSI virtual disk moves to "Drive 2" on DSM.

 

This is all fine so far. But here is where it gets weird. If I add additional virtual disks to the same SCSI controller, they show up in Storage Manager but aren't usable for various reasons, mainly related to the Health status not showing up or showing "Not Supported" so something is failing with the SMART shim in redpill I guess? For example, if I leave DiskIdxMap=0A00 and SataPortMap=1 I see Drives listed on 2-7 (after adding a total of 6 virtual SCSI disks in ESXi). But, Drive 3-7 can't be used for a Storage Pool as the health status fails. Drive 2, the original drive DSM is installed on, shows Healthy and can be used.

 

If I change SataPortMap to 58, like you use, now only 3 disks total show up in Storage Manager rather than all 6. And they show up as Drives 6-8 with only Drive 7 showing up as "Healthy" and being usable. If I reboot, Drive 7 and 8 show healthy now, if I reboot again, only Drive 8 shows healthy. So clearly, something is going on with the SMART shim. I do notice that for the drives that show healthy, when they do, it shows a serial number for the virtual disk and a firmware version. I wonder if this is being reported by ESXi since it is paravirtual SCSI disks? If so, could there be a condition where the SMART shim is conflicting with some sort of partial SMART data ESXi is actually presenting to DSM?

 

To test that theory, I changed the virtual SCSI controller to LSI SAS instead of Vmware Paravirtual. With SataPortMap at 58 (to test original scenario) only 3 of the 6 data disks show up, with the listing starting at Drive 6. But they all show "Healthy". With SataPortMap=1 all 6 disks show up, starting at Drive 2 in Storage Manager, and all 6 are "Healthy" BUT when creating a storage pool, it fails. It just says DSM failed to create the storage pool using 1 more disks. And this is the case whether I try RAID1, RAID5, or even just a basic storage pool with 1 disk. It just doesn't like making a storage pool using a SCSI virtual disk....

 

Could it be the SataPortMap setting or DiskIdxMap? Is there another setting I could be missing. My config.json just has those two values defined plus a serial and mac of course. Extensions installed are the default TTG ones (boot-wait and virtio) plus vmxnet3, mptsas, and vmw_pvscsi.

 

You need to understand what every option means first. Start by reading : 

https://gugucomputing.wordpress.com/2018/11/11/experiment-on-sata_args-in-grub-cfg/

 

And continue testing

 

Same applies for you @pipsen

Edited by pocopico
Link to post
Share on other sites

Hello guys, I have stupid question. I have followed the RedPill installation of DSM 7.0.1 and after few obstacles with drivers for SCSI adapter, I was able to run it.

Currently I have a screeen asking for PAT file. When I provide the path to file, it will start installation but approximately in half it stuck saing that installation failed.

 

Capture.JPG

Edited by djblond
Link to post
Share on other sites
7 hours ago, djblond said:

Hello guys, I have stupid question. I have followed the RedPill installation of DSM 7.0.1 and after few obstacles with drivers for SCSI adapter, I was able to run it.

Currently I have a screeen asking for PAT file. When I provide the path to file, it will start installation but approximately in half it stuck saing that installation failed.

 

Capture.JPG

What pat file did you use?

I used the original patfile from synology and also got the same screen.

The second time I used the pat file from the cache folder in the redpill folder and that worked for me.

Link to post
Share on other sites
What pat file did you use?
I used the original patfile from synology and also got the same screen.
The second time I used the pat file from the cache folder in the redpill folder and that worked for me.
As the builds are version specific you have to use the exact PAT file which the loader was built for/using. Simplest way to ensure you use the correct PAT is by copying it from the build cache.

Skickat från min GM1913 via Tapatalk

Link to post
Share on other sites
8 hours ago, djblond said:

Hello guys, I have stupid question. I have followed the RedPill installation of DSM 7.0.1 and after few obstacles with drivers for SCSI adapter, I was able to run it.

Currently I have a screeen asking for PAT file. When I provide the path to file, it will start installation but approximately in half it stuck saing that installation failed.

 

Capture.JPG


Check you VID:PID of your usb stick 

Link to post
Share on other sites

Hi @pocopico,

I have a HPE Micro Gen 10 (AMD) which I would like to experiment with  redpill boot loader and DSM 7.0.1.  Today I can run 6.2.3 using Jun's loader with 3617xs.

I used jimmyGALLAND's dev work to create a rebpill bootloader for DSM_7.0.1_3617xs but I am missing the TG3 driver.

Could you include in your git an entry for 3617xs?

https://github.com/pocopico/rp-ext/blob/main/tg3/rpext-index.json

  • Like 1
Link to post
Share on other sites
4 hours ago, Piteball said:

As the builds are version specific you have to use the exact PAT file which the loader was built for/using. Simplest way to ensure you use the correct PAT is by copying it from the build cache.

Skickat från min GM1913 via Tapatalk
 

 

Aaa good to know. I used the official from Synology.

Anyway, just tested again with the version from cache, but the same errro

Link to post
Share on other sites
7 minutes ago, djblond said:

 

I actually didnt change those (I used those which are in json).

And just for clarification, I am trying to run it on ESXi (not VMware Worsktation)

 

Pavel

SATA or USB Boot?

i got mine ESXi Test working with SATA Boot

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.