I’ve been working through issues relating to using the internal USB-A port or an SSD as a boot drive. I’m running into issues that would allow me to put the right panel back on without using a USB Thumb Drive in the internal USB-A port as the boot device.
HW Setup:
ArgonEON
Rpi4B 8GB
SanDisk Extreme PRO 256GB: Boot device (Internal USB-A port in the EON)
2x Toshiba MG08ACA16TE 16TB 7200RPM 512e 3.5" SATA: OMV Share Drives (2 center 3.5" SATA interfaces in the EON)
1x Samsung 870EVO 2.5 1TB SSD: Docker Data Store (left 2.5" SATA interface in the EON)
SW Setup:
RpiOS Lite 64bit
OMV Version: 6.0.16-1 (Shaitan)
Kernel Version: Linux 5.10.103-v8+
JellyFin Local Install (Not in a Container): Latest up to date
First Issue:
Cloned the working boot thumb drive to a Samsung 870EVO and installed it into the right 2.5" SATA interface: No boot.
Took that same 870EVO installed into a cheap amazon USB SATA drive docking station connected to the internal USBA port in the EON: Everything works identical to the cloned thumb drive.
Clean install of RpiOS lite 64bit to the same 870EVO installed into the same right 2.5" SATA interface: No boot.
Only real conclusion: Can’t boot from SSD via right internal EON SATA interface.
Second issue:
Any combination of the SATA M.2 Drive/USB-A interfaces below installed in the internal USB-A port on the EON: No boot.
The catch with the adapter/M.2 drive combination is that the same Kingston Drive works plugged into the same internal USB-A port on the EON with the below M.2 enclosure. UGREEN M.2 Enclosure
Only real conclusion: Possible compatibility issue/malfunction.
So having laid out all of my attempts and not wanting to spend any money to validate the possible compatibility issue between the adapters and a different M.2 drive. Is this a compatibility issue or a malfunction? Is there a list of known working USB adapter/M.2 combinations? In an ideal setup, for me, I would have the 2 storage drives, 2 SSD’s and boot from an internal M.2 thus being able to close up the EON. As it stands the only way I can do that is to use a thumb drive and I’m not sure about the longevity of this solution due to the frequency of read/writes to a thumb drive, and I loose out on the use of an SSD slot.
@justinobwi I believe the only currently supported boot configurations are via microSD or the internal USB-A port (with a number of posts discussing booting from various M.2 adapters):
You actually may be able to boot with only a single SSD or hard drive connected to one of the SATA connectors (with nothing connected to the other 3 SATA connectors or the internal USB-A port) but that would be wasting quite a bit of the EON’s capabilities.
I am booting from an SSD drive inserted into the internal USB3 socket using this connector. The rest of the bay is taken up with 4 SSD drives (I have not tried booting from any of them). The boot SSD is bare, no case, and I can have the right panel in place.
Picture attached for info.
One oddity. I placed the same OS as you on the SSD then booted and installed without the 4 main SSDs. The USB SSD identified as sda but after booting when the 4 main SSD drives were installed it was identified as sdc.
I’m actually running the same Sata M.2 drive as you and an adapter that looks the exact same, only difference is that it was purchased from US Amazon instead of UK.
I’m thinking it has to be the drive. After looking at your pic. I reformatted my M.2, re-imaged it, installed and still no boot. My thought is that 3 adapters with 1 drive, the likely failure point is the drive. The USB-A port works with other devices.
I’ll order another drive and update once it arrives.
Just to finalize this thread. Everything is now working. The issue was the SATA M.2 drive. Additionally, I suspect that the drive went bad due to a failing USB hub. Below are the adapter and drive that I have working today.
If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues
