Summary: | GPT-labeled slizes do not always appear in /dev/gpt/ | ||
---|---|---|---|
Product: | Base System | Reporter: | Sjack <jac> |
Component: | misc | Assignee: | 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
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". |