Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

1 hour ago, ThorGroup said:

Can you post the full dmesg? I also see your RTC is not working - did you pull the newest release? The one you're using seems to be lacking RTC support.

 

I have used the redpill toolchain v0.4 and force switch to the original repo instead of jumkey's one.

The full dmesg is attached.  nothing with boot_device_shim, and no rtc.

DSM7_918dmesg.txt

 

I have also tried apollolake + 6.2.4, the same.

In short, 3615 works fine, 918 do not.

 

p.s. the same proxmox is running a DS918 with jun's loader rock solid.

 

For comparison, I also attached the dmesg of 3615 DSM 6.2.4. The file is much larger as it is a full boot to the DSM.

DSM624_3615_dmesgout.txt

Edited by mcdull
Link to comment
Share on other sites

5 hours ago, mcdull said:

you are right, nothing with boot_device_shim.

but I am using proxmox, and this should not be an expected behaviour, right?  Although I am using AMD CPU and qmeu64 as machine type.

 



[    5.762165] usb-storage 2-1:1.0: USB Mass Storage device detected
[    5.764347] scsi host12: usb-storage 2-1:1.0

However, the DSM itself should see the usb mass storage. 

 

@mcdull I looked into Jun's loader console and both loaders they mention that "I am running an Intel Kernel on AMD"... but like your last post also my DS918+ has been running Rock Solid under Unraid for years now. Never crashed etc... I do not know if it will be a big issue in the new loader... I do not want to bother ThorGroup for clarification for the time being since the loader is still under development and not so relevant...

Edited by gadreel
Link to comment
Share on other sites

1 minute ago, gadreel said:

 

@mcdull I looked into Jun's loader console and both loaders they mention that "I am running an Intel Kernel on AMD"... but like your last post also my DS918+ has been running Rock Solid under Unraid for years now. Never crashed etc... I do not know if it will be a big issue in the new loader... I do not want to bother ThorGroup for clarification for the time being since the loader is still under development...

I run it under Proxmox.  Its rock solid, except Virtual machine does not work. 

There is no need to use VMM if I have proxmox anyway

  • Like 1
Link to comment
Share on other sites

Hi, with the GIT-changes from today, the builded IMG dosn´t work anymore. (DS3615xs_6.2.4-25556 on Proxmox 7 with same Settings as before).

Builded with Linux sources.

 

Spoiler

[    2.847386] pci 0001:0a:00.0: Can't map mv9235 registers
[    2.848386] ahci: probe of 0001:0a:00.0 failed with error -22
[    2.849370] <redpill/virtual_pci.c:488> Added device with new bus @ bus=0a dev=00 fn=00
[    2.850537] <redpill/pci_shim.c:209> vPCI device created successfully
[    2.851340] <redpill/pci_shim.c:212> PCI shim registered
[    2.852092] <redpill/sanitize_cmdline.c:156> !!BUG!! Failed to locate original cmdline
[    2.853271] <redpill/redpill_main.c:48> RedPill cannot be loaded, error=-2

 

 


[  197.148591] BUG: unable to handle kernel paging request at ffffffffa0000c10
[  197.148591] IP: [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591] PGD 1810067 PUD 1811063 PMD 1b6e5a067 PTE 0
[  197.148591] Oops: 0010 [#350] SMP 
[  197.148591] Modules linked in:
[  197.148591] CPU: 3 PID: 3687 Comm: init Tainted: GF     D    O 3.10.105 #25556
[  197.148591] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  197.148591] task: ffff8801b6d6e040 ti: ffff8801b7124000 task.ti: ffff8801b7124000
[  197.148591] RIP: 0010:[<ffffffffa0000c10>]  [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591] RSP: 0018:ffff8801b7127f50  EFLAGS: 00010202
[  197.148591] RAX: ffffffffa0000c10 RBX: 0000000000000000 RCX: 0000000000000000
[  197.148591] RDX: 0000000000f54010 RSI: 00007ffff94b7960 RDI: 00007ffff94b785a
[  197.148591] RBP: 0000000000000000 R08: 00007ffff94b786d R09: ff646b6e726d6e62
[  197.148591] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
[  197.148591] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  197.148591] FS:  00007fb45ce2d700(0000) GS:ffff8801bfd80000(0000) knlGS:0000000000000000
[  197.148591] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  197.148591] CR2: ffffffffa0000c10 CR3: 00000001b1716000 CR4: 00000000000006e0
[  197.148591] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  197.148591] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  197.148591] Stack:
[  197.148591]  ffffffff814cfdc4 0000000000000000 0000000000000014 00007ffff94b785a
[  197.148591]  0000000000f54010 00007ffff94b7840 00007ffff94b7960 0000000000000206
[  197.148591]  0000000000000000 ff646b6e726d6e62 00007ffff94b786d 000000000000003b
[  197.148591] Call Trace:
[  197.148591]  [<ffffffff814cfdc4>] ? system_call_fastpath+0x22/0x27
[  197.148591]  [<ffffffff814cfd11>] ? system_call_after_swapgs+0xae/0x13f
[  197.148591] Code:  Bad RIP value.
[  197.148591] RIP  [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591]  RSP <ffff8801b7127f50>
[  197.148591] CR2: ffffffffa0000c10
[  197.148591] ---[ end trace 3aa30e997e1a20db ]---

 

