alienman

Hi @Aigor, I confirm that installing your SPK in the first post and changing after in the /var/packages/open-vm-tools/config/privilege file from "run-as": "package" to "run-as": "root" then it works! I hope you soon can share a new package with version 11.3.5. Regards.

Hi @tbc0309, I see that you have a fork of the synology-open-vm-tools package at https://github.com/tbc0309/synology-open-vm-tools . So I feel you're mainting it. Therefore, could you try my suggestion in the previous post, please? I need help from someone to update the SPK package with root admin for reliable shutdown. Regards.

Hi @Aigor, I finally found the solution to solve the problem of calling to the shutdown command with root privileges in DSM 7.x. However, I need your help. Then, could you please prepare a new package with this information? The workaround is based on the technique used by some community SPK packages that implement device drivers (for example, the RTL8156 USB Ethernet devices or the Aquantia AQC111U). In the repos of these packages they have implemented a simple tool called "spk_su.c". This tool only changes the corresponding "conf/privilege" file of the package to obtain the root privilege to execute some commands in the package. The tool is then included in the package, and it's required to call it manually after the first install of the package, because the installer checks the "privilege" file. However, after the first installation of the package, if you call with something like "sudo install -m 4755 -o root -D /var/packages/_my_package/target/bin/spk_su /opt/sbin/spk_su" then you can retry to install the package, and it will work. If you check the source code of the tool you will see that it only patches the "conf/privilege" file. You can read more about this here: https://github.com/bb-qq/r8152/issues/137 So, my request is to recompile your current version of the open-vmtools package changing these points: Restore the standard user in the package, that's "package" instead of any other. Add the "spk_su.c" file to the project and compile it. Edit the "postinst" script to call to the spk_su tool. All of the previous changes are resumed on this patch as example: https://github.com/bb-qq/aqc111/commit/f9c024c5b575d8b57aacdfec9bd40ef5e16ecb2a . So I feel you only need to do this: Edit the file "synology-open-vm-tools/spk/open-vm-tools/src/conf/privilege" and replace " "run-as": "root" " with " "run-as": "package" " in all lines. Edit the file "synology-open-vm-tools/spk/open-vm-tools/src/service-setup.sh" and modify the "service_postinst ()" function adding the code in the patch. I feel this will be sufficient to generate a valid SPK package compatible with DSM 7.x Please, try it! Regards.

Hi @Indio, The module is running. It's sufficient to see in the dmesg log of the DSM the lines "... smart_shim.c:818> Handling ioctl ...". So until here, all is right installed. Regarding your problem, I see that all seems OK with the HD. What's the problem now? Remember that I'm using VMWARE ESXi and not PROMOX. So I don't know how to enable VIRTUAL SSD in the qemu configuration. However, I feel it can be enabled. Search in the documentation about how to mark a virtual harddisk as SSD. Regards.

How you have installed it? You copied it (redpill.ko) to the /home/tc/custom-module/ directory ? What is the content of the dmesg log? Please share more info.

I use 3622xs+ that is broadwellnk. But others suggest to use 1621+. I don't know if you will obtain any advantage. Please test it and comment here.

Forget the /home/tc/redpill-load/cache/ directory and use the new /home/tc/custom-module/. Then you only need to copy it one time!

Hi @Dvalin21, With last versions of Tinycore-Redpill you can copy the pat file downloaded by you to the /home/tc/custom-module/. Futhermore it will be saved in your disk if you execute the "./rploader.sh backup now" command. Please don't use the other path (/home/tc/redpill-load/cache/) as this directory will be deleted/created with some commands. My recomendation is this: after the fist install of TCRP, at the end, copy the pat file from /home/tc/redpill-load/cache/ to /home/tc/custom-module/, and execute the backup. After that every time you execute a command (including the "./rploader.sh clean ...") the pat file will the stored locally. And you can use at every new command instead of download it. Regards.

Hi, I'm not sure about the best platform for AMD cpus. However, I've a working TCRP DS3622xs+ 7.0.1 in an ancient HP Microserver N54L with AMD CPU. Running without troubles, and inside a Virtual Machine (host is ESXi) too in the same computer. So, I feel you can run it in any AMD CPU.

