Jump to content
XPEnology Community

RedPill - the new loader for 6.2.4 - Discussion

ThorGroup

By ThorGroup
in Developer Discussion Room

 Share

Recommended Posts

taiziccf Junior Member

taiziccf

Posted
Posted

I assume you familiar with proxmox and know how to change as necessary

  

args: -device nec-usb-xhci,id=usb-bus0,multifunction=on -drive file=/var/lib/vz/images/105/synoboot7.img,media=disk,format=raw,if=none,id=drive-disk-bootloader -device usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on -netdev type=tap,id=net0,ifname=tap105i0 -device e1000e,mac=46:2xxxxxx,netdev=net0,bus=pci.0,addr=0x12,id=net0
balloon: 0
bios: seabios
boot: order=ide2
cores: 4
efidisk0: local-lvm:vm-105-disk-1,size=4M
ide2: none,media=cdrom
machine: q35
memory: 4096
name: DSM7
numa: 0
onboot: 1
ostype: l26
sata0: local-lvm:vm-105-disk-0,backup=0,discard=on,replicate=0,size=20G,ssd=1
sata1: NVME:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=250G,ssd=1
sata2: filepool:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=10200G
serial0: socket
serial1: socket
serial2: socket
smbios1: uuid=xxx
sockets: 1
startup: order=2,up=5
vga: none
vmgenid: xxx

 

Link to comment
Share on other sites
yangyou Newbie

yangyou

Posted
Posted
1 hour ago, taiziccf said:

I assume you familiar with proxmox and know how to change as necessary

  


args: -device nec-usb-xhci,id=usb-bus0,multifunction=on -drive file=/var/lib/vz/images/105/synoboot7.img,media=disk,format=raw,if=none,id=drive-disk-bootloader -device usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on -netdev type=tap,id=net0,ifname=tap105i0 -device e1000e,mac=46:2xxxxxx,netdev=net0,bus=pci.0,addr=0x12,id=net0
balloon: 0
bios: seabios
boot: order=ide2
cores: 4
efidisk0: local-lvm:vm-105-disk-1,size=4M
ide2: none,media=cdrom
machine: q35
memory: 4096
name: DSM7
numa: 0
onboot: 1
ostype: l26
sata0: local-lvm:vm-105-disk-0,backup=0,discard=on,replicate=0,size=20G,ssd=1
sata1: NVME:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=250G,ssd=1
sata2: filepool:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=10200G
serial0: socket
serial1: socket
serial2: socket
smbios1: uuid=xxx
sockets: 1
startup: order=2,up=5
vga: none
vmgenid: xxx

 

Thank you very much!

Link to comment
Share on other sites
taiziccf Junior Member

taiziccf

Posted
Posted

i confirm, with latest build of loader, DSM7 918+ with proxmox can use virtio network

 

not required to set e1000e anymore 

args: -netdev type=tap,id=net0,ifname=tap105i0 -device e1000e,mac=46:2xxxxxx,netdev=net0,bus=pci.0,addr=0x12,id=net0

 

this should run much more stable and synology is now reporting correct network bandwitdh.

Link to comment
Share on other sites
Randell Newbie

Randell

Posted
Posted
13 minutes ago, taiziccf said:

i confirm, with latest build of loader, DSM7 918+ with proxmox can use virtio network

 

not required to set e1000e anymore 


args: -netdev type=tap,id=net0,ifname=tap105i0 -device e1000e,mac=46:2xxxxxx,netdev=net0,bus=pci.0,addr=0x12,id=net0

 

this should run much more stable and synology is now reporting correct network bandwitdh.

what vid pid you use?😂     "vid": "0x46f4" "pid": "0x0001" ???

Link to comment
Share on other sites
scoobdriver Advanced Member

scoobdriver

Posted
Posted

@haydibe Thanks for your work . 

the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ? 

  

root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown.
ERRO[0000] error waiting for container: context canceled

 

