updateing

I'm reporting back: after some trial and error this thing finally worked! The keys are: * there must be no dummy ata ports during initial installation. * a disk with loader's DSM version installed must be listed before any dummy ata port for post-installation operation. Here is what I did: 0. To begin with, I had 2 SATA controllers in my VM: the first one is a bogus q35 controller, the second one is the passthrough onboard SATA controller. The latter exposed 8 ports where first 4 were dummy. 1. I removed the passthrough controller (setting SataPortMap=10 caused a kernel panic so I had to take the trouble to remove it), and added a virtual SATA disk. 2. Last step made SATA controllers in VM appear as: q35 bogus + emulated ICH SATA controller. I set SataPortMap=14, DiskIdxMap=1000 and DSM installation went fine. 3. Added the passthrough onboard SATA controller back. 4. Controller in VM was q35 bogus + onboard + emulated. I set SataPortMap=181, DiskIdxMap=100100, and DSM could boot with all 4 physical disks populated. I tried SataPortMap=181 and DiskIdxMap=100008, DSM would go into "Migratable" state and fail with the infamous "We detected errors on your hard drive..." message. I'm planning to add "sata_remap" to fix port ordering, but at least it works now.

Wow that's really quick. Thanks for the tip! I'll try and report back in a day. I have to admit that I truly did not notice the presence of that thread, sorry But some minor suggestions might be useful: I've tried searching for "WARNING: Bad ports are mapped" and "Bad ports are mapped", nothing came up. Maybe we can extend the sentence to its whole in the thread, so that people can find them more easily? And the post is not referenced in the most exposed FAQ threads either (the DSM7 Loader and Platforms thread has more exposure there). Maybe we can add link to this thread to "Links to Loaders" thread?

