I Installed a 12.1 p0 system on a USB drive on an EFI system using ufs file system. First installed without labels added the labels later. They appeared on gpart list, not in /dev/gpt. [jac@atomic03 ~]$ uname -a FreeBSD atomic03 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 [jac@atomic03 ~]$ gpart show da1 => 40 125045344 da1 GPT (60G) 40 409600 1 efi (200M) 409640 119128064 2 freebsd-ufs (57G) 119537704 5507680 3 freebsd-swap (2.6G) [jac@atomic03 ~]$ sudo gpart list da1 | grep label label: efi label: root label: swap [jac@atomic03 ~]$ ls -al /dev/gpt/ total 1 dr-xr-xr-x 2 root wheel 512 Aug 23 10:56 . dr-xr-xr-x 17 root wheel 512 Aug 23 10:56 .. crw-r----- 1 root operator 0x99 Aug 23 10:56 efi [jac@atomic03 ~]$ Then did a fresh install on an identical configuration. Added the labels in the install configuration menu. Same result: The labels appear on gpart list, not in /dev/gpt. Then did a freebsd-update to 12.1 p8. Same result: The labels appear on gpart list, not in /dev/gpt. [jac@atomic04 ~]$ uname -a FreeBSD atomic04 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC amd64 [jac@atomic04 ~]$ sudo gpart show da1 => 40 125045344 da1 GPT (60G) 40 409600 1 efi (200M) 409640 119128064 2 freebsd-ufs (57G) 119537704 5507680 3 freebsd-swap (2.6G) [jac@atomic04 ~]$ sudo gpart list | grep label label: efi0 label: root0 label: swap0
Additional info: When I start the system in Single user mode the labels are in the gpt directory. # uname -a FreeBSD atomic04 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC amd64 # gpart show da1 => 40 125045344 da1 GPT (60G) 40 409600 1 efi (200M) 409640 119128064 2 freebsd-ufs (57G) 119537704 5507680 3 freebsd-swap (2.6G) # gpart list da1 | grep label label: efi0 label: root0 label: swap0 # ls -al /dev/gpt/ total 2 dr-xr-xr-x 2 root wheel 512 Aug 23 17:02 . dr-xr-xr-x 17 root wheel 512 Aug 23 17:02 .. crw-r----- 1 root operator 0x99 Aug 23 17:02 efi0 crw-r----- 1 root operator 0x99 Aug 23 17:02 root0 crw-r----- 1 root operator 0x99 Aug 23 17:02 swap0 When I then exit and continue the boot results are. [root@atomic04 ~]# gpart show da1 => 40 125045344 da1 GPT (60G) 40 409600 1 efi (200M) 409640 119128064 2 freebsd-ufs (57G) 119537704 5507680 3 freebsd-swap (2.6G) [root@atomic04 ~]# gpart list da1 | grep label label: efi0 label: root0 label: swap0 [root@atomic04 ~]# ls -al /dev/gpt/ total 2 dr-xr-xr-x 2 root wheel 512 Aug 23 17:02 . dr-xr-xr-x 17 root wheel 512 Aug 23 17:02 .. crw-r----- 1 root operator 0x99 Aug 23 17:02 efi0
Again some additional info. I decided to bite the bullet and chanced the /etc/fstab to use the labels. And rebooted, system came up and now the labels are there. [root@atomic04 ~]# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# #/dev/da1p2 / ufs rw 1 1 /dev/gpt/root0 / ufs rw 1 1 #/dev/da1p3 none swap sw 0 0 /dev/gpt/swap0 none swap sw 0 0 [root@atomic04 ~]# ls -al /dev/gpt/ total 1 dr-xr-xr-x 2 root wheel 512 Aug 23 17:17 . dr-xr-xr-x 12 root wheel 512 Aug 23 17:17 .. crw-r----- 1 root operator 0x93 Aug 23 17:17 efi0 crw-r----- 1 root operator 0x96 Aug 23 17:17 root0 crw-r----- 1 root operator 0x99 Aug 23 17:17 swap0 [root@atomic04 ~]# So my issue is resolved. Question is is this behaviour as designed?
Yes, I believe this is basically "works as intended". It's a problem with the aliasing mechanism in GEOM which allows one to refer to a device by multiple names (/dev/da1pN, /dev/gpt/foo, /dev/ufs/bar, /dev/diskid/baz, etc.). Once something opens a device by one of the names, it obtains exclusive access to the underlying device and causes the aliases to wither away. My understanding is that the aliasing code has been reworked in head to avoid this problem, but I'm not completely certain.
Warner and Xin Li have some alias / gpart refactoring in head; my changes were reverted due to a similar problem: some kinds of geom don’t seem to effectively get retasted. Even after spending a few days on it I still don’t understand geom well enough to explain why sometimes we don’t retaste. I’m not pleased that we delete aliases when one is opened rw — I think it would be better to leave the alias and just fail opens with an access error.
(In reply to Conrad Meyer from comment #4) Yeah, it's an annoying behaviour that comes up pretty regularly. "Works as intended" is less accurate than "works as expected".