Link to comment
Share on other sites
djvas335 Advanced Member

djvas335

Posted
Posted

chmod +x entrypoint.sh then rebuild the docker image

 

2 hours ago, scoobdriver said:

@haydibe Thanks for your work . 

the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ? 

  


root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown.
ERRO[0000] error waiting for container: context canceled

 

 

  • Like 1
Link to comment
Share on other sites
Piteball Junior Member

Piteball

Posted
Posted
3 hours ago, scoobdriver said:

@haydibe Thanks for your work . 

the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ? 

  


root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown.
ERRO[0000] error waiting for container: context canceled

 

Is your active user added to the docker security group? (sudo usermod -aG docker $USER)

Link to comment
Share on other sites
mcdull Super Member

mcdull

Posted
Posted
3 hours ago, scoobdriver said:

@haydibe Thanks for your work . 

the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ? 

  


root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown.
ERRO[0000] error waiting for container: context canceled

 

try not use sudo, but use root direct.

Link to comment
Share on other sites
haydibe Guru

haydibe

Posted
Posted
3 hours ago, scoobdriver said:

@haydibe Thanks for your work . 

the 'build' part seems to work , however when I run auto , I receive the following error , would you have any advise ? 

  


root@ubuntu:/home/scoob/redpill-tool-chain_x86_64_v0.5.2# sudo ./redpill_tool_chain.sh auto bromolow-7.0-41222
docker: Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/entrypoint.sh": permission denied: unknown.
ERRO[0000] error waiting for container: context canceled

 

Thanks for spotting this - I missed that zips don't retain the file permissions. I should probably use tar in the future.  

Link to comment
Share on other sites
Aigor Guru

Aigor

Posted
Posted (edited)

Finally i'v get DSM3615xs7.0-4122 boot from esxi 7.0, but i'm not able to create storage pool image.thumb.png.e0d578e3bea04c68521b78e39e3e0cb2.png
 

 

as you can see  disk is 16 Gbyte SATA connected as disk 1 to SATA 0 
image.png.cc9a65f0dadba573336ac083bdf47dee.png

I suspect some whitelist for hdd or for smart data 

To convert image from redpill to vmdk i used starwind converter to convert img to vmdk 

Edited by Aigor
Link to comment
Share on other sites
scoobdriver Advanced Member

scoobdriver

Posted
Posted
13 minutes ago, Aigor said:

Finally i'v get DSM3615xs7.0-4122 boot from esxi 7.0, but i'm not able to create storage pool 

 

I resolved the issue I had with haydibes tool. created the VMDK , but still unable to boot to this to a point where it is detected on the network. (ESXi 6.7) 

 

Good to see how you have managed it .. 

Have you tried adding an extra sata controller and adding the data disk to 1:0 , boot disk to 0:0 (this was the recommended setup with Juns ) 

Link to comment
Share on other sites
Aigor Guru

Aigor

Posted
Posted
2 minutes ago, scoobdriver said:

 

I resolved the issue I had with haydibes tool. created the VMDK , but still unable to boot to this to a point where it is detected on the network. (ESXi 6.7) 

 

Good to see how you have managed it .. 

Have you tried adding an extra sata controller and adding the data disk to 1:0 , boot disk to 0:0 (this was the recommended setup with Juns ) 

I don't think is a sata ctrl problem, i suspect SMART data problem.
Storage manager MUST read smart data, but isn't available on VMdisk, but data are mandatory for system, so without smart data the disk is marked not usable 
This is only a my speculation, but i have errors on messages about smart no data 
  

