Bug 248857

Summary: GPT-labeled slizes do not always appear in /dev/gpt/
Product: Base System Reporter: Sjack <jac>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Some People CC: markj
Priority: ---    
Version: 12.1-RELEASE   
Hardware: Any   
OS: Any   

Description Sjack 2020-08-23 19:43:07 UTC
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
Comment 1 Sjack 2020-08-23 22:13:42 UTC
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
Comment 2 Sjack 2020-08-23 22:24:23 UTC
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?
Comment 3 Mark Johnston freebsd_committer freebsd_triage 2020-08-28 13:32:23 UTC
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.
Comment 4 Conrad Meyer freebsd_committer freebsd_triage 2020-08-28 15:10:53 UTC
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.
Comment 5 Mark Johnston freebsd_committer freebsd_triage 2020-08-28 15:29:41 UTC
(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".