David Zeuthen wrote:
How about giving a hint as to which _physical_ disk it is? Imagine you had a couple of scsi controllers each with a bunch of disks, plus some sata and USB volumes and you add one (which might currently have labels that match other drives) and want to format it. Which one is it? Or a drive in the system fails and isn't detected. How do you find which one it was?
You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..
No - sdb1 tells me what order the OS detected it it. It says nothing about the physical connection or even which controller is involved. Does anyone actually use this system with a large number of disks that sometimes need attention? If the drive that was sdb yesterday fails in a way that keeps it from being detected, sdb will mean something else after a reboot.
Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit most of this before F9 as part of the gio/gvfs hacking. Stay tuned!
How do you change the UUID's on md arrays? I often clone machines by separating RAID1 drives and letting them sync to new partners. If those separated drives ever find themselves back in the same machine, I wouldn't want them to rebuild automatically.
I'm failing to see why this question relevant to this discussion?
Same general rant about not being able to tell/control what is really going on. I don't like the system to guess, especially when I know the answer will likely be wrong.
I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if applicable; e.g. some FS's don't have UUID); and b) use some sane labels by default. The user is still free to edit /etc/fstab to use LABEL= instead of UUID= and/or relabel his drives or do whatever he wants.
And similarly, I'd like a way to peg these to physical controller/cable/drive selects because the UUIDs and labels are all going to be the same on disks that I've cloned with DD or letting RAID1's rebuild. I know you can't on USB, but about everything else has a controller/target/LUN concept to identify it.