I've got the following setup: CPU: Intel Core i7-12700 Mobo: ASRock H670M-ITX/ax RAM: 8GB DDR4-2400 *2 Storage: 3TB Toshiba HDD *1 (this is only a test drive) NIC: Mellanox ConnectX-2 10Gb (Ethernet) OS: Proxmox VE 7.4 A virtual machine with onboard SATA controller and 10G NIC VF passthrough has been setup to run TCRP and DSM. Software versions are listed as follows: Loader: TCRP 0.8.0.3 (setup as DS918+ with redpill-acpid extension) DSM: 7.1.0-42661 When executing `./rploader.sh satamap now` in TC, it showed: tc@box:~$ ./rploader.sh satamap now Machine is VIRTUAL Hypervisor=KVM Found "00:1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)" Detected 6 ports/0 drives. Mapping KVM q35 bogus controller after maxdisks Found "01:00.0 Intel Corporation Device 7ae2 (rev 11)" Detected 8 ports/1 drives. Bad ports: 1 2 3 4. Override # of ports or ENTER to accept <8> Computed settings: SataPortMap=18 DiskIdxMap=1000 WARNING: Bad ports are mapped. The DSM installation will fail! Should i update the user_config.json with these values ? [Yy/Nn] It suggests ports 1, 2, 3 and 4 on onboard SATA controller is bad. After some digging into the script I'm able to confirm that: tc@box:~$ sudo dmesg|grep ata [ 0.031244] Memory: 6093272K/6290892K available (10242K kernel code, 1227K rwdata, 1916K rodata, 1184K init, 3660K bss, 197364K reserved, 0K cma-reserved) [ 0.295897] libata version 3.00 loaded. [ 0.437601] ata1: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f100 irq 28 [ 0.437604] ata2: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f180 irq 28 [ 0.437606] ata3: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f200 irq 28 [ 0.437608] ata4: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f280 irq 28 [ 0.437611] ata5: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f300 irq 28 [ 0.437613] ata6: SATA max UDMA/133 abar m4096@0xfea1f000 port 0xfea1f380 irq 28 [ 0.497715] ata7: DUMMY [ 0.497716] ata8: DUMMY [ 0.497716] ata9: DUMMY [ 0.497716] ata10: DUMMY [ 0.497722] ata11: SATA max UDMA/133 abar m2048@0xfe803000 port 0xfe803300 irq 29 [ 0.497723] ata12: SATA max UDMA/133 abar m2048@0xfe803000 port 0xfe803380 irq 29 [ 0.497724] ata13: SATA max UDMA/133 abar m2048@0xfe803000 port 0xfe803400 irq 29 [ 0.497726] ata14: SATA max UDMA/133 abar m2048@0xfe803000 port 0xfe803480 irq 29 [ 0.498087] scsi host14: pata_legacy [ 0.498097] ata15: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14 [ 0.766974] ata5: SATA link down (SStatus 0 SControl 300) [ 0.767034] ata1: SATA link down (SStatus 0 SControl 300) [ 0.767125] ata4: SATA link down (SStatus 0 SControl 300) [ 0.767188] ata3: SATA link down (SStatus 0 SControl 300) [ 0.770401] ata6: SATA link down (SStatus 0 SControl 300) [ 0.773793] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 0.773933] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 [ 0.773934] ata2.00: applying bridge limits [ 0.774254] ata2.00: configured for UDMA/100 [ 0.809825] ata14: SATA link down (SStatus 0 SControl 300) [ 0.810038] ata12: SATA link down (SStatus 0 SControl 300) [ 0.810057] ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 0.810071] ata13: SATA link down (SStatus 0 SControl 300) [ 0.811840] ata11.00: ATA-8: TOSHIBA DT01ACA300, MX6OABB0, max UDMA/133 [ 0.811841] ata11.00: 5860533168 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 0.813863] ata11.00: configured for UDMA/133 [ 0.906407] scsi host14: pata_legacy [ 0.906443] ata16: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15 [ 1.110280] usbcore: registered new interface driver ums-datafab [ 1.132122] Write protecting the kernel read-only data: 14336k [ 1.132615] Freeing unused kernel image (text/rodata gap) memory: 2044K [ 1.132714] Freeing unused kernel image (rodata/data gap) memory: 132K ata7~ata14 is the onboard SATA controller. Only the latter 4 ports are actually implemented on the board. This can be also verified in Proxmox VE kernel messages: root@Hamster-PVE:~# dmesg|grep -i ata [ 0.000000] BIOS-e820: [mem 0x0000000065612000-0x00000000656dffff] ACPI data [ 0.012427] NODE_DATA(0) allocated [mem 0x48f7d6000-0x48f7fffff] [ 0.079435] Memory: 15984708K/16544452K available (16393K kernel code, 4342K rwdata, 10192K rodata, 2888K init, 4900K bss, 559484K reserved, 0K cma-reserved) [ 0.488570] libata version 3.00 loaded. [ 1.137309] Write protecting the kernel read-only data: 28672k [ 1.137958] Freeing unused kernel image (text/rodata gap) memory: 2036K [ 1.138203] Freeing unused kernel image (rodata/data gap) memory: 48K [ 1.206668] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 4 ports 6 Gbps 0xf0 impl SATA mode [ 1.247136] ata1: DUMMY [ 1.247137] ata2: DUMMY [ 1.247137] ata3: DUMMY [ 1.247138] ata4: DUMMY [ 1.247143] ata5: SATA max UDMA/133 abar m2048@0x70c22000 port 0x70c22300 irq 125 [ 1.247144] ata6: SATA max UDMA/133 abar m2048@0x70c22000 port 0x70c22380 irq 125 [ 1.247146] ata7: SATA max UDMA/133 abar m2048@0x70c22000 port 0x70c22400 irq 125 [ 1.247146] ata8: SATA max UDMA/133 abar m2048@0x70c22000 port 0x70c22480 irq 125 [ 1.559759] ata8: SATA link down (SStatus 0 SControl 300) [ 1.563563] ata6: SATA link down (SStatus 0 SControl 300) [ 1.563613] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 1.563959] ata7: SATA link down (SStatus 0 SControl 300) [ 1.564828] ata5.00: ATA-8: TOSHIBA DT01ACA300, MX6OABB0, max UDMA/133 [ 1.565066] ata5.00: ATA Identify Device Log not supported [ 1.565066] ata5.00: 5860533168 sectors, multi 16: LBA48 NCQ (depth 32), AA [ 1.566639] ata5.00: ATA Identify Device Log not supported [ 1.566640] ata5.00: configured for UDMA/133 [ 1.566706] scsi 4:0:0:0: Direct-Access ATA TOSHIBA DT01ACA3 ABB0 PQ: 0 ANSI: 5 I've tried using `SataPortMap=18 DiskIdxMap=1000` suggested by rploader.sh, but DSM installation just won't start saying "We've detected errors on your hard drives (1,2,3,4) and the SATA ports have also been disabled." Adding `DiskSeqReverse=08` or `sata_remap=0>7:7>0` does not affect the probing of first 4 ports, and DSM still refuses to install. I'm out of ideas here. Can anybody help? Thanks!

Thanks for the result! And the commands are so handy

This is a disk image of my pen drive (512MB SD card). Plz try if it works or not: https://drive.google.com/file/d/0Bwkmhb ... sp=sharing This file is created by: 1. Download Synoboot: https://github.com/Jman420/nanoBoot-DSM ... 3612xs.img 2. Write the file to pen drive. 3. Expand the partition and filesystem to ~100MB. Expansion of ext filesystem is way easier than FAT, and that is one of the reasons why I choose Synoboot. 4. Replace zImage with *ORIGINAL* XPEnology 5.6-5644.5 one. 5. Compress modified ramdisk (with synobios.ko hax) with gzip as rd.gz 6. Add initrd parameter in /boot/grub/grub.conf. 7. dd if=/dev/sdX of=img

