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.
Probably a very Noob question but here goes…
@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 /
@edward What are the udisks output details?
udisksctl info -b /dev/sda
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
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).