Yes! But you need to use my patched redpill that fixes the SERIAL NUMBER of the shimed disks:

Hi, More interesting information related to Physical Disks with RDM on ESXi: - When connecting the disk over the PVSCSI controller (remember to use my patch for SMART UNIQUE SERIAL NUMBERS), I've finally obtained the real SMART data in the Virtual Machine. First I've executed the "smartctl" command inside the Tinycore Linux, and after inside the XPEnology. The results are interesting: when running inside the Tinycore the SMART values are obtained. But when using the XPEnology only if you use the correct interface. Here the smartcrl command "stock" (that is, using the "-d ata" parameter) inside the VM running redpill-TC (aka XPEnology): root@redpill:~# smartctl -a -d ata /dev/sdp smartctl 6.5 (build date Feb 20 2021) [x86_64-linux-4.4.180+] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: Virtual-HDD Serial Number: sdp Firmware Version: 1.13.2 Device is: Not in smartctl database [for details use: -P showall] ATA Version is: [No Information Found] Local Time is: Tue Mar 29 17:53:16 2022 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 69) seconds. Offline data collection capabilities: (0x18) No SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. No Selective Self-test supported. SMART capabilities: (0x0103) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. No General Purpose Logging support. Short self-test routine recommended polling time: ( 5) minutes. Extended self-test routine recommended polling time: ( 75) minutes. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002d 200 200 006 Pre-fail Offline - 0 2 Throughput_Performance 0x0004 128 117 064 Old_age Offline - 128 3 Spin_Up_Time 0x0027 177 176 006 Pre-fail Always - 4687 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 69 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 9 Power_On_Hours 0x0032 006 000 000 Old_age Always - 12973 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 42 13 Read_Soft_Error_Rate 0x002e 200 200 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0033 200 200 140 Pre-fail Always - 0 184 End-to-End_Error 0x0033 200 200 140 Pre-fail Always - 0 187 Reported_Uncorrect 0x003a 062 062 005 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 062 062 000 Old_age Always - 27 (Min/Max 27/30) 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 40 194 Temperature_Celsius 0x0022 118 098 000 Old_age Always - 29 195 Hardware_ECC_Recovered 0x0032 128 128 000 Old_age Always - 57 196 Reallocated_Event_Count 0x0032 128 128 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 128 128 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 254 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Selective Self-tests/Logging not supported As you can see here the fake SMART data is presented (as expected). But here the same command changing from "-d ata" (default) to "-d sat" protocol (remember this is inside the VM XPEnology): root@redpill:~# smartctl -a -d sat /dev/sdp smartctl 6.5 (build date Feb 20 2021) [x86_64-linux-4.4.180+] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD30EFRX-68EU*** Serial Number: WD-WCC4N2****** LU WWN Device Id: 5 0014ee 2b729a*** Firmware Version: 82.00A82 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Tue Mar 29 17:53:51 2022 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART Status command failed: scsi error unsupported field in scsi command SMART overall-health self-assessment test result: PASSED Warning: This result is based on an Attribute check. General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (39840) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 399) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 168 168 021 Pre-fail Always - 6583 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 352 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 060 059 000 Old_age Always - 29304 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 352 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 348 193 Load_Cycle_Count 0x0032 196 196 000 Old_age Always - 14975 194 Temperature_Celsius 0x0022 119 104 000 Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 20699 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. So as you can see now all the real SMART data is retreived. The conclusion is then: - We can drive physical RDM disks with SMART support with redpill DSM 7. - The only required implementation pending (after merging my SERIAL NUMBER patch) is to use for SCSI disks the same ioctl used by the smartmontools when using the "-d sat" protocol, instead of the default "-d ata" protocol. Using the last one the fake SMART data is provided. But if we could change the "sata_shim.c" hooks to use the alternative method then we'll enable full SMART support. Great news, right? Regards.