So here is what I thought and did... From the discussion pages before, we can infer that the BIOS resetting has something to do with the time setting. And from my NanoBoot build tests we know that synobios.ko is the suspect. So I digged into this file. 0. Extract vmlinux from zImage from XPEnoboot, then extract ramdisk cpio in the vmlinux (why does XPEnology packs the ramdisk with vmlinux?) 1. Extract synobios.ko from ramdisk. Load the file in IDA, and search for time related functions in the function window. 2. There is an imported function named rtc_cmos_write, which fits our demand perfectly: time-related(RTC), operates with hardware(cmos_write) (Actually this is an exported function in common Linux kernel) So I decided to remove all calls to this function in order to block writing to the RTC. 3. List all the cross references to rtc_cmos_write. This is the common procedure for a call: We need to replace all these calls including argument passing procedure with NOP(0x90), which instructs the processor to do nothing when we reach here. 4. However, the file looks like this in WinHex: (IDA's Hex View is not showing original file) [updated 2016/03/10: Wrong mark on the WinHex side] This is due to the kernel modules are relocatable. The actual jumping address will be filled during runtime, and there is only a stub after the "call" instrcution. So we need to stop the "address filling". WARNING! Byte offset is different from the instruction offset shown in IDA. You can find the actual byte offset at the bottom left corner of IDA's Hex View. Byte offset should be used for "Navigation -> Goto Offset" in WinHex. 5. ELFs use relocation tables for this. Each item in the table tells the linker where we should fill and what to fill with. However I don't know where the table is placed, and all I can do is to search the address of the stubs. The following picture is search results of the first stub (at 0x0000000000003820, presented as 0x2038000000000000 in little-endian) This means the stub at 0x0000000000003820(2nd byte of "call rtc_cmos_write" in rtc_correct_wday) will be replaced with rtc_cmos_write's actual address at runtime. There are a bunch of these stubs which refers to rtc_cmos_write. Since the function rtc_correct_wday looks harmless, let's replace all references to other stubs to the one in this function, 0x0000000000003820. As those stubs won't get filled, we can continue using NOP to skip them. For example, there is "call rtc_cmos_write" in rtc_bandon_rotate_auto_poweron at 0x38c7 and the jumping target address stub begins at 0x38c8 (zeros omitted), then we search for 0xc838 and change it to 0x2038. Do the same for all other stubs in rtc_cmos_write calls. Be careful! Don't leave out any reference to the stubs. Note: all addresses mentioned in step 5 is IDA's instruction address. But since we are searching for hex values, we won't use Goto Offset menu so don't worry about the byte offset. 6. Now, relocation won't interfere with our changes about NOP'ping the "call" instrcutions. It's time to change all bytes shown in step 4 to 0x90. Remember, we are not NOP'ping the one in rtc_correct_wday. For example, we are removing the "call rtc_cmos_write" at 0x38c7 (0x3937 for byte offset, use Goto Offset menu). The disassembly looks like this: Change like this: (the argument calculating and passing procedure took a bit more (4) instructions...) Then the disassemnly should be like this: Do the same for all other calls to rtc_cmos_write. Note: if you don't know how to determine where the argument passing procedure starts, just ignore it and NOP the call instruction (0xE8 and 4 following bytes). It may work... 7. You are all set now. Put the modified file back into the cpio archive, copy to your boot disk, and let Grub load this archive as initrd to override the one inside zImage. If you encounter "No space left" error, you can try resizing the partition and filesystem.

I have been playing around DSM 5.2 for an hour and has rebooted several times. BIOS settings remain unchamged. I will try to schedule auto-boot and shutdown, and see if it resets the BIOS. If the schedule does not reset the BIOS, we can (almost) confirm the modified synobios.ko works... ADD: if I unplug all the USB devices, including the pen drive containing bootloader, the shutdown menu will work as expected. But how can I use DSM without the pen drive?

I have just got an Atom D525 machine and installed XPEnoboot 5.2-5644 on it. Everything else is working well but the BIOS resets every time DSM starts, and shutdown action in DSM will lead to a reboot after shutdown. NanoBoot x86 5.0.3.1 worked fine though, but the DSM of DS214play can't recognize all of my network adapters. After poking around the (outdated) NanoBoot source (5.0-4458, x86-64, DS3612xs), I found that the synobios.ko was the suspect: at first I didn't add required symbols into the kernel source, so synobios.ko couldn't load. And no BIOS resetting happened during this period. After the symbols being added and synobios.ko loaded, the resets began. So I switched back to XPEnoboot 5.2-5644, and spent all night studying the disassembly of the file in this version (why the initramfs is packed into zImage...) I nop'ped out some suspectful function call. Then things seems to be OK. Though it still reboots when I select shutdown in the menu, but BIOS settings remain unchanged. However, a power failure came after I finished a power cycle, so I can't determine whether the case is normal or just a coincidence. (I have done only one time of trial) I will test again when the electricity supply returns normal.