Probably a very Noob question but here goes…
Is there any way, looking at the drive slots from the from of the machine and from left to right, to identify how they are represented in the OS …sda, sdb, sdc, etc? From what I’ve read so far, I can use smartmontools to run tests on the health of a drive, but unless I use drive from different manufacturers I don’t see how you identify, if they are identical drives, which drive might actually be failing.
I’m kind of figuring that it’s a hardware thing since the internal USB drive slot always comes up as sdb…so I’d like to identify the others, for future reference, if a drive does start to fail that I know which one it is.
Thanks for the help.
1 Like
@jet438 If your EON has more than one drive, the order in which their corresponding device nodes are added is arbitrary.You will want to configure /etc/smartd.conf to query your various drives via their universally unique identifier (UUID):
/dev/disk/by-uuid/01234567-890a-12b3-456c-789012345678 -d sat -a -o on -s (S/../.././02|L/../../6/03)
sudo blkid will provide you with a UUID listing.
That part I can do. My issue is that I gave 2 physically identical drives.
Let’s say they’re registered as sda and sdb. Now, hopefully, they last for a long time but some day smart is going to notify that one of the drives is failing…say sdb. I open the case and which one do I choose? Is the only way to match it up by serial number?
Yes - serial number - unless your drives include visible indicator leds (that can be briefly “flashed” to identify).
Does anyone know why I have a “removable” drive (as denoted by RM=1) attached to sda when I run lsblk? I only have a single hard drive in my EON which I mount by UUID. mmcblk0 is presumably my microSD card. I would expect my one and only hard drive to be allocated to sda, what’s the “removable” device?
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 57.5M 1 loop /snap/core20/1437
loop1 7:1 0 57.8M 1 loop /snap/core20/1498
loop2 7:2 0 71.8M 1 loop /snap/lxd/22915
loop3 7:3 0 71.8M 1 loop /snap/lxd/22927
loop4 7:4 0 38.7M 1 loop /snap/snapd/15541
loop5 7:5 0 38.7M 1 loop /snap/snapd/15909
sda 8:0 1 0B 0 disk
sdb 8:16 0 7.3T 0 disk
└─sdb1 8:17 0 7.3T 0 part /mnt/vol1
mmcblk0 179:0 0 119.1G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 118.8G 0 part /
Here’s what I get - it mentions “USB” in here - I am running Ubuntu 22.04, I wonder whether it is allocating a separate device to the USB dongle thing that bridges the SATA board to the Pi?
/org/freedesktop/UDisks2/block_devices/sda:
org.freedesktop.UDisks2.Block:
Configuration: []
CryptoBackingDevice: '/'
Device: /dev/sda
DeviceNumber: 2048
Drive: '/org/freedesktop/UDisks2/drives/Pinas_SATA_0000000000EC'
HintAuto: true
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: true
HintSymbolicIconName:
HintSystem: false
Id:
IdLabel:
IdType:
IdUUID:
IdUsage:
IdVersion:
MDRaid: '/'
MDRaidMember: '/'
PreferredDevice: /dev/sda
ReadOnly: false
Size: 0
Symlinks: /dev/disk/by-id/usb-Pinas_SATA_0000000000EC-0:0
/dev/disk/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2.2:1.0-scsi-0:0:0:0
UserspaceMountOptions:
@edward The EON’s built-in SATA board should not (normally) be indicating any (empty) devices.
Do you perhaps have some sort of adapter plugged into the EON’s internal USB port?
Also - are you seeing any related (/dev/sda) entries within /var/log/dmesg ?
Here is (I think) the relevant bit of the /var/log/dmesg file:
[ 2.943259] kernel: usb 1-1.2: New USB device found, idVendor=2109, idProduct=2817, bcdDevice= 0.50
[ 2.943282] kernel: usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.943299] kernel: usb 1-1.2: Product: USB2.0 Hub
[ 2.943313] kernel: usb 1-1.2: Manufacturer: VIA Labs, Inc.
[ 2.945948] kernel: hub 1-1.2:1.0: USB hub found
[ 2.946278] kernel: hub 1-1.2:1.0: 4 ports detected
[ 3.805991] kernel: scsi 0:0:0:0: Direct-Access Pinas SATA 0 PQ: 0 ANSI: 6
[ 3.806589] kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3.807248] kernel: sd 0:0:0:0: [sda] Media removed, stopped polling
[ 3.809380] kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 3.869352] kernel: raid6: neonx8 gen() 3654 MB/s
[ 3.937350] kernel: raid6: neonx8 xor() 2699 MB/s
[ 4.005340] kernel: raid6: neonx4 gen() 4003 MB/s
[ 4.005699] kernel: usb 2-2.4: new SuperSpeed USB device number 4 using xhci_hcd
[ 4.030856] kernel: usb 2-2.4: New USB device found, idVendor=1741, idProduct=1156, bcdDevice= 1.00
[ 4.030868] kernel: usb 2-2.4: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 4.030875] kernel: usb 2-2.4: Product: sata
[ 4.030881] kernel: usb 2-2.4: Manufacturer: Pinas
[ 4.030886] kernel: usb 2-2.4: SerialNumber: 0000000000E1
[ 4.040402] kernel: scsi host1: uas
[ 4.052986] kernel: scsi 1:0:0:0: Direct-Access Pinas sata 0 PQ: 0 ANSI: 6
[ 4.073345] kernel: raid6: neonx4 xor() 2755 MB/s
[ 4.077136] kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0
[ 4.105258] kernel: sd 1:0:0:0: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
[ 4.105276] kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks
[ 4.105469] kernel: sd 1:0:0:0: [sdb] Write Protect is off
[ 4.105477] kernel: sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 4.105786] kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.112166] kernel: sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
@edward 
Do you have only a single (8TB) hard drive connected directly to the EON’s SATA board?
Within your dmesg output, I am also seeing entries related to a RAID6 configuration (which may explain the mysterious /dev/sda behavior).
Hi, I did some investigating. I wasn’t happy booting Ubuntu direct from the microSD card, so I decided to clone it to an 2.5" SSD and boot from that instead. This SSD is now plugged into one of the other SATA ports along with my WD Red.
With this change, I’m no longer getting this “ghost” removable drive. I did a bit of reading about the “raid6” messages and they may be normal for the Raspberry PI, but I stand to be corrected.
Interesting - glad you were able to get the behavior resolved!
As you mentioned, dmesg will typically contain a handful of kernel: raid6: messages as they are related to software RAID kernel drivers (that mdadm relies on).
Sorry to revive this topic after almost 2 years, but is my understanding correct that you managed to boot from one of the SATA slots?
Edit: Apparently it works! I cloned my sd card to an SSD slotted in the 4th sata bay, changed boot order to USB first and it boots without issues.