Edit: Works now with the new changes, Thanks.

 

Edited by dodo-dk
Link to comment
Share on other sites

12 hours ago, ThorGroup said:
15 hours ago, jarugut said:

The bootloader for DS918+ DSM7 with  drivers integrated works fine on QNAP hardware. I've tested the same USB on other Barametal but I received error 13 or file corrupted, but in the qnap ts453a works perfectly

Can you post the install log from /var/log of the install?

 

Hi Thorgroup, on the /var/log not exist any install log sorry, I've checke in the USB too but not exist this file.

 

 

image.thumb.png.603320a3e0090692612f7eb43bfe59ca.png

 

Do you have enough with the dmesg output? do you need that I will reinstalled from the scratch the qnap with the same USB to check if the install file will be created?

dmesg.out

Link to comment
Share on other sites

17 hours ago, Aigor said:

Download plip 

https://download.plop.at/files/bootmngr/plpbt-5.0.15.zip

unzip, you obtain a iso file, connect them to VM as boot CDROM 
when usb-key is ready, put it into esxi host, on VM add usb host device and you should see usb key.
Boot with plip, at prompt, boot usb and you can boot vm from image into usb key.

 

This was the method I was talking about in earlier posts that doesn't work for me.... you are able to boot a physical USB this way? It definitely boots? When I choose the USB stick in plip the screen just freezes and it never boots. If you are able to boot the USB do you still get Error 13 on install or DSM installs and actually works?

Link to comment
Share on other sites

14 minutes ago, jarugut said:

Hi Thorgroup, on the /var/log not exist any install log sorry, I've checke in the USB too but not exist this file.

 

I think the file they mention in the var/log is the message file. The output of the dmesg is that message file that you have in your var/log. If you look inside you will find the records during the update. But the dmesg outpout is still fine.

Link to comment
Share on other sites

33 minutes ago, ilovepancakes said:

 

This was the method I was talking about in earlier posts that doesn't work for me.... you are able to boot a physical USB this way? It definitely boots? When I choose the USB stick in plip the screen just freezes and it never boots. If you are able to boot the USB do you still get Error 13 on install or DSM installs and actually works?

Yes it works for me, i use esxi-7.02 with Vcenter, it boots and reach prompt in serial, sysnology assistant show me new system, start installation of DS3615xs 7.0 pat file, but it ends with error 13 at almost 45% on webinterface 

Link to comment
Share on other sites

6 minutes ago, Aigor said:

Yes it works for me, i use esxi-7.02 with Vcenter, it boots and reach prompt in serial, sysnology assistant show me new system, start installation of DS3615xs 7.0 pat file, but it ends with error 13 at almost 45% on webinterface 

 

What does /var/log/messages show as failure for install?

Link to comment
Share on other sites

30 minutes ago, Aigor said:

Yes it works for me, i use esxi-7.02 with Vcenter, it boots and reach prompt in serial, sysnology assistant show me new system, start installation of DS3615xs 7.0 pat file, but it ends with error 13 at almost 45% on webinterface 

seems esxi requires dom support which is not yet implemented.

Link to comment
Share on other sites

1 hour ago, mcdull said:

did you see

/dev/synoboot 

/dev/synoboot1

/dev/synoboot2

??

No, i can't see any devices /dev/sy*


This is the part of messages about installation 

