flyride Posted June 4, 2020 Share #26 Posted June 4, 2020 Ok, I think I understand now. Somehow your passthrough controller is being enumerated before the SATA controllers. This is not typical. SataPortMap=811 DiskIdxMap=000C08 Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #27 Posted June 4, 2020 Same problem: root@ismhomenas:/mnt/synoboot1/grub# cat grub.cfg | grep sata set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=000C08 SataPortMap=811 SasIdxMap=0' Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #28 Posted June 4, 2020 If you happen to be editing the hardware configuration of the VM, it may be reordering the PCI addresses of the devices from boot to boot. Let's regroup on this as I am losing track of the system state due to changes: Try: SataPortMap=1 DiskIdxMap=0C00 This is not technically correct but should work for most unknown configurations. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #29 Posted June 4, 2020 same problem: Looks like the positions of the drives have changed. root@ismhomenas:/mnt/synoboot1/grub# cat grub.cfg | grep sata set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C00 SataPortMap=1 SasIdxMap=0' Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #30 Posted June 4, 2020 (edited) Do me a favor, in ESXi, modify the SATA Controller 0 then save. Then modify the SATA Controller 1, then save. Finally remove and add the passthrough HBA. See if that changes anything. As long as you don't write anything to your array you won't have to resync when we get this sorted out. Edited June 4, 2020 by flyride Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #31 Posted June 4, 2020 I'm not sure what you mean by modify. The only thing I can do with it is remove it and re-add. I have to shut off the VM to do it though. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #32 Posted June 4, 2020 That's fine, just do them in order. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #33 Posted June 4, 2020 It's unchanged. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #34 Posted June 4, 2020 Seems like the position of the disks is wrong so it's masking the other ones attached. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #35 Posted June 4, 2020 Something else changed. Are there any other controllers (even with no drives attached to them) remaining in the VM? Let's try SataPortMap=444 and DiskIdxMap=00 This is a purely diagnostic/discovery test and the best case is that 4/5 drives on your HBA are visible, but it will tell us conclusively how these are getting mapped. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #36 Posted June 4, 2020 Under other devices there are a couple of IDE controllers. I don't have the ability to remove them however. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #37 Posted June 4, 2020 What hypervisor environment is this? Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #38 Posted June 4, 2020 New GRUB setting did not affect the disks. VMware ESXi, 6.7.0, 13981272 Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #39 Posted June 4, 2020 You cannot have all those controllers in the system. Is this vCenter we are looking at? I find it hard to believe you cannot remove the base controllers from the image. Was the VM built from the "Other 3.x Linux 64-bit" template as the tutorials state? From my web access to my ESXi host, I see this on my production VM: Controller 0 with loader, controller 1 with virtual drives (RDM's in my case), and a PCI passthrough HBA. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #40 Posted June 4, 2020 Yes it's vCenter 7. If I login to the host directly, I do not see those devices. However, I think the IDE controllers might be related to the floppy and CD drives. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #41 Posted June 4, 2020 Well let's remove HD2, SATA controller1, floppy and CD, they are all not necessary. Please do that from the web client. Boot back up and see where we are. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #42 Posted June 4, 2020 I also vaguely remember editing the synoinfo.conf files for esataportcfg when I was first setting this up. Could that be related? To answer your other questions, yes I've built this VM to whatever the guide was at the time. The only difference is that I've added more RAM and procs because I was running surveillance station and resilio sync on it. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #43 Posted June 4, 2020 You may upload that file if you like (please upload an actual file or use a spoiler to keep the post short). I don't think it's a factor here, but never say never... Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #44 Posted June 4, 2020 synoinfo.conf So I just a lspci -nn -q and it shows the first two sata controllers as lower numbers, but the lsi controller shows up as a sas controller. Would that make a difference in the grub config? 0000:02:01.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0] 0000:02:02.0 SATA controller [0106]: VMware SATA AHCI controller [15ad:07e0] 0000:03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3] 0000:0b:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] [1000:0072] (rev 03) Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #45 Posted June 4, 2020 (edited) So I removed the disk and controller and put the grub settings back to default: set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=1 SasIdxMap=0' and the two drives are showing back up, but they've fallen out of the array. I really don't care about the numbers or order at this point. Can we get the drives back in the array without doing a full resync? Edited June 4, 2020 by SirIanthe3rd Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #46 Posted June 4, 2020 If all the drives are present and it is not reporting healthy, then something wrote to the array while it was in degraded mode. In that case you ought to resync. If you want to continue with an upgrade plan, the controller/drive mapping needs to be understood. Nothing in your synoinfo.conf would cause the problem. Can you post the Disk Manager Overview now? You might feel like you've gone through a wringer, but your data was not at risk. And you have corrected two significant issues: vSCSI controller conversion to vSATA, and adding FixSynoBoot.sh, both of which are needed for a successful upgrade. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #47 Posted June 4, 2020 Nothing wrote to the array, but I think the OS probably marked it degraded because two drives were no longer present. We can continue, but at this point I'll have to go through another 36 hour resync unless you know of a way to workaround that. Quote Link to comment Share on other sites More sharing options...
flyride Posted June 4, 2020 Share #48 Posted June 4, 2020 It doesn't work that way, each drive has a write serial number. The write serials are no longer in sync across the whole array. If the array wouldn't start because of not enough members, it would be up and healthy now, but it managed to start degraded and something in DSM wrote to it. It's probably innocuous and could be forced, but it's your data and I would never recommend that unless the data was otherwise irrecoverable. Quote Link to comment Share on other sites More sharing options...
SirIanthe3rd Posted June 4, 2020 Author Share #49 Posted June 4, 2020 I'm rebuilding the array now. Hopefully will be done by tomorrow night. Quote Link to comment Share on other sites More sharing options...
kahn2k Posted September 11, 2020 Share #50 Posted September 11, 2020 Hi @Sirlanthe3rd, did you manage to get the array working? I have the very same issue as you when migrating from one VM to another. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.