UUIDs on drives

[Karl Larsen]

Derek Broughton wrote:
> ghe wrote:
>
>   
>> (This is long, but hopefully the end.)
>>     
>
> Not possible... :-)
>   
>> Look. I think we're all saying pretty much the same thing, but, as
>> someone has said, we're looking at the situation from different points
>> of view and different layers of software/firmware.
>>     
>
> OK, but you're looking at it from the _wrong_ point :-)  Seriously, the
> whole point of software is to separate the user from the hardware by levels
> of abstraction, and you are complaining that we're accomplishing that too
> well.
>
>   
>> My own orientation is somewhat hardware-based. My first computer had no
>> peripherals or drivers, so (with the help of a mentor who knew what he
>> was doing) I built the controllers and wrote the drivers. So I tend to
>> think of a disk drive (or whatever) as a collection of I/O addresses for
>> however the CPU does its I/O.
>>     
>
> And do you believe that we should be writing out to specific addresses on
> the disk?  QED.
>
>   
>> If I install onto a disk in the leftmost SATA slot, there's a unique and
>> unchanging I/O address associated with that disk (as long as it's in the
>> same slot), and I see no reason why the ROM code and the boot loader
>> should ever need to refer to it as anything else. 
>>     
>
> Because they should never NEED to know that they're using the leftmost SATA
> slot.  If my boot loader assumes my boot drive is in the leftmost SATA
> slot, I can _never_ move it.  It shouldn't - and doesn't - care.
>
>   
>> I know it doesn't work this way now, and that's largely what I'm whining
>> about.
>>     
>
> What's more: it MUST not work this way.
>  
>   
>> In my case, with Ubuntu dual booting on the Mac Pro,, udev apparently
>>     
>
> No, udev did nothing of the sort.  udev acts _after_ the kernel.
>
>   
>> (hd0) was always the same because it was determined by the ROM code, but
>> sda wasn't, so when (hd0) was hit to boot, it found and ran grub just
>> fine. 
>>     
>
> So?  If you'd just used UUID you wouldn't have had this issue.
>
>   
>> There are "udev rules" that could maintain consistency with all this,
>> but the installer would have to write some, if a given disk is always to
>> have the same label.
>>     
>
> It shouldn't.  It's a basic principle of relational databases that keys
> should not have semantic content.  That seems to be equally applicable to
> the hardware database.
>
>   
>> And, as has been pointed out, the installer doesn't do that. It could,
>> though. If creating fstab is part of its job, why shouldn't writing a
>> few udev rules be, too?
>>     
>
> Absolutely, it could.  BUT IT WOULD BE A BAD THING!  If you insist, you can
> write those udev rules.  Please don't distribute them.
>
>   
>> udev's purpose of getting rid of redundant nodes in /dev 
>>     
>
> I can't see that that was _ever_ udev's purpose.  If it was it got derailed
> really quickly, as any udev tree has always been a whole lot bigger than
> the pre-udev device tree, afaict.
>
>   
>> Since the node names in /dev are just strings, C's going to be referring
>> to them with pointers anyway, so what's the disadvantage of calling
>> things what they are: SCSIa, SATAa, SASa, IDEa, ATAPIa, FIREWIREa,
>> IEEEa, USB_STICKa, PICTURE_FRAMEa, etc? 
>>     
>
> The disadvantage is that I should never need to know _what_ sort of hardware
> I'm using.  All I need to know about the hardware is whether it's removable
> or not, and if removable, where it's plugged in.
>
>   
>> But UUID on top of udev on top of the kernel on top of the BIOS on top
>> of the CPU's I/O... There's got to be an easier way to get to an I/O port.
>>     
>
> Why?  You shouldn't normally want to get to an I/O port.
>
>   
>> But if I'm thinking something that isn't true or 
>> doesn't make sense, I'd very much like to know about it.
>>     
>  
> Gee, I keep telling you that, but you don't seem to want to know about it...
>   
    The title of this thread bothers me. We are talking about using UUID 
identifiers for PARTITIONS, not drives. I wonder if this is causing the 
talk about /dev and other that have nothing to do with the process.

    Alas I just read man vol_id and it says:

  vol_id is usually called from a udev rule, to provide udev with the
       filesystem type, the label and the uuid of a volume. It supports most
       of the common filesystem formats and detects various raid setups to
       prevent the recognition of raid members as a volume with a 
filesystem.

So the real use of vol_id appears to be for udev. My use of vol_id is to 
print out the proper UUID= when I give it a partition address. I guess 
Ubuntu loader uses it as well.

Karl


-- 

	Karl F. Larsen, AKA K5DI
	Linux User
	#450462   http://counter.li.org.
   PGP 4208 4D6E 595F 22B9 FF1C  ECB6 4A3C 2C54 FE23 53A7