Inconsistent mount point on Banana Pi Pro over SATA

[manuti 62]

Armbianmonitor:

http://ix.io/3moG

The info from "df" show /dev/sda but "lsblk" show a /dev/sdc unmounted unit. The unit is reachable at /media/sata and is added in fstab using the UUID.

What's happening?

Thanks in advance.

[lanefu 343]

block device names can vary especially on USB.... it's best practices to use UUIDs or LABELS to mount filesystems.

[manuti 62]

7 hours ago, lanefu said:

block device names can vary especially on USB.... it's best practices to use UUIDs or LABELS to mount filesystems.

I used UUIDs to mount via fstab. You can see it in the snapshot and I suppose this info is also included in armbian-monitor dump included.

[Werner 402]

12 hours ago, lanefu said:

block device names can vary especially on USB.... it's best practices to use UUIDs or LABELS to mount filesystems.

Still odd nevertheless. One a block device is assigned it should be consistent across those very basic commands, shouldn't it?

 

[lanefu 343]

5 hours ago, manuti said:

I used UUIDs to mount via fstab. You can see it in the snapshot and I suppose this info is also included in armbian-monitor dump included.

okay sorry I didn’t understand the issue exactly.

 

so I believe this is a technicality of using lsblk.   A btrfs subvolume isn’t going to trace back to a block device.   Would be interesting to look at the output of 

 

ls -l /dev/disk/by-uuid

 

[manuti 62]

After mounting and unmounting several times both external units it seems to start working. Now the mount point at /sda is consistent across all the commands. The outpus you asked, @lanefu, is:

ls -l /dev/disk/by-uuid 
total 0
lrwxrwxrwx 1 root root 15 may 11 22:57 d4e4d15d-d587-4f5d-83d7-4cbb1700e7c5 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root  9 may 11 22:57 dcb5a19c-6bd2-4c5a-8fc4-9ed4adec7074 -> ../../sdb
lrwxrwxrwx 1 root root  9 may 11 22:57 e6201983-bfd8-4eae-bf54-90575f09835f -> ../../sda

 

I also added a new screenshot. Thanks for the help. And I'll keep an eye on this if it happens again.