-[  225.868642] md0: detected capacity change from 2549940224 to 0
-[  225.870581] md: md0: set sda1 to auto_remap [0]
-[  225.872090] md: md0 stopped.
-[  225.873076] md: unbind<sda1>
-[  225.874056] md: export_rdev(sda1)
-[  225.902237] md1: detected capacity change from 2147418112 to 0
-[  225.904159] md: md1: set sda2 to auto_remap [0]
-[  225.905667] md: md1 stopped.
-[  225.906652] md: unbind<sda2>
-[  225.907636] md: export_rdev(sda2)
-[  228.993757] md: bind<sda1>
-[  229.000306] md/raid1:md0: active with 1 out of 15 mirrors
-[  229.002532] md0: detected capacity change from 0 to 2549940224
-[  232.017966] md: bind<sda2>
-[  232.022973] md/raid1:md1: active with 1 out of 15 mirrors
-[  232.025212] md1: detected capacity change from 0 to 2147418112
-[  232.034839]  md1: unknown partition table
-[  232.047692]  md0: unknown partition table
-[  232.388147] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.391664] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.405654] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  232.458003] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.461474] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.475526] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  232.489944] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.493417] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  232.506342] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  292.174537] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  292.177902] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  292.191563] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  301.538610] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  301.541326] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  301.554141] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  310.119761] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  310.123070] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  310.138215] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  319.572893] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  319.576197] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  319.589889] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  328.548025] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  328.551250] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  328.564702] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-[  337.546501] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  337.549819] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
-[  337.563643] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
-DiskStation> [  346.526666] EXT3-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
[  346.529928] EXT2-fs (md0): error: couldn't mount because of unsupported optional features (2c0)
[  346.543461] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)

1116291853_errore-installazione.png.fca8ca6e57695060527ac6102827d435.png

 

no error 13, file may be corrupted 

Link to comment
Share on other sites

1 hour ago, Aigor said:

I'm not full understood sata dom use.
My test boots flawless and recognize sata virtual hdd , but cant install DSM into sata disk.

 

Known problem, not fixed easily other than updating Redpill to support SATA DOM (small SATA based chip where DSM boots from in some actual Synology devices) which TTG is working on.

 

https://github.com/RedPill-TTG/redpill-load/issues/6

  • Like 2
Link to comment
Share on other sites

13 hours ago, mcdull said:

 

I have used the redpill toolchain v0.4 and force switch to the original repo instead of jumkey's one.

The full dmesg is attached.  nothing with boot_device_shim, and no rtc.

DSM7_918dmesg.txt 55.05 kB · 7 downloads

 

I have also tried apollolake + 6.2.4, the same.

In short, 3615 works fine, 918 do not.

 

p.s. the same proxmox is running a DS918 with jun's loader rock solid.

 

For comparison, I also attached the dmesg of 3615 DSM 6.2.4. The file is much larger as it is a full boot to the DSM.

DSM624_3615_dmesgout.txt 242.26 kB · 9 downloads

Your problem lies in https://github.com/RedPill-TTG/redpill-lkm/issues/10

You can see it here:

[    5.145864] <redpill/runtime_config.c:159> Runtime config populated
[    5.148435] <redpill/call_protected.c:81> Got addr ffffffff81928292 for early_serial_setup
[    5.149080] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[    5.149628] BUG: unable to handle kernel paging request at ffffffff81928292
[    5.150071] IP: [<ffffffff81928292>] early_serial_setup+0x0/0x150
[    5.150071] PGD 180d067 PUD 180e063 PMD 2768ad063 PTE 8000000001928163

 

We probably should enable crash-on-error as now if the module fails to load it lets the kernel continue to boot.

 

10 hours ago, gadreel said:

@mcdull I looked into Jun's loader console and both loaders they mention that "I am running an Intel Kernel on AMD"... but like your last post also my DS918+ has been running Rock Solid under Unraid for years now. Never crashed etc... I do not know if it will be a big issue in the new loader... I do not want to bother ThorGroup for clarification for the time being since the loader is still under development and not so relevant...

That's a lucky config :) For sure you're leaving performance on the table but if it was stable before it should be stable now (as in general they try not to break things in the newer kernels). A small advice from us is make sure you carefully configure security flags for mitigations  (spectre, meltdown, etc). We found this regarding unraid: https://forums.unraid.net/topic/80235-disabling-spectremeltdownzombieload-mitigations-plugin-available/

These may have a really big impact on performance and since the guest kernel cannot detect what CPU is it running on it might enable things for no reason.

 

9 hours ago, dodo-dk said:

Hi, with the GIT-changes from today, the builded IMG dosn´t work anymore. (DS3615xs_6.2.4-25556 on Proxmox 7 with same Settings as before).

Builded with Linux sources.

 

  Logs (Reveal hidden contents)


