flyride
-
Posts
2,438 -
Joined
-
Last visited
-
Days Won
127
Posts posted by flyride
-
-
When you have a chance, please boot TinyCore and post the results of dmesg
I'd like to validate the nature of the port failure as posted by the kernel. It doesn't seem that there is a way to fix this with satamap aside from disabling ports (but we can use dtb/dts solution or virtualization as alternatives). But if the problem is presented consistently by TC kernel we can detect it and advise the user.
-
12 minutes ago, pocopico said:
I think that a dead port will still fail with sata_remap as it is visible to the DSM installer.
We can short a controller with dummy ports in the middle or end of the port range with SataPortMap, but not as the first ports. And unfortunately DiskSeqReverse is no longer in the kernel.
-
If we figure out a way to stimulate/simulate these port failures in virtual, that would be super helpful.
If the dummy ports are not the first ports on the controller, at least we can short the controller and make it work.
I think I should add a scan for DUMMY in satamap and advise the user to consider another platform/alternative.
But also think that there are other failure modes that may be harder to detect than "DUMMY"
-
1 minute ago, pocopico said:
I think you will have better luck with 1621+ cause there you can specify the pcie path and the port number also.
since its an AMD motherboard it will make sense also .
H570 is an Intel chipset.
@Deniska Virtualization is also a possibility for you.
-
1
-
-
I think they are not dummy, they are reserved for your M.2 in SATA mode.
-
1
-
-
Something is inconsistent with your system description and what satamap sees for ports. What motherboard make and model specifically?
What does ls -la /sys/block say from TinyCore?
If SataPortMap=1 there are no drives 2,3. So something else is happening.
-
Are you trying to install or upgrade to 42661-2? That results in a Recover loop at the moment.
-
Just following up on this, please review this post:
-
I have a conjecture about all the recent hard drive port errors, mostly encountered on X570, but now we have a current Intel motherboard example.
The errors all seem to be on dual-definable ports that can be either NVMe slots or SATA (via M.2 port). For whatever reason, DSM is choking on unpopulated M.2 SATA ports.
I realize that few people have M.2 SATA SSD's. But it would be very helpful to tabulate comparative results with a motherboard that exhibits the characteristics.
1) with nothing populated in M.2 slots
2) with all M.2 slots populated by NVMe drives
3) with all M.2 slots populated by M.2 SATA drives
4) with all M.2 slots completely disabled (if functionally configurable on the motherboard)
Without additional information, there may be no baremetal satamap based solution that will work. In that case, we will want to confirm functionality with a Device Tree-based model.
Of course, virtualization is and will continue to be a solution for these motherboards.
-
2
-
-
Post the output of satamap, and also ls -la /sys/block from TinyCore.
Fdisk -l and dmesg aren't bad ideas either
There is no need for driver extension for SATA controller as long as it is AHCI compliant.
-
If you change your SN it will just require a Migration. Not to worry.
-
Please keep in mind this FAQ entry when discussing Synology Accounts.
You should not be surprised if serial numbers are blacklisted or other methods are used to deny your XPEnology installation access to Synology server services.
-
16 minutes ago, asheenlevrai said:
I don't understand. Isn't the generated RP loader partition already on the USB flash drive?
This would create a backup copy on the same medium? Is that right?
Writing the post-build loader image created by TCRP to the loader partition is a one-way operation. Once DSM is installed or upgraded, the loader partition is altered.
./rploader.sh backuploader makes a copy of the post-build loader image to free space on the flash drive. The loader image can then be reverted if necessary.
./rploader.sh backup saves the configuration state (pre-build) so that it is intact as you left it when you next boot TinyCore.
./rploader.sh restoresession attempts to reconstruct the configuration state (pre-build) from the previous session if it was not saved with backup.
-
1
-
-
Some functions cannot be auto-detected.
If they are not part of the core RedPill code (ACPI is not) and have no PCI device associated with them for detection, this process handles them.
-
2 hours ago, Peter Suh said:
Can I continue to ask and answer questions about TCRP installation in this topic?
If there are no problems, I will participate.Of course you can.
-
31 minutes ago, neonflx said:
Ryzen 3900, AsRock X570, LSI 8 port plus 8 ports on board dual 10gb x540
using latest TCRP I can build and boot up but every time no hard drives are found
I have tried loading the mpt3sas extension before build as well as building it straight out also tried 3622 and 1621 but every time no hard drives are found
one thing I noticed is that when running satamap it only sees the board ports , which i have hd's connected to as wel
satamap won't show you information about SAS/SCSI because they are not SATA. So that behavior is expected.
@pocopico maybe I should add in the checkscsi again just to advise of connected scsi ports, even though it has nothing to do with satamap.
I think you have an issue with your HBA driver at the moment.
At least one X570 board recently encountered had a split SATA backplane and attached to two controllers, not one. Then those controllers were mapped high to low and low to high (ports vs. controller slots). I was working with the person with the issue to try and figure out a hack to make it work, but they went in a different direction. That was an ASUS board but it seems like a relevant data point.
-
2
-
-
-
The 30GB drive should be connected to a second sata controller (SATA1). If I believe what ./rploader satamap says it isn't connected to any controller at all (which would make sense to the outcome)
Can you check?
-
1
-
-
0.8 is intended as "stable release" - if you are installed now there is no benefit to rebuilding.
What is the configuration of your virtual drives and controllers on the VM that fails?
-
That is cosmetic only. Depiction of the actual device is a new feature of DSM 7.x
-
-
@Peter Suh no offense intended, but it seems like it is inappropriate to post this in pocopico's development thread as it is not contributing to development in any way.
-
If you passthrough the NIC, DSM must have a driver to support it. Again, no different than baremetal.
Alternatively, if ESXi has internal driver support for the card and DSM doesn't work with it, you can just provide the VM a vmxnet3 interface.
The point is that you have the choice.
-
19 minutes ago, docop1 said:
About the nic card , like the mellanox you quote, was it you pass it and it appear directly as an extra nic ? Like on ds918 we put 2 nic as per the system, then adding the pci nic will give a 3 nic in 'autodetect' mode .. Or it should be done manually or set the mac id somewhere.. ?
thanks and indeed good guide
It is no different than if you inserted a card into baremetal system. DS918+ has 2 NICs maximum as a platform default. So on that platform, to support more cards (or multi-port cards), add maxlanport to user_config.json and set it to match the NIC count. MAC id does not explicitly need to be set; its purpose is to 1) ensure uniqueness among DSM instances, and 2) enable Wake-On-LAN features if you want to use them.
TinyCore RedPill Loader (TCRP)
in Loaders
Posted
Something to read:
https://forums.servethehome.com/index.php?threads/pci-sata-controllers-and-dummy-unused-ports-on-linux.32649/
This reinforces the idea that if M.2 SATA SSD's were installed in those slots, everything will behave normally.
EDIT: This may also link back to hotplug. Modern BIOS that supports hotplug vs. non-hotplug support, and port not set to hotplug appears to result in DUMMY on that port if there is no disk attached - a known behavior. M.2 SATA ports might not be implemented with hotplug support in BIOS....