Using UUID to specify home and tce partitions on a USB stick

[helander]

One common problem with USB sticks that are used on different computers is that you have no control over the device naming scheme used on the different computers. The USB stick may show up as /dev/sda1 on one computer and /dev/sdc1 on another computer. Using the bootparameters "home=sda1   tce=sda1" the stick will work as expected on the first computer but not on the second (where sda1 most certainly points to a completely different disk).

A "workaround" would be to use the globally unique UID of the partitions in question (you could get the UUID:s of the known partitions using the "blkid" command.

I propose that TinyCore startup code is modified so that you could specify not just the partition "name" (e.g. sda1, sdc2) but also a "uuid" string as the value to the "home" and "tce" boot parameters. The output from the blikid command could be used in the process to translate from "uuid" to "name".

As far as I know, the UUID method is the most robust (100%) method to get a system that boots from a USB stick, also rereference other resources from the same stick.

Kind regards

/Lars

[roberts]

Yes! We were discussing this. Using our autoscan features we were usually able to avoid it.
But now it is time to have it as an option. It is in process. Thanks for your input.

[tobiaus]

i know what a uuid is but not how much it tells you, so i suggest two ideas based on how much information a uuid contains. the way tc does mounting is so wonderful. unlike ubuntu's "friendly but misleading" system that gives a "nice" label and mounts things like "/media/disk" or "/media/disk2" or "/media/disk3" (but i like this for cdroms) you have to use "mount" instead of just looking at the path which is easier (and you don't even have to remember what's what because it's right in front of you) to know what /media/disk is.

in tc mostly you just ls /mnt and (mounted or not) it tells you what can be mounted. (/dev tells you what could be mounted if it was connected or if it isn't. for all /dev knows you have 12 serial ports so it doesn't know anything.) mount is still used to tell you what is and isn't, it's still used to mount and unmount it, but to mount /mnt/sda1 you just "mount /mnt/sda1" and to umount /mnt/sda1, same thing. it's easier than most distros. uuid's are hideous beasts and belong behind the scenes, even if they're vital for certain things. if they can be used to figure out where the first usb is (/something/usb, /something/usb2) then they could be very useful, not just to boot options but to a friendly system.

to maintain the "it is what it is" beauty that tc has right now, plus add the "hey but what is it practically speaking" kind of scheme that ubuntu attempts, it would be cool to invisibly use uuid to symlink what is *actually* mounted in the style of tc's /mnt/sda1 (i know just from looking at the path it's dev/sda1) could be symlinked: thus /dev/sdb1 is the real device, /mnt/sdb1 is the real location (before and after mounting, just like tc is now) and /media/usb1 is the symlink. this would improve on ubuntu's "be nice and mislead me" system. the symlinks would actually tell scripts something useful, not just "nice over" the actual device name, and people that wanted tc's very nice way of making linux purists (/mnt/sda1) go easier on themselves would stay the way it is.

it's not just "something for everyone" but "everything for a reason," and nothing "just 'cause it looks nice." (you won't have to type the uuid.) but, if uuid can't magically tell you all that information... you could just create a symlink for each uuid. thus /mnt/uuids/rAnDoMnumbersANDl3tt3rs00-1u0dhex would always be a symlink from /mnt/sd-whatever-its-mounted-as to the item with the uuid "rAnDoMnumbersANDl3tt3rs00-1u0dhex" and you could use /mnt/sda1 or /mnt/uuid/rAnDoMnumbersANDl3tt3rs00-1u0dhex for a script. if you always use the same key, great. but what if you want to use a script for "anything i mount as /dev/sda1?" hopefully you won't need to parse the output of mount (like you don't need to now.) right now just use ls or find.

[helander]

I think the simplest scheme and less conflicting with current TC "standards" would be as follows:

   1) Assume a boot option that currently holds a partition "name" (home, tce, local, ...) has the value x
   2) Use the output from "blkid" and "grep" for x. This will give you a line of text with both the /dev/yyyy and the corresponding UUID
   3) Filter out the yyyy from this line of text and you have the partition "name" independently if the bootcode value was the partition name or the uuid.

There are few things to remember when it comes to disk device naming schemes:

   1)The actuall namning of the disks devices (/dev/hda, /dev/sdb, /dev/hdc, ...) depdends on
       * The hardware configuration
       * The order in which the BIOS finds the devices
       * The kernel, its drivers and the hwdetect features of the distro in use

As long as you do not change any of the above, you could assume that you what disk /dev/xxxx actually is.
I am used to systems where the hardware configuration changes (plug in/out USB disks) and I also run different Linux distros at different times. This means that I have since long do not view the device names as carved in stone - I must be flexible 

The main problem I wanted to solve was that if I plugin (on an arbitrary computer) a USB stick with TC on it and boot, I would need to be sure that tce, home and local would point to some areas on the stick itself and not on any other disk.

There is of course another side of the problem and that is that if you plugin a USB disk or if you open the box and install an additional disk or remove an existing disk, you will likely modify the naming scheme of the system. This would mean that if you have an fstab that refers to a device name, that system might get corrupted since it relies an a naming scheme no longer valid. This is exactly why distributions like Ubuntu have choosen to use UUID as the "mount"-specifiers.

The use case I am looking for is to plugin a USB stick, boot and run everything from the stick (I do not want to use any other disks on the system) and for that purpose the solution I outlined would be good.

If TC would go for a solution in the future to use UUIDs as mount-specifiers in fstab, in order to secure survival in case of hardware modifications, I am fine with that, but it is not on my "requirement"-list today 


Kind Regards

/Lars
 

[libertyernie]

Each hard drive has a link in /dev/disk/by-uuid/xxxx. I don't know if it will work, but you could try:

Code: [Select]

tce=disk/by-uuid/xxxx

[roberts]

I have an entirely optional implementation of both UUID and LABEL.
I have released it for QA testing by the team.

It will allow anchoring home/opt/restore etc to a specific device by either UUID or LABEL via boot options  This will be available in 1.3rc2.