[    2.847386] pci 0001:0a:00.0: Can't map mv9235 registers
[    2.848386] ahci: probe of 0001:0a:00.0 failed with error -22
[    2.849370] <redpill/virtual_pci.c:488> Added device with new bus @ bus=0a dev=00 fn=00
[    2.850537] <redpill/pci_shim.c:209> vPCI device created successfully
[    2.851340] <redpill/pci_shim.c:212> PCI shim registered
[    2.852092] <redpill/sanitize_cmdline.c:156> !!BUG!! Failed to locate original cmdline
[    2.853271] <redpill/redpill_main.c:48> RedPill cannot be loaded, error=-2

 

 



[  197.148591] BUG: unable to handle kernel paging request at ffffffffa0000c10
[  197.148591] IP: [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591] PGD 1810067 PUD 1811063 PMD 1b6e5a067 PTE 0
[  197.148591] Oops: 0010 [#350] SMP 
[  197.148591] Modules linked in:
[  197.148591] CPU: 3 PID: 3687 Comm: init Tainted: GF     D    O 3.10.105 #25556
[  197.148591] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  197.148591] task: ffff8801b6d6e040 ti: ffff8801b7124000 task.ti: ffff8801b7124000
[  197.148591] RIP: 0010:[<ffffffffa0000c10>]  [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591] RSP: 0018:ffff8801b7127f50  EFLAGS: 00010202
[  197.148591] RAX: ffffffffa0000c10 RBX: 0000000000000000 RCX: 0000000000000000
[  197.148591] RDX: 0000000000f54010 RSI: 00007ffff94b7960 RDI: 00007ffff94b785a
[  197.148591] RBP: 0000000000000000 R08: 00007ffff94b786d R09: ff646b6e726d6e62
[  197.148591] R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
[  197.148591] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  197.148591] FS:  00007fb45ce2d700(0000) GS:ffff8801bfd80000(0000) knlGS:0000000000000000
[  197.148591] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  197.148591] CR2: ffffffffa0000c10 CR3: 00000001b1716000 CR4: 00000000000006e0
[  197.148591] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  197.148591] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  197.148591] Stack:
[  197.148591]  ffffffff814cfdc4 0000000000000000 0000000000000014 00007ffff94b785a
[  197.148591]  0000000000f54010 00007ffff94b7840 00007ffff94b7960 0000000000000206
[  197.148591]  0000000000000000 ff646b6e726d6e62 00007ffff94b786d 000000000000003b
[  197.148591] Call Trace:
[  197.148591]  [<ffffffff814cfdc4>] ? system_call_fastpath+0x22/0x27
[  197.148591]  [<ffffffff814cfd11>] ? system_call_after_swapgs+0xae/0x13f
[  197.148591] Code:  Bad RIP value.
[  197.148591] RIP  [<ffffffffa0000c10>] 0xffffffffa0000c0f
[  197.148591]  RSP <ffff8801b7127f50>
[  197.148591] CR2: ffffffffa0000c10
[  197.148591] ---[ end trace 3aa30e997e1a20db ]---

 

Edit: Works now with the new changes, Thanks.

 

Yup, we broke the code for ~2h before we realize what's wrong. In essence it was a race condition between userspace mounting /proc and us trying to lookup /proc/cmdline :D Now it's fully independent.

 

 

3 hours ago, jarugut said:

 

Hi Thorgroup, on the /var/log not exist any install log sorry, I've checke in the USB too but not exist this file.

 

 

image.thumb.png.603320a3e0090692612f7eb43bfe59ca.png

 

Do you have enough with the dmesg output? do you need that I will reinstalled from the scratch the qnap with the same USB to check if the install file will be created?

dmesg.out 123.76 kB · 3 downloads

That is unfortunately a partial dmesg but if we have to guess it's not detecting the USB stick properly. In order to grab the logs you have to log-in over serial port as all the logs are in memory and are erased after reboot. A Linux distro boot process is usually two staged: it first loads a pre-boot system into ram, does some housekeeping like mounting the main OS and loading drivers and then "overrides" the / with newly mounted disk and continues booting. In DSM that second step only happens when DSM is installed. The installer itself is running from ram so all its logs are in ram.

 

3 hours ago, ilovepancakes said:

This was the method I was talking about in earlier posts that doesn't work for me.... you are able to boot a physical USB this way? It definitely boots? When I choose the USB stick in plip the screen just freezes and it never boots. If you are able to boot the USB do you still get Error 13 on install or DSM installs and actually works?