Hi, Using my previous patch for SMART UNIQUE SERIAL NUMBERS (see above) I discovered this: - When connecting SATA HDD disks over pRDM in ESXi to the VM running Redpill-TC, connected to the PVSCSI controller, now I can read the disk name and basic information (and not when connecting the disk over the SATA controller). Using the "smartctl -a /dev/sdp" command I can see all the physical disk information. And this is great. However, all the SMART data is fake. That's the output in kernel log when running the smartcrl command: [ 252.742300] <redpill/smart_shim.c:818> Handling ioctl(0x2285) for /dev/sdp [ 252.742443] <redpill/smart_shim.c:835> sd_ioctl(0x2285) - not a hooked ioctl, noop [ 252.744150] <redpill/smart_shim.c:818> Handling ioctl(0x31f) for /dev/sdp [ 252.744342] <redpill/smart_shim.c:647> Got SMART *command* - looking for feature=0xd0 [ 252.744560] <redpill/smart_shim.c:391> Generating fake SMART values So I can assume that the first ioctl is passed to the disk, but no the second one. Therefore if we can implement some workaround, then we'll have the option to drive physical disks running as Virtual Machine without needing to passthrough any controller. In fact, with the stock ESXi support will be sufficient to drive physical disks with SMART (and idle commands), virtual disks (as regular HDD vmdk), virtual cache (as SSD vmdk) and physical NVMe disks (for cache or volumes). I hope that soon you'll want to merge my patch and work on improving the ioctl 0x31f with RDMs. Regards.

So, then... Please @jumkey @yanjun or @buggy25200 could one of you review and merge this patch?