2021-08-16T20:03:36+02:00 Test-dude synostgdisk[9925]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:36+02:00 Test-dude synostgdisk[9925]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:37+02:00 Test-dude synoiscsiep[10127]: iscsi_start_all.cpp:93:SYNOiSCSIStartAllWithoutLock Successfully started iSCSI service.
2021-08-16T20:03:37+02:00 Test-dude kernel: [   27.654355] workqueue: max_active 1024 requested for vhost_scsi is out of range, clamping between 1 and 512
2021-08-16T20:03:38+02:00 Test-dude synodisklatencyd[10272]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:38+02:00 Test-dude synodisklatencyd[10272]: disk/disk_temperature_get.c:104 read value /dev/sdb fail

---------------------------------------------------------------------

Internal disk info:
01:
02: /dev/sdb    (01000000000000000001)
03:
04:
05:
06:
07:
08:
09:
10:
11:
12:
13:
14:
15:
2021-08-16T20:03:39+02:00 Test-dude spacetool[10313]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude spacetool[10313]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostorage[10316]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostorage[10316]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10305]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10305]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10306]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10306]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.232694] synobios write r to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.375736] synobios write K to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.411345] synobios write 4 to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.424833] synobios write ; to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude root[10792]: == DSM 7.0 41222-0 finished boot up ==
2021-08-16T20:03:41+02:00 Test-dude kernel: [   31.634472] synobios write 3 to /dev/ttyS1 failed
2021-08-16T20:03:42+02:00 Test-dude updater[11394]: utils.cpp:461 (RunAvailableUpdaters) Run SUS available updates
2021-08-16T20:03:42+02:00 Test-dude updater[11394]: utils.cpp:480 (RunAvailableUpdaters) Run SUS mandatory updates
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:576 (UpdateLogLocation) fileindex update log location
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:580 (UpdateLogLocation) ignored volume: []
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:421 (PickLogDir) did not find available volume, use root partition
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:583 (UpdateLogLocation) picked new log dir [/var/log/@SynoFinder-log]
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:472 (MoveTo) link exists [/var/log/SynoFinder] -> [/var/log/@SynoFinder-log]
2021-08-16T20:04:30+02:00 Test-dude synostgd-disk[11680]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:04:30+02:00 Test-dude synostgd-disk[11680]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:05:30+02:00 Test-dude synostgd-disk[12215]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:05:30+02:00 Test-dude synostgd-disk[12215]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:06:30+02:00 Test-dude synostgd-disk[12702]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:06:30+02:00 Test-dude synostgd-disk[12702]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:07:30+02:00 Test-dude synostgd-disk[13243]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:07:30+02:00 Test-dude synostgd-disk[13243]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:08:30+02:00 Test-dude synostgd-disk[13925]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:08:30+02:00 Test-dude synostgd-disk[13925]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: update.cpp:169 Fail to read: /var/lib/data_update/syno-abuser-blocklist/version.json
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: update.cpp:171 syno-abuser-blocklist version file gone or corrupted or in the first updating
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: updater.cpp:118 syno-abuser-blocklist not been updated yet. Need Fix
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: updater.cpp:132 Try to fix database syno-abuser-blocklist
2021-08-16T20:09:30+02:00 Test-dude synostgd-disk[14420]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:09:30+02:00 Test-dude synostgd-disk[14420]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:10:30+02:00 Test-dude synostgd-disk[14710]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:10:30+02:00 Test-dude synostgd-disk[14710]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:11:30+02:00 Test-dude synostgd-disk[14970]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:11:30+02:00 Test-dude synostgd-disk[14970]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:12:30+02:00 Test-dude synostgd-disk[15263]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:12:30+02:00 Test-dude synostgd-disk[15263]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:13:30+02:00 Test-dude synostgd-disk[15532]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:13:30+02:00 Test-dude synostgd-disk[15532]: disk/disk_temperature_get.c:104 read value /dev/sdb fail


 

Link to comment
Share on other sites
ilovepancakes Advanced Member

ilovepancakes

Posted
Posted
10 minutes ago, Aigor said:

Storage manager MUST read smart data

 

