Does FreeBSD use UUID to identify partitions

N

NickC

Just a quick install related question if that is ok before I start my first FreeBSD install. Does FreeBSD use UUID to identify partitions?

Reason for asking is that I intend to install this in a multi disk environment where after the install other disks may be installed or removed above this one in the chain. Will FreeBSD still keep working in that situation? I have found that a many versions of Linux fail to boot unless they remain at exactly the same place in the disk drive chain. In the windows world it is just a case of setting the BIOS to boot from the correct disks MBR, but that is not always the case in the Linux world, and maybe the *nix world.

Thanks,
nick
 
FreeBSD supports UUIDs to identify GPT partitions. It's recommended to label your GEOM providers in some way. UFS(2) supports filesystem labels directly with newfs -L $name. GPT partitions can be labeled with gpart add -l $name. Any GEOM provider can be labeled with glabel except for GPT formatted disks because glabel would overwrite the secondary table. ZFS finds its GEOM providers by on-device meta-data and doesn't care about labels.
 
Thanks for your replies. From what you say if this does not use UUIDs by default then perhaps it is not the ideal OS to use in a multi-disk environment.

Cheers,
Nick
 
That's a strange conclusion. See glabel(8), where it shows that UUIDs appear in /dev/gptid. So yes, UUIDs are "natively suppored", even though more readable and maintainable labels are also available.
 
Perhaps I didn't phrase the question very well, and may have misunderstood your answer. Let me put it a different way:
Lets say I have two disk drives
drive 0
drive 1
I then do a default install of FreeeBSD on drive 1, writing the boot loader to the MBR of drive 1. If drive 0 is then removed from the system will FreeBSD still boot? Also what about if another drive is install further up the chain, lets say our current drive 1 -> drive 2 because a new drive 1 was inserted.
 
Both bsdinstall and the older sysinstall write entries in /etc/fstab with absolute disk numbers. Those need to be changed to labels or UUIDs to make the disk relocatable.
 
Does there happen to be a simple article anywhere describing how to do this. Something that even a Windows sysadmin and Linux/*nix noobie could understand ;)
 
Labels are easier, see the article in post #3. However:

1. Boot in single user mode.
2. Identify the GPTID or label for the disk or partition.
# glabel status
3. Mount the other partitions (to be able to run an editor): mount -a.
4. Edit /etc/fstab, replacing drive or partition references with GPTID or label references.
Code: 
/dev/ada0p2         /     ufs      rw           1           1
becomes
/dev/gpt/gprootfs   /     ufs      rw           1           1
or
/dev/gptid/978973df-74f9-11e1-8601-f52720ac5086    /     ufs      rw           1           1
 
gptid is the way to go. My system I installed the system on an SSD, but had many more disks to install. In Linux you can use blkid which is way easier, but the same concept can apply in FreeBSD. From the output of gpart show:
Code: 
root@beneschtech:/usr/local/etc # gpart show
=>        40  5860533088  ada0  GPT  (2.7T)
          40  5860533088     1  freebsd-zfs  (2.7T)

=>        40  5860533088  ada1  GPT  (2.7T)
          40  5860533088     1  freebsd-zfs  (2.7T)

=>        40  5860533088  ada2  GPT  (2.7T)
          40  5860533088     1  freebsd-zfs  (2.7T)

=>        40  5860533088  ada3  GPT  (2.7T)
          40  5860533088     1  freebsd-zfs  (2.7T)

=>        34  3907029101  ada4  GPT  (1.8T)
          34           6        - free -  (3.0K)
          40  3774873600     1  freebsd-ufs  (1.8T)
  3774873640   132155495        - free -  (63G)

=>       40  976773088  ada5  GPT  (466G)
         40     532480     1  efi  (260M)
     532520  968351744     2  freebsd-ufs  (462G)
  968884264    7888864     3  freebsd-swap  (3.8G)

As you can see, ada5 has the system on it, ada0 was what it installed to at first before I plugged in the other disks. Now you can do:
Code: 
root@beneschtech:/usr/local/etc # gpart list ada5 | grep rawuuid
   rawuuid: 236455e5-88dd-11ed-8cd8-40167ee8b0d1 << ada5p1 (EFI)
   rawuuid: 23658a99-88dd-11ed-8cd8-40167ee8b0d1 << ada5p2 (/)
   rawuuid: 23661ae8-88dd-11ed-8cd8-40167ee8b0d1 << ada5p3 (swap)

The << parts were added by me for illustrative purposes, but that's how it will map out. Now in /etc/fstab:
Code: 
root@beneschtech:/usr/local/etc # cat /etc/fstab
# Device    Mountpoint    FStype    Options    Dump    Pass#
# Main system on SSD 500G
/dev/gptid/23658a99-88dd-11ed-8cd8-40167ee8b0d1 /        ufs    rw    1    1
/dev/gptid/236455e5-88dd-11ed-8cd8-40167ee8b0d1 /boot/efi    msdosfs    rw    2    2
/dev/gptid/23661ae8-88dd-11ed-8cd8-40167ee8b0d1 none        swap    sw    0    0

# home dirs on 2TB spinning disk
/dev/gptid/2c83071b-88eb-11ed-b084-40167ee8b0d1 /usr/home    ufs    rw    0    0

My other 4 disks are for a zpool. Now, a few other points of note here:
If your system boots with standard /dev/ada0... entries, the /dev/gptid structure will NOT appear, but if you boot by them, they are persistent. Seems stupid to me, but hey it is what it is.
The /dev/gpitd entries are not a forest of symbolic links like Linux, they are regular character devices, seems less error prone to me so +1 BSD. But it also means you have to really pay attention to making sure you have the right disk. So I guess its a draw.

Nice little hack with vi:
Do the gpart command above and append >> /etc/fstab to it.
In the file, break the lines right after the disk identifier.
Use dd then p on the identifier line to put the uuid sandiwched in there.
remove the rawuid: part, I think its 2 words, so "02dw" in command mode on the uuid line.
Replace the /dev/ada... line with /dev/gpitd/ and merge the next two lines "0DA/dev/gptid/<esc>JxJ" Where <esc> is the escape key

Maybe try it on swap first, it will complain but still boot, so you can get the hang of it, then move on to using partition IDs.
 
You must log in or register to reply here.
Back
Top