Hi @pocopico, Please could you merge this (now clean) patch for supporting any number of SCSI disks with redpill-lkm? diff --git a/shim/storage/smart_shim.c b/shim/storage/smart_shim.c index 6d94e68..0b7eaf4 100644 --- a/shim/storage/smart_shim.c +++ b/shim/storage/smart_shim.c @@ -269,11 +269,12 @@ static __always_inline void put_ioctl_buffer(unsigned char *buffer) } /*************************************** ATAPI/WIN command interface handling *****************************************/ -static int populate_ata_id(const u8 *req_header, void __user *buff_ptr) +static int populate_ata_id(const u8 *req_header, void __user *buff_ptr, const char* const disk_name) { pr_loc_dbg("Generating completely fake ATA IDENTITY"); unsigned char *kbuf; + char disk_serial[DISK_NAME_LEN]; kzalloc_or_exit_int(kbuf, HDIO_DRIVE_CMD_HDR_OFFSET + sizeof(struct rp_hd_driveid)); struct rp_hd_driveid *did = (void *)(kbuf + HDIO_DRIVE_CMD_HDR_OFFSET); //did=drive ID @@ -283,7 +284,8 @@ static int populate_ata_id(const u8 *req_header, void __user *buff_ptr) kbuf[HDIO_DRIVE_CMD_RET_SEC_CNT] = ATA_CMD_ID_ATA_SECTORS; did->config = 0x0000; //15th bit = ATA device, rest is reserved/obsolete - set_ata_string(did->serial_no, "VH1132", 20); + strscpy(disk_serial, disk_name, DISK_NAME_LEN > 20 ? 20 : DISK_NAME_LEN); + set_ata_string(did->serial_no, disk_serial, 20); set_ata_string(did->fw_rev, "1.13.2", 8); set_ata_string(did->model, "Virtual HDD", 40); did->reserved50 = (1 << 14); //"shall be set to one" @@ -323,14 +325,14 @@ static int populate_ata_id(const u8 *req_header, void __user *buff_ptr) * @return definitive exit code for the ioctl(); in practice 0 when succedded [regardless of the modifications made] or * the same error code as org_ioctl_exec_result passed */ -static int handle_ata_cmd_identify(int org_ioctl_exec_result, const u8 *req_header, void __user *buff_ptr) +static int handle_ata_cmd_identify(int org_ioctl_exec_result, const u8 *req_header, void __user *buff_ptr, const char* const disk_name) { //ATA IDENTIFY should not fail - it may mean a problem with a disk or the "disk" is a adapter (e.g. IDE>SATA) with // no disk connected, or if executed against a USB flash drive... or it's an VirtIO SCSI disk read as ATA if (unlikely(org_ioctl_exec_result != 0)) { pr_loc_dbg("sd_ioctl(HDIO_DRIVE_CMD ; ATA_CMD_ID_ATA) failed with error=%d, attempting to emulate something", org_ioctl_exec_result); - return populate_ata_id(req_header, buff_ptr); + return populate_ata_id(req_header, buff_ptr, disk_name); } //sanity check if requested ATA IDENTIFY sector count is really what we're planning to copy @@ -692,7 +694,7 @@ static int handle_hdio_drive_cmd_ioctl(struct block_device *bdev, fmode_t mode, // we need to modify it to indicate SMART support case ATA_CMD_ID_ATA: pr_loc_dbg_ioctl(cmd, "ATA_CMD_ID_ATA", bdev); - return handle_ata_cmd_identify(ioctl_out, req_header, buff_ptr); + return handle_ata_cmd_identify(ioctl_out, req_header, buff_ptr, bdev->bd_disk->disk_name); //this command asks directly for the SMART data of the drive and will fail on drives with no real SMART support case ATA_CMD_SMART: //if the drive supports SMART it will just return the data as-is, no need to proxy And why this patch? With the recent version of redpill-tinycore we can create and use virtual SSD disks for cache. However, when using them one trouble exists: With the current implementation of the "smart_shim.c" when the disk is connected with the pvscsi controller all the SMART data is FAKE, including the SERIAL NUMBER. And the DSM uses the SERIAL NUMBER to identify the disk. So when you add more than one disk, then the UI will show only one of these disks... because all share the same serial number. What does this patch is to use the device name (from the "/dev/block_device_path") as the serial for such disks. And with this simple technique you can add as many cache disks as you want. Regards.

Hi @pocopicoand others, As I've described here with the recent version of redpill-tinycore we can create and use virtual SSD disks for cache. However, when using them one trouble exists: With the current implementation of the "smart_shim.c" when the disk is connected with the pvscsi controller all the SMART data is FAKE, including the SERIAL NUMBER. And the DSM uses the SERIAL NUMBER to identify the disk. So when you add more than one disk, then the UI will show only one of these disks... because all share the same serial number. So I prepared a dirty patch that solves this problem: root@redpill-tool-chain:/opt/redpill-lkm/shim/storage# diff smart_shim.c smart_shim.c.bak 272c272 < static int populate_ata_id(const u8 *req_header, void __user *buff_ptr, const char* const disk_name) --- > static int populate_ata_id(const u8 *req_header, void __user *buff_ptr) 277d276 < char disk_serial[DISK_NAME_LEN]; 287,289c286 < //set_ata_string(did->serial_no, "VH1132", 20); < strscpy(disk_serial, disk_name, DISK_NAME_LEN > 20 ? 20 : DISK_NAME_LEN); < set_ata_string(did->serial_no, disk_serial, 20); --- > set_ata_string(did->serial_no, "VH1132", 20); 291c288 < set_ata_string(did->model, "Virtual-HDD", 40); --- > set_ata_string(did->model, "Virtual HDD", 40); 329c326 < static int handle_ata_cmd_identify(int org_ioctl_exec_result, const u8 *req_header, void __user *buff_ptr, const char* const disk_name) --- > static int handle_ata_cmd_identify(int org_ioctl_exec_result, const u8 *req_header, void __user *buff_ptr) 336c333 < return populate_ata_id(req_header, buff_ptr, disk_name); --- > return populate_ata_id(req_header, buff_ptr); 698c695 < return handle_ata_cmd_identify(ioctl_out, req_header, buff_ptr, bdev->bd_disk->disk_name); --- > return handle_ata_cmd_identify(ioctl_out, req_header, buff_ptr); 817c814 < //#ifdef DBG_SMART_PRINT_ALL_IOCTL --- > #ifdef DBG_SMART_PRINT_ALL_IOCTL 819c816 < //#endif --- > #endif 834c831 < //# ifdef DBG_SMART_PRINT_ALL_IOCTL --- > # ifdef DBG_SMART_PRINT_ALL_IOCTL 836c833 < //# endif --- > # endif 1083c1080 < } --- > } \ No newline at end of file What does this patch is to use the device name (from the "/dev/block_device_path") as the serial for such disks. And with this simple technique you can add as many cache disks as you want. I attached a compiled version of the redpill.ko module for the ds3622xs+ platform for convenience. But please @pocopicoadd to your "rploader.sh" script the option to use a user-compiled-custom-redpill.ko module. At time it's a pain to edit your script only to "inject" it! Regards. redpill.ko.tgz

Hi @giorgosperi, To create the Virtual Machine and install on it the redpill-tinycore I've used this basic guide: https://www.tsunati.com/blog/xpenology-7-0-1-on-esxi-7-x. With some tips from: https://xpenology.club/install-dsm-7-on-baremetal-or-vm/ And I've added some custom tweaks: - After download the (last) VMDK of the redpill-tinycore I upload it to my ESXi server, and before adding the disk to the VM I do a VMDK copy: "vmkfstools -i tinycore-redpill.v0.4.6.vmdk -d thin thin-tinycore-redpill.v0.4.6.vmdk". The reason is because the image is created using the qemu tools, and it could generate errors. So I prefer to create a new image from the source, and set the type that I want to use (in this case "thin"). - For the Hard Disk controllers in the VM I use: 1 SATA (0:0) for the redpill bootdrive; 1 SATA (1:0) for the HDD disks (configured as SATA); 1 pvscsi (0:0) for the SSD Cache disks; 1 NMVe only for testing as for nvme disks the SMART fails (lacks a redpill shim). In the future I'll try to passthrough real NVMe disks. - All HDD (vmdk or RDM) are connected to the second SATA controller. And all SSD (vmdk or RDM) are connected to the pvSCSI controller. Remember to edit the .VMX file to add the corresponding flag of force-SSD-type: scsi0:0.virtualSSD = "TRUE". - Also I've installed one open-vm-tools package: But for this we need to work on finishing the shutdown support. For the rest, it's more or less what you prefer to do. Perhaps a new guide "How to install DSM 7.0 in ESXi with HDD and CACHE" could be writed for this forum. Don't think so? Regards.

Hi @Aigor, I've tested the docker with vmtools, and it's a pain. I don't want to run Docker just for this. The main reason is the time to start Docker. And a second problem is the ssh method to execute the shutdown... this could fail at any time. So this solution isn't robust and is slow. Regarding how to compile the package, I've seen the README in the different repositories. However, I'll found it quite complex to a simple compile. Futhermore, I can't understand why the original author doesn't create a simple docker for this task. Futhermore, it's very annoying the manual editing of files. Why not create one script for the full task? Finally, after a much time thinking on a good solution, my efforts will go oriented to use a gold user (openvmtools) to run the package and trigger the shutdown. Then this user will have the privileges to execute the "/sbin/shutdown" command (that is what the source code of the open-vm-tools calls to). So, for this reason I ask if you can prepare an alternative SPK package with this user instead of the default "package" one. Then I'll work on adding support (perhaps with a redpill extension) for this user with sudo/wheel privileges to execute the shutdown binary without additional passwords. That's my objective. You want to help me?

Hi @Aigor, I'm interested on improve the "open-vm-tools" package. I've installed your package and the only problem is the shutdown. I'm searching for different solutions. In the meantime, could you please share how to compile your package? And can you change the user from [ "run-as": "package" ] to [ "run-as": "openvmtools" ] ? I'm studing if I could use a wheel user with privileges to shutdown without password. The idea is to inject this user from the redpill (as an extension) or create it manually in the DSM. You can help me, please?

Hi, Based on this post: I request to create a redpill-extension that adds the PCI addresses in the "/etc.defaults/extensionPorts" file, based on the results of the "udevadm info" tool. I've tested that we can add multiple "pci" lines like: [pci] pci1="0000:00:01.0" pci2="0000:01:02.0" pci3="0000:02:01.0" And then the system (DS3622xs+) will detect automatically the NVMe devices on these addresses. Regards.

Hi @giorgosperi, I don't want to be rude. I understood you mentioned that it can't be detected as a SSD. So if the problem is the target platform (DS315xs vs DS3622xs+), then we know now that it's preferable to use the second, as it could detect both types (HDD and SSD) as your preference for virtual disks. I apologize for the misunderstanding!

Perhaps a good starting point to compile the package "open-vm-tools" and insert it in the redpill as a module could be the Alpine package: https://git.alpinelinux.org/aports/tree/community/open-vm-tools Using the APKBUILD makefile it could be easy to compile it and build a a package with a lightweight version (without X11 and some other not useful submodules). Anyone interested on it?

Problem solved:

Hi, Anyone interested on create new module "open-vm-tools"? The idea is to generate something similar to the ACPI module, but including the "open-vm-tools" package.

Hi, Regarding the SHUTDOWN process using the Open-VM-Tools, I feel we need to explore some alternatives as the current implementation of the DSM 7.x doesn't allow packages with root permissions. However, nothing is lost. We only need to find a simple method to execute the shutdown process. First, let me to explain what does the Open-VM-Tools package: https://github.com/vmware/open-vm-tools/blob/19b6d0f9d9fb3092cb71df26eca60411c644af7f/open-vm-tools/lib/system/systemLinux.c#L325 Here is the souce of the open-vm-tools where the shutdown command is executed. If we found another alternative, it's wasy to modify this line and call to the desired command. So, first don't worry about what command is called. We can call to any command. The problem is how to execute the shutdown process from the package without root privileges. The alternatives that perhaps could work are: "synoshutdown" comand: This command from a plain user doesn't start the shutdown process. Call to a user shutdown command: From the scripts we can create a new script for starting a shutdown. And then call to it from the command line (I don't know how to do this). Wheel sudoers: We can add the spk package user to the sudoers file and enable to shutdown without password. But this implies to edit system config files as root. Change to root with "sudo -i": This works from the command line, but implies to type the password. Launch an ACPI power-off action: Anyone knows how to do this from the command line? Call to a hidden function in the redpill.ko: Perhaps another option could be to open a backdoor in the redpill module to receive a syscall without root privileges to start a shutdown/reboot process. I don't have more ideas. What you think?

Hi @pocopico 1. Yes, what I want to do it's use a redpill.ko compile by myself. Your current "compile" environment doesn't work right, and it doesn't permit to do modifications in the source and/or change the configuration. So I prefer to compile using the docker environment. However, please think the case when a user wants to test a new module that you don't provide. In this case it will useful to support (as example) "./rploader.sh build broadwellnk-7.0.1-42218 /home/tc/test/redpill.ko". In this case (when the parameter ends with "redpill.ko") you only need to overcome the download and copy from this path the module. Easy right? 2. I've downloaded too. But your script doesn't store the downloaded .pat file. Only if the user executes before calling to your script the command to create the directory ("mkdir -p /home/tc/redpill-load/cache") and copy the .pat file to it, then only in this case it will be used. That doesn't have much sense. Please, save the downloaded file in the cache and don't remove it. Or provide a documented method to provide it. 3. I know that the last selection in GRUB it's saved. And I accept that perhaps it's best to not change much what it's done by developers. I agree in this case with you. Please, note another issue: 4. When I want to "remake" and no new version of the redpill exists, then in this case the process fails because some extensions are duplicated. In my case I need to execute BEFORE some commands to clean: "rm -rf redpill-load/custom/extensions/pocopico.vmxnet3" and "rm -rf redpill-load/custom/extensions/thethorgroup.jg.boot-wait". I feel you can add to the script to remove all previously applied extensions. And one question: When using a Virtual Machine it's a pain to use the X-Window of the TinyCore (the mouse doesn't work nice). You know how to start it in TEXT MODE only and print in the welcome page the IP of the ethernet interface? Then it will be more easy to see the address and SSH to it. Regards.