flyride

That worked perfectly for me. Good call, I had forgotten about that as I don't normally use virtio platforms.

@leang521 I was able to compile and boot DVA3221 with r8169 instead of virtio for network. But without virtio the scsi data disk won't be accessible. So unless you want to rebuild for USB/sata0 data disk, we need to wait and see if there is another repo with virtio current platform updates, or the new platforms added to the pocopico fork of redpill-load/virtio.

Recovered by running fsck.ext4 against the volume1 device, and then manual mount of the volume. The SHR subarrays are in a degraded state with removed (not missing) members. The removed members are not aligned to a single faulty disk. All data should be offloaded, volumes and storage pools deleted, and then build a new SHR or RAID5.

They are the same device

I only see one error. It looks like the virtio extension doesn't have a tag for DVA3221. @pocopico is there a better repo to use or did it just not get added?

./rploader.sh restoresession apollolake-7.0.1-42218

Not sure what this means. Are you referring to the grub menu?

You executed that from TinyCore. The instructions were to launch the TCRP shell when DSM was at an install page, fwiw. No matter. Re-run ./rploader.sh update now and ./rploader.sh satamap now and post the output.

Just for my curiosity, what hardware configuration would you deploy with this? Because DS3622xs+ appears to be able to do anything this can.

launch the TCRP console at https://<your ip>:7681 login with root confirm your grub args with cat /proc/cmdline See what drives are connected where with ls -la /sys/block Post the outputs.

Strange. I'm using ProxMox VE 7.2 to create an equivalent test (on 3622xs+) but it's the same PCI ID, driver and probably the same virtio code. I can confirm using virtio-paravirtualized on the VM. admin@dsm7test3622prx:/$ lspci | fgrep 100 0000:06:03.0 Class 00ff: Device 1af4:1002 0000:06:05.0 Class 0100: Device 1af4:1004 0000:06:12.0 Class 0200: Device 1af4:1000 tc@box:~$ lspci -n | fgrep "1af4" 06:03.0 00ff: 1af4:1002 06:05.0 0100: 1af4:1004 06:12.0 0200: 1af4:1000 Seems happy enough. I get the same error from listmods as you do so maybe that's a red herring. Found SCSI Controller : pciid 1af4d00001004 Required Extension : No matching extension Found Ethernet Interface : pciid 1af4d00001000 Required Extension : No matching extension Can you configure the serial console?

@leang521 If data disk is SCSI, you need to manually edit DiskIdxMap=101000 after satamap and before loader build This is until the next update comes out from @pocopico I hope it works. If it doesn't, here's a summary of how I would try to configure your system. refresh new, clean TCRP image Configure virtio for network card bootloader image on sata0 and data disk on scsi0 OR bootloader image on USB image and data disk on sata0 ./rploader.sh update now ./rploader.sh fullupgrade now ./rploader.sh identifyusb now ./rploader.sh serialgen DVA3221 ./rploader.sh satamap now edit DiskIdxMap per above if data disk is scsi0, leave alone if data disk is sata0 ./rploader.sh ext denverton-7.1.0-42661 add https://raw.githubusercontent.com/pocopico/redpill-load/master/redpill-virtio/rpext-index.json ./rploader.sh build denverton-7.1.0-42661 auto USB image is a manual configuration to the VM conf file: Put loader.img in the path /var/lib/vz/images/<vmid> args: -device 'nec-usb-xhci,id=usb-bus0,multifunction=on' -drive 'file=/var/lib/vz/images/<vmid>/<img file name>,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' (and don't forget to configure boot to USB device)

I see problems. I don't know how or why you have two img files on both SATA0 and SATA1. There should only be one loader image file. Also, a data disk should not be on the same controller as a SATABOOT image. So if this is KVM, you will need to change the data disk to scsi0. Alternatively, you can convert your loader to USB image and then data disk on sata0. If you want more diagnosis post the actual output from ./rploader.sh satamap now

Did you add the virtio support extension before building the loader? ./rploader.sh ext apollolake-7.0.1-42218 add https://raw.githubusercontent.com/pocopico/redpill-load/master/redpill-virtio/rpext-index.json