From everything I have seen, this isn't the case. On Jun's loader, virtual disks don't show SMART data of course and the logs still complain about that, but the disk is still marked "Healthy" which makes it usable in a storage pool. I'm assuming Jun did something with the loader to get virtual disks to mark that way. That is, DSM determines if a disk can be used or not by the health status. It certainly is possible that the health status is determined by SMART data being present and readable, BUT if you find a way to override the health status flag and force it to "Healthy", the disk will be usable in Storage Manager even though SMART data is not present and DSM still says it can't be accessed.

 

On Jun's loader, notice how even though the disk is marked "Healthy" when you click "Health Info" for that disk, it doesn't load any SMART data, even fake SMART data or something. It says "access error". Also certainly possible they completely changed how that works in DSM 7, but the way to test is to spin up 6.2.4 with Redpill and see if the same issue happens on ESXi. If it does, then we know the loader is what is missing something to correctly trick DSM into using the virtual disks. I opened an issue on Redpill-LKM github repo for @ThorGroup to evaluate further.

Link to comment
Share on other sites
flyride Guru Master

flyride

Posted
Posted (edited)
2 hours ago, Aigor said:

I don't think is a sata ctrl problem, i suspect SMART data problem.
Storage manager MUST read smart data, but isn't available on VMdisk, but data are mandatory for system, so without smart data the disk is marked not usable 
This is only a my speculation, but i have errors on messages about smart no data 

 

Unless SMART requirements suddenly changed with DSM 7 this is a red herring.  DSM will always attempt to pull SMART data, but the only things that I have seen that actually rely on it are Cache health and RAIDF1.  The log errors you show have been there all along.

 

Syno does customize the SMART code, and hardcodes for SCSI queries even though the underlying drives are usually SATA.  This causes issues with certain controllers that have been manifested in various ways through the different DSM versions. 

 

Some additional info here:

https://xpenology.com/forum/topic/12391-nvme-optimization-baremetal-to-esxi-report/?tab=comments#comment-88690

https://xpenology.com/forum/topic/29581-suppress-virtual-disk-smart-errors-from-varlogmessages/

 

Also:

  1. Check your device for appropriate Syno disk tagging using udevadm. If it is a usable disk it should return SYNO_DEV_DISKPORTTYPE=SATA
    # udevadm info /dev/sdx
  2. Is 16GB large enough to create a Storage Pool on DSM7?
Edited by flyride
  • Like 2
Link to comment
Share on other sites
ThorGroup Junior Member

ThorGroup

Posted
  • Author
Posted

We're currently trying to tackle couple of problems at once ;)

 

So in summary we have:

  • GRUB last choice not saving on ESXi -> this can be caused by VMDK, if so it will show "error: failure writing sector 0x20ba to 'hd0'" or similar after attempting to boot (and the boot continues)
  • unable to create pools on v7 -> this isn't about SMART from what we know so far but about a bespoke hddmon service, investigation in progress. Disks without SMART should work. At present we don't have a machine at hand where we can pass a whole disk controller to the VM (which will give us SMART) and test if this fixes pools creation. Is anyone with Proxmox and a controller which can be passed via PCI pass can test that?
  • Info => General tab not loading on bromolow v7: we have no idea why as of now, but this is a symptom of something bigger, possibly the lack of PMU emulation
  • "error 13" on v7 with 918+ -> we may have stepped into the same annoying hotplug bug as with 3617xs, so the USB (or in fact ANY other hot-pluggable device) is not detected
  • reinit not working on v7 for 918+ -> this is caused by memory free, for now we disabled it in the platform as it shouldn't prevent booting and working (see https://github.com/RedPill-TTG/redpill-lkm/issues/10)
  • merging docker into RP Load -> we ran out of hands at this moment :D

=============

On 8/15/2021 at 4:00 AM, loomes said:

Thats only a thing im using for myself. After a commit in the past, i mean it was https://github.com/RedPill-TTG/redpill-lkm/commit/76c36a43483562c3438dd491a58208bc92e04416 (but im not sure) the detection dont work anymore in my proxmox machine so i changed the file.