VMWare products should be able to boot from a physical USB stick. Any other method will fail as they force any "usb" mounts to be presented as SATA/SCSI.

 

 

2 hours ago, Aigor said:

I'm not full understood sata dom use.
My test boots flawless and recognize sata virtual hdd , but cant install DSM into sata disk.

So, let us explain the SATA DOM stuff and booting. The kernel has so-called SCSI subsystem in drivers/scsi/sd.c - it is responsible for handling SCSI, SATA, and USB (as all are technically using the SCSI protocol under the hood). Syno modified the driver and added "disk types" which are logical types of disks informing the system whether something is an internal disk, USB stick, remote disk, disk in an external enclosure, iSCSI target, or a "synoboot" device. Every type except synoboot is easy to detect based on SCSI headers. The last one however depends heavily on the hardware it is running on.

 

Synoboot device can be:

  • A USB stick with the correct vendor-id/product-id combo
  • VirtIO SCSI device (vDSM only from what we see)
  • Any SCSI device which product name is "synoboot" (it's not a name you can modify)
  • A SATA device matching any one of these rules:
    • vendor-name="SATADOM" and model-name="TYPE D 3SE" (purley only)
    • vendor-name="SATADOM-" and model-name="TYPE D 3SE" (all except purley)
    • vendor-name="SATADOM" and model-name="3SE" (purley only)
    • vendor-name="SATADOM" and model-name="D150SH" (all other)

Commonly small SATA devices which are used for booting operating systems are referred as "SATA DOM" (SATA Disk-on-Module) and they look something like this:

supermicro_ssd_dm032_smcmvn1_32gb_sata_d

Since the SATA drive you normally use doesn't match any of the rules described above kernel assigns a type SYNO_DISK_SATA instead of SYNO_DISK_SYNOBOOT. The byproduct of that is the disk appears as /dev/sdc (or similar) rather than /dev/synoboot which causes the installer to freak out and throw Error 13 (which is a catch-all for "something unexpected happened").

 

We hope this clears this a bit. We have a draft of docs describing this (and slightly more) but it's still in a bit of a sorry state since we don't understand the whole disk system of syno kernel (e.g. how you can do >24 drives with eboxes? how does it work with them without resorting to unsupported /dev/sdaa scheme?).

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

25 minutes ago, ThorGroup said:

Synoboot device can be:

  • A USB stick with the correct vendor-id/product-id combo

 

For ESXi, since it can't virtualize USB sticks, what about a way in the loader to trick DSM into seeing the SATA virtual disk as a USB stick? It seems now DSM detects the SATA disk as a SATA disk based on those errors in messages log upon install, but it something was shimmed to make it appear as a USB with valid VID/PID maybe that would be a solution?

 

Also, while waiting for ESXi to work with Redpill I started experimenting with VirtualBox and I get Redpill (using Jumkey's latest branch for 7.0 (which does now take your updated virtio networking fix into account for VirtualBox) to boot and show a console but it doesn't seem to grab an IP, only shows "lo" network, no "eth0". Here is messages log, any ideas?

 

https://pastebin.com/EwWLuaMV

Link to comment
Share on other sites

1 hour ago, ilovepancakes said:

 

For ESXi, since it can't virtualize USB sticks, what about a way in the loader to trick DSM into seeing the SATA virtual disk as a USB stick? It seems now DSM detects the SATA disk as a SATA disk based on those errors in messages log upon install, but it something was shimmed to make it appear as a USB with valid VID/PID maybe that would be a solution?

 

Also, while waiting for ESXi to work with Redpill I started experimenting with VirtualBox and I get Redpill (using Jumkey's latest branch for 7.0 (which does now take your updated virtio networking fix into account for VirtualBox) to boot and show a console but it doesn't seem to grab an IP, only shows "lo" network, no "eth0". Here is messages log, any ideas?

 

https://pastebin.com/EwWLuaMV

We cannot really trick the kernel to see SATA as USB as they're checking if it's connected to a USB port. But we can make a SATA drive appear as the correct one ;)

Additionally SATA disks don't really have VID/PID, they have vendor name and product name in forms of strings - just a different approach to the media identification. That's why syno added a separate provisioning for SATA.

 

As for VBox you're probably missing https://github.com/RedPill-TTG/redpill-load/commit/5df3ace2191f6bad818b2f34e802163a96408d59 - yumkey branch doesn't have that commit. We're working on v7 but we found some problems (e.g. broken cmdline sanitization which may trigger autodestruction of the DSM after a random time).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...