flyride
-
Posts
2,438 -
Joined
-
Last visited
-
Days Won
127
Posts posted by flyride
-
-
6 hours ago, thisisthedangtime said:
It sounds like you're telling me that because my drives are listed as "Invalid slot number," that TCRP isn't able to intelligently map my drives. So I will have to manually map them. Can I use DSM 6 guides to make my satamap? At your request, here's my response to:
No, the invalid slot number error has no impact. The satamap that is generated is valid, but you choose not to save it to user_config.json.
-
On 6/28/2022 at 6:49 AM, flyride said:
Once DSM is installed, return to TinyCore and rebuild the loader identically, but change to SataPortMap=62. Boot back into DSM and verify everything is still working, then add your remaining disks back in. There will be a gap in the disk lineup because of your system's port mapping behavior. If you don't like that you can fix it with sata_remap but I advise just to leave it alone.
-
First, understand that satamap has nothing to do with your LSI. Satamap controls sata ports. Your LSI has SAS/SCSI ports. You do need a satamap to tell DSM how to map SATA ports from various controllers into a portspace that it can use.
4 minutes ago, thisisthedangtime said:I enter "./rploader.sh satamap now". It sees an SCSI Controller and downloads a module for it, presumably my LSI.
Then it sees SATA Controller one, where TCRP lives. Then it sees SATA Controller two, where a 25GB virtual disk is sitting (do I need this if the LSI works properly? I assume not).
ESXi virtual SATA controllers have the odd characteristic in that they support 30 ports. If configured as such, it would use up all the DSM ports such that your LSI controller would not be visible. So as long as you have a vSATA controller in the VM, TCRP attempts to override you with a "sane" value such as 8. Sata controller two is only needed if you want a virtual disk to be visible in DSM. If you are planning to use the storage from disks attached to your LSI HBA, it is not needed. If you remove the virtual disk and SATA controller 2 from your VM, it won't attempt to configure the satamap for it.
As a courtesy only, TCRP attempts to provide information about the LSI and the disks attached to it because if it doesn't, the user thinks something is wrong. Even though it has nothing to do with satamap. For some reason TCRP appears to find controllers in the PCI map that seem not to exist. If you can run this from the TinyCore command line that will help explain this further:
lspci -d ::100; lspci -d ::104; lspci -d ::107As an aside, you also seem to have a virtual SCSI controller configured in the VM that isn't attached to anything. The tutorial suggests for you to delete this. I'm not sure if that is part of the problem with the script output.
Finally, satamap configures to support the LSI ports to be tacked on to the end of the sata port mapping. Even through there were "errors" it did not affect the outcome.
Bottom line, it is configuring satamap correctly to support the vSATA controller and the LSI. If your controller is recognized by DSM (meaning, the driver works) then your LSI will expose its ports starting with slot #9
If you delete the vSATA controller and virtual disk, your LSI will expose its ports starting with slot #2.
You can always compute your own SataPortMap and DiskIdxMap values and edit them into user_config.json. TCRP attempts to do this for you but it doesn't work perfectly in every corner case as there are infinite combinations of hardware out there.
-
I'll refer you back to the link list from my previous post. A few items that illustrate the point:
- Compatible serialloader? There is no such thing. Serials correspond to DSM platform versions, which has little to do with your Xeon E3
- There are boot loaders that support both DSM 6 and DSM 7 that work with your Xeon. The Loaders and Platforms links will help you understand the relationships between boot loaders, DSM versions and DSM platforms
- "Happy Hacking" is all that you will ever see. Please review the FAQ and tutorial reference links for more information on this.
-
1
-
25 minutes ago, bonestaak said:
unfortunately those xpenologie solutions apparently only work on game motherboards
This is patently incorrect. You might want to review the information in the following links. There is more to XPenology than your carryover knowledge from real Synology.
https://xpenology.com/forum/forum/83-faq-start-here/
https://xpenology.com/forum/topic/61634-dsm-7x-loaders-and-platforms/
https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/
https://xpenology.com/forum/topic/7973-tutorial-installmigrate-dsm-52-to-61x-juns-loader/
-
1
-
-
Most people are posting here:
-
3 hours ago, thisisthedangtime said:
Don't run this as root.
-
A proper satamap permits access to all your ports and does not require changes to add and remove drives.
-
What @IG-88 said. It looks like you have three groups of bad ports, and I got you close but only accounted for two.
-
You are assumed to be running Jun's loader with DSM 6 based on where you posted this.
cd /dev
mkdir /mnt/synoboot1
sudo mount synoboot1 /mnt/synoboot1
cd /mnt/synoboot1
Then you can navigate to, and edit grub.cfg. No image recreation required.
-
RedPill will spoof SMART if necessary. For sure with virtual disks, and possibly with HBA drives. You can check the kernel log or comparatively analyze the SMART output to be certain.
To make things more complicated, Synology added Ironwolf support for some models, and then removed it from all models from 2022 on (i.e. DS3622xs+) as they are trying to steer customers into their branded drives.
-
1
-
-
The dmesg command should work from either TinyCore or from the junior mode of DSM. This is covered in the tutorial troubleshooting section.
You should be able to manually override user_config.json and install DSM, but in order to use all your disks, you will need to rebuild the loader afterward.
Initially, set SataPortMap=22 and DiskIdxMap=0006. You can install with only one disk if you want. Don't build any Storage Pools yet.
Once DSM is installed, return to TinyCore and rebuild the loader identically, but change to SataPortMap=62. Boot back into DSM and verify everything is still working, then add your remaining disks back in. There will be a gap in the disk lineup because of your system's port mapping behavior. If you don't like that you can fix it with sata_remap but I advise just to leave it alone.
-
A couple of things are happening here.
satamap is trying to advise you on ports that will cause problems during installation, but is not properly resolving the PCI bus addresses for the SATA controllers. This is interesting (and I haven't seen this before) so thanks for posting the PCI map so I can dig into that further.
The real issue is that DSM 7 is getting very finicky about allowing the installer to run when the visible SATA ports are not configured exactly as it wants.
Specifically, all ports need to be hot pluggable, or have a device attached to them. Additionally, many motherboards are mapping M.2 ports into the drive range that cannot be configured correctly (outside of populating the M.2 with SATA SSDs). Or, mapping non-functional ports into the range, which is the same problem.
If you can show whether you have these actual "bad" ports, the way to show this in the back end is dmesg | fgrep "DUMMY"
I suspect the way you can get past this is to set up a single disk in satamap, get DSM installed/upgraded, then rebuild the loader with another satamap that will provide access to the drives.
You can read more about the workaround options in the troubleshooting section in the tutorial here:
https://xpenology.com/forum/topic/62221-tutorial-installmigrate-to-dsm-7x-with-tinycore-redpill-tcrp-loader/EDIT: if you can post the result of ls -la /sys/block that would help with the PCI resolution problem.
-
Post a new support request in the DSM Installation forum, and include output from the installation scripts.
-
1
-
-
TinyCore is not an ISO, are you using the published loader?
Regardless, if you want to use Synoboot (boot loader from disk image) it must be attached to SATA controller.
Your 1TB data disk therefore must be connected to the SCSI controller in Proxmox. You have them backwards.
If you use emulated USB image instead of Synoboot, you can connect the data disk(s) as SATA.
-
1
-
-
-
https://xpenology.com/forum/topic/9394-installation-faq/?do=findComment&comment=81093
DSM7 support is constantly evolving. Bad port detection was added in the 0.8.0.3 update. Prior to that, the DSM install would fail with no explanation why.
-
11 minutes ago, updateing said:
I've tried using `SataPortMap=18 DiskIdxMap=1000` suggested by rploader.sh
It also specifically reported
WARNING: Bad ports are mapped. The DSM installation will fail!Disable your physical SATA controller and install using a virtual disk. Then once DSM is installed, restore the satamap to support the SATA controller. The DUMMY entries are only an issue for the initial installation.
Many options are explained in the tutorial here:
-
Make sure the date and time are set correctly otherwise https connections used to download the new content will fail.
-
You are using SATABOOT on Proxmox. You should not attach your data disks to the same controller. It plainly tells you this.
Move your data drives to the SCSI controller, or if you would rather keep using the SATA controller for your data disks, switch your loader to a USB image. After this is complete rerun satamap and build the loader again.
-
The LSI has to be recognized by DSM. You are posting results from Tinycore.
SataPortMap=1 and DiskIdxMap=00 is correct for baremetal and no AHCI SATA disks. Is the "no disks" error from DSM installation? Then you need to look at serial output in junior mode (when GUI is at installation) and see how the HBA disks are being addressed, if at all.
ls -la /sys/class/scsi_disk
-
Actually I don't see a reason why you can't use normally, there doesn't appear to be any damage.
Go ahead and reboot the NAS and make sure everything is still in place afterward.
-
mount -v /dev/vg1/volume_1 /volume1
-
pvs
vgchange -ay
pvdisplay
lvdisplay
DSM 7.1 in ESXi: Mapping LSI2008 Card
in DSM 7.x
Posted
Those are normal error messages and nothing to do with your LSI HBA.
But if you are getting no drives recognized from the LSI, the driver isn't loaded or isn't working. You're on the right track with manual add of extensions. You can see what DSM sees if you load the TCRP console in junior mode (at install screen). It will probably show you that mpt2sas/mpt3sas are not loaded. That's what needs fixing.
Again this doesn't really matter because satamap is unaffected by SCSI/SAS. You just need a basic satamap in place, which you finally did.