We've fixed that by detecting DMI differently. In short we first naively grepped dmesg but if it's too long it will wrap on Linux v4 (syno decreased the buffer); now we use /sys so the detection should be robust. We didn't commit that to the master yet as we don't want to break @jumkey PR for v7 as we did some cleanup of symlink hell along the way. We cannot merge the 918+ v7 because it has a broken USB for us... the circle of doom.

 

On 8/15/2021 at 4:09 AM, ilovepancakes said:

 

Nicely done!! I built a fresh lkm and loader and can successfully install DSM 7 on ESXi now! A couple of things I noticed from a first run...

 

1.) The Grub boot menu doesn't seem to remember the "SATA" boot option as the last chosen option. When I reboot the VM, it defaults back to USB.

 

2.) Within DSM, if I go to Info Center under Control Panel, the "General" tab doesn't load, it just is white and shows no info about DSM.

 

3.) The only way I got the install to work was to have the loader VMDK and the data VMDK on the same SATA controller. If loader is on a SCSI controller for the VM, it boots but gets error 13 again. If I move loader to SATA controller along with a data VMDK, it installs, BUT I cannot create a storage pool/volume in DSM. Storage Manager shows the Vmware SATA drive but DSM says it cannot detect the drives status as "Healthy" so it won't let that drive be used to create a volume. I know SMART doesn't work with Xpenology and ESXi, but in Jun's loader the virtual drives at least showed "Healthy" which meant DSM could use them.

1) Do you get something like "error: failure writing sector 0x20ba to 'hd0" in grub when you pick the boot option (followed by "Loading Linux..." and "Loading initramfs...")? Because if it doesn't remember it means it's unable to save the grub environment to a disk. In such case your VMDK may be read only.

2) Yes, we saw that too - cause sadly unknown for now

3) This seems to be related to the hddmon problem and SMART discussion above

 

On 8/15/2021 at 6:28 PM, pocopico said:

@ThorGroupShould/Could we target at a higher disk count system and better hardware specs such as DS3617xsII or DS1621xs+ ?

Currently we are trying to support:

  • 3615xs v6 USB
  • 3615xs v6 SATA
  • 3615xs v7 USB
  • 3615xs v7 SATA
  • 918+ v6
  • 918+ v7

Multiply 6 of these by the number of hypervisors (VMWare, Proxmox, VirtualBox, unRAID): that's easily 24 permutations to test every time we make any change. Targeting another system isn't as simple as just adding a new image and compiling the module. To support a new platform we need:

  • PCI tree
  • Platform specific bugs like:
    • USB issue on 3617xs and now 918+ on v7
    • Flipped UARTs on 3615
    • Disabled ttyS0 on 918+
    • hdd health check on v7
  • S/Ns (we didn't have a chance to even look how they're generated in the current solution; we rely on the same publicly available tool developer by the community long time ago)

So in short, yes, we want to target something more advanced (most likely RS and not DS) but we want to get to the point where we can say "yup, it's stable and feature-complete on 3615 and 918". Currently the todo for considering it in such a state are solving the bugs above +:

  • GPIO shim for v4
  • PMU emulation
  • hddmon
  • USB/hotplug bug

These are absolutely necessary. Most likely on the way we must change to load the module as I/O scheduler instead of utilizing init script.

 

 

On 8/15/2021 at 10:43 PM, flyride said:

Just out of curiosity, why the continued development on 3615xs versus Broadwell?  The advantage of 3617xs is that 16 threads are accessible instead of 8.

In short: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/mysteries.md#usb-hot-plug-is-not-functional-some-models

 

 

On 8/16/2021 at 2:49 AM, mcdull said:

May I clarify under what config apollolake-7.0 will work?

Only in barematel? Qemu over proxmox won't work?