I finally found this reference on your board. https://linux-hardware.org/?probe=7b71c09e85 It looks like there are two SATA controllers presented to the system. Given the way the ports are grouped, I would assume that 4 are attached to one, and 4 to the other. If you want to retry the satamap you can put in 4 and 4 and see what it does. Alternatively, the next update of the TCRP rploader script will have a query for the port count in it and suggest it to you instead of making you choose (or guess, in this case).

This looks like you are running KVM q35, plus SATABOOT image on sata0, and now data drives on scsi controller. This is different than your first post which was all sata. There is a problem for systems with SCSI data disks only that will be fixed with the next rploader script update. Functional settings for the above specific combination are SataPortMap="11" and DiskIdxMap="101000"

TCRP = TinyCore RedPill A very extensive TCRP/7.x installation tutorial geared more for end users is about to be posted, in work with @pocopico hopefully in the next day or so. Just so you know any 169.254 address means that the system thinks it can use the network, but cannot find a DHCP server, so it is assigning itself an address. If you cannot find a reason for this, maybe temporarily set your PC to IP 169.254.1.1 mask 255.255.0.0, or 169.254.63.1 mask 255.255.255.0 or 169.254.58.1 mask 255.255.255.0 and you may be able to reach it.

Pretty hard to give advice when you have no idea of the provenance of the loader being used to boot your system... That said I don't think anyone has yet reported success of upgrading to update 4 in a test mode. The update hasn't even been posted to https://xpenology.com/forum/forum/78-dsm-updates-reporting/ yet If it were my system I would build a TCRP loader with 7.0.1-42218 and see if it can recover.

That is a very old motherboard. It has embedded ATA controllers, these must be disabled in the BIOS. Also, the embedded SATA controller must support EDIT: AHCI (oops) mode and be configured that way. The motherboard must also be able to boot directly from USB. If these things can't be done, the motherboard is not a good candidate. If all that is configured, then post information about what loaders, DSM versions and platforms you are trying. DS918+, DS920+ and DVA3221 will not work with your CPU.

If it asks you twice, it is because it sees that you have two different SATA controllers. You should understand how your ports are connected to the controllers in order to answer. What motherboard are you using?

Moved my original answers along with your repost if it helps anyone else. They don't even have to stay in the same order as long as the array is healthy before migration. But always, ALWAYS have a backup of your data before you subject an array to a migration installation event. What limit would that be? Ethernet port speed? No limit, just have to get driver support. Out of the box there is a limit to the number of NICs you can use at one time, but that can easily be addressed. Sure, and quite preferable to a USB solution DSM is designed to manage SATA not NVMe, especially on 6.1.x. It doesn't want to use NVMe as storage, only cache. It can be hacked to work but it is not supported or simple. I would abandon that idea if I were in your shoes. You're already looking at a very ambitious project.

It will work as stated. It doesn't matter if it's for a real Synology or not. But it's manually hacking in an array which has members that are not supported by DSM. The poster creates only a Basic array. If DSM tries to manipulate that array in any way (such as repairing RAID etc) it will instantly fail. Maybe this won't ever happen as a Basic array (vs a multi-element array) but if it does, it will crash. There is a legitimately supportable way of doing this, which is to use a hypervisor and then map the NVMe disks to a SATA disks using virtualization features. Then DSM will see the storage as SATA and manage it as usual. But this also isn't very simple and if you aren't already using a hypervisor based solution, a whole lot more to learn. Thanks for posting this as a new topic. I hope you hear some other opinions from others who would otherwise not see it.

Can you post something more descriptive, or a screen shot?

Those errors are for hardware that is not in your system, no issues there. DS1621+ uses a Device Tree to identify disk ports, which is somewhat experimental. I think recently part of the code to generate the device tree was non-functional, although it may have been corrected in the last 24 hours or so. Regardless, DS3622xs+ is a better choice. There is no known advantage to using the AMD-specific build. For more information: https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/

Moderator action: moved thread out of the Developer forum tree.