It should work under Proxmox/QEmu/ESXi. There's a jumkey branch which we're trying to merge but it's refusing to work for us.

 

 

12 hours ago, loomes said:

Disable reinit tty in platforms.h 

We temporarily applied it to the master as well https://github.com/RedPill-TTG/redpill-lkm/commit/afe20e47011d260921ca1cd2202a4df0210628df

 

 

9 hours ago, Aigor said:

Do the last sata_dom implementation boot from network?

What do you use to boot from network? In general DSM expects to be booted from USB or a real SATA.

 

 

3 hours ago, Aigor said:

I don't think is a sata ctrl problem, i suspect SMART data problem.
Storage manager MUST read smart data, but isn't available on VMdisk, but data are mandatory for system, so without smart data the disk is marked not usable 
This is only a my speculation, but i have errors on messages about smart no data 
  


2021-08-16T20:03:36+02:00 Test-dude synostgdisk[9925]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:36+02:00 Test-dude synostgdisk[9925]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:37+02:00 Test-dude synoiscsiep[10127]: iscsi_start_all.cpp:93:SYNOiSCSIStartAllWithoutLock Successfully started iSCSI service.
2021-08-16T20:03:37+02:00 Test-dude kernel: [   27.654355] workqueue: max_active 1024 requested for vhost_scsi is out of range, clamping between 1 and 512
2021-08-16T20:03:38+02:00 Test-dude synodisklatencyd[10272]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:38+02:00 Test-dude synodisklatencyd[10272]: disk/disk_temperature_get.c:104 read value /dev/sdb fail

---------------------------------------------------------------------

Internal disk info:
01:
02: /dev/sdb    (01000000000000000001)
03:
04:
05:
06:
07:
08:
09:
10:
11:
12:
13:
14:
15:
2021-08-16T20:03:39+02:00 Test-dude spacetool[10313]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude spacetool[10313]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostorage[10316]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostorage[10316]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10305]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10305]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10306]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude synostgdisk[10306]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.232694] synobios write r to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.375736] synobios write K to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.411345] synobios write 4 to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude kernel: [   29.424833] synobios write ; to /dev/ttyS1 failed
2021-08-16T20:03:39+02:00 Test-dude root[10792]: == DSM 7.0 41222-0 finished boot up ==
2021-08-16T20:03:41+02:00 Test-dude kernel: [   31.634472] synobios write 3 to /dev/ttyS1 failed
2021-08-16T20:03:42+02:00 Test-dude updater[11394]: utils.cpp:461 (RunAvailableUpdaters) Run SUS available updates
2021-08-16T20:03:42+02:00 Test-dude updater[11394]: utils.cpp:480 (RunAvailableUpdaters) Run SUS mandatory updates
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:576 (UpdateLogLocation) fileindex update log location
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:580 (UpdateLogLocation) ignored volume: []
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:421 (PickLogDir) did not find available volume, use root partition
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:583 (UpdateLogLocation) picked new log dir [/var/log/@SynoFinder-log]
2021-08-16T20:03:42+02:00 Test-dude fileindeX[11400]: fileindex.cpp:472 (MoveTo) link exists [/var/log/SynoFinder] -> [/var/log/@SynoFinder-log]
2021-08-16T20:04:30+02:00 Test-dude synostgd-disk[11680]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:04:30+02:00 Test-dude synostgd-disk[11680]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:05:30+02:00 Test-dude synostgd-disk[12215]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:05:30+02:00 Test-dude synostgd-disk[12215]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:06:30+02:00 Test-dude synostgd-disk[12702]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:06:30+02:00 Test-dude synostgd-disk[12702]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:07:30+02:00 Test-dude synostgd-disk[13243]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:07:30+02:00 Test-dude synostgd-disk[13243]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:08:30+02:00 Test-dude synostgd-disk[13925]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:08:30+02:00 Test-dude synostgd-disk[13925]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: update.cpp:169 Fail to read: /var/lib/data_update/syno-abuser-blocklist/version.json
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: update.cpp:171 syno-abuser-blocklist version file gone or corrupted or in the first updating
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: updater.cpp:118 syno-abuser-blocklist not been updated yet. Need Fix
2021-08-16T20:08:34+02:00 Test-dude synodbudd[10260]: updater.cpp:132 Try to fix database syno-abuser-blocklist
2021-08-16T20:09:30+02:00 Test-dude synostgd-disk[14420]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:09:30+02:00 Test-dude synostgd-disk[14420]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:10:30+02:00 Test-dude synostgd-disk[14710]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:10:30+02:00 Test-dude synostgd-disk[14710]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:11:30+02:00 Test-dude synostgd-disk[14970]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:11:30+02:00 Test-dude synostgd-disk[14970]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:12:30+02:00 Test-dude synostgd-disk[15263]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:12:30+02:00 Test-dude synostgd-disk[15263]: disk/disk_temperature_get.c:104 read value /dev/sdb fail
2021-08-16T20:13:30+02:00 Test-dude synostgd-disk[15532]: SmartDataRead(108) read value /dev/sdb fail
2021-08-16T20:13:30+02:00 Test-dude synostgd-disk[15532]: disk/disk_temperature_get.c:104 read value /dev/sdb fail


 

SMART doesn't seem to be a problem here. These errors aren't really that important. Additionally newer QEMU implements partial SMART and even then the array is not created. We think it has to do with hddmon kernel module which crashes during load.

 

  • Like 3
  • Thanks 2
Link to comment
Share on other sites
Comic Chang Newbie

Comic Chang

Posted
Posted
17 hours ago, taiziccf said:

I assume you familiar with proxmox and know how to change as necessary

  


args: -device nec-usb-xhci,id=usb-bus0,multifunction=on -drive file=/var/lib/vz/images/105/synoboot7.img,media=disk,format=raw,if=none,id=drive-disk-bootloader -device usb-storage,bus=usb-bus0.0,port=1,drive=drive-disk-bootloader,id=usb-disk-bootloader,bootindex=999,removable=on -netdev type=tap,id=net0,ifname=tap105i0 -device e1000e,mac=46:2xxxxxx,netdev=net0,bus=pci.0,addr=0x12,id=net0
balloon: 0
bios: seabios
boot: order=ide2
cores: 4
efidisk0: local-lvm:vm-105-disk-1,size=4M
ide2: none,media=cdrom
machine: q35
memory: 4096
name: DSM7
numa: 0
onboot: 1
ostype: l26
sata0: local-lvm:vm-105-disk-0,backup=0,discard=on,replicate=0,size=20G,ssd=1
sata1: NVME:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=250G,ssd=1
sata2: filepool:vm-100-disk-0,backup=0,cache=none,discard=on,replicate=0,size=10200G
serial0: socket
serial1: socket
serial2: socket
smbios1: uuid=xxx
sockets: 1
startup: order=2,up=5
vga: none
vmgenid: xxx

 

 

try virtio-scsi and virtio-net for better performance

  

args: -device 'qemu-xhci,addr=0x18' -drive 'id=synoboot,file=/var/lib/vz/images/redpill-DS3615xs_7.0-41222_b1629030772.imgif=none,format=raw' -device 'usb-storage,id=synoboot,drive=synoboot,bootindex=5'
balloon: 0
boot: cdn
bootdisk: sata0
cores: 6
cpu: host
hookscript: local:snippets/exec-cmds
machine: q35
memory: 16384
name: DS3615xs
net0: virtio=00:11:32:xx:xx:xx,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsi0: lvm-gen8:vm-210-disk-1,discard=on,size=256G,serial=data,ssd=1
scsihw: virtio-scsi-pci
serial0: socket
serial1: socket
serial2: socket
sockets: 1
tablet: 0
vga: serial0

 

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...