Bug 202089
| Summary: | gpart erroneously creates partitions with a '1' label | ||
|---|---|---|---|
| Product: | Base System | Reporter: | sub.mesa |
| Component: | bin | Assignee: | Alexander Motin <mav> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | ae, mav |
| Priority: | --- | ||
| Version: | 10.2-BETA1 | ||
| Hardware: | Any | ||
| OS: | Any | ||
A commit references this bug: Author: mav Date: Thu Aug 13 13:19:57 UTC 2015 New revision: 286719 URL: https://svnweb.freebsd.org/changeset/base/286719 Log: Revert part of r280687, reporting "1" (true) for empty value. For example, it made gpart partitions without label report "1" as label. PR: 202089 MFC after: 3 days Changes: head/lib/libgeom/geom_xml2tree.c I've committed the fix into HEAD branch. I will merge it in three days. This bug affected only `gpart` command output, not affecting system operation. |
*** Problem description gpart will report partitions to have a label called '1' while no label has been assigned. The label will not actually propagate to GEOM, so no /dev/gpt/1 device node will exist, but 'gpart show -l' will report the erroneous '1' label where it should state '-' (dash) instead to indicate the partition has no label attached. *** Environment # uname -a FreeBSD zfsguru.bsd 10.2-RC1 FreeBSD 10.2-RC1 #0 r286032 *snip* amd64 Kernel is a GENERIC-like kernel with some minor additions (OFED Infiniband, AltQ traffic shaping and device polling; that is it). I have seen this issue before, but did not properly diagnose it until today. This means the actual offending commit can be far into the past. I did not encounter this bug on 10.1 though. *** Steps to reproduce # gpart show ada0 gpart: No such geom: ada0. # gpart create -s gpt ada0 ada0 created # gpart add -s 1024 -t freebsd-boot ada0 ada0p1 added # gpart show -l ada0 => 34 25165757 ada0 GPT (12G) 34 1024 1 1 (512K) 1058 25164733 - free - (12G) ### note that gpart says label '1' for the first partition, while no label has been assigned! Also note that the label is not actually there as device node or seen by glabel status: # ls -l /dev/gpt/ ls: /dev/gpt/: No such file or directory # glabel status Name Status Components iso9660/ZFSGURU-LIVECD N/A cd0 diskid/DISK-VB5bfe914e-38cf2b58 N/A ada0 ### now try some other things by explicitly assigning a label name, which works: # gpart add -s 1024 -t freebsd-boot -l 'LabelName' ada0 ada0p2 added # gpart add -s 1024 -t freebsd-boot -l 1 ada0 ada0p2 added # gpart add -s 1024 -t freebsd-boot -l 2 ada0 ada0p3 added # gpart show -l ada0 => 34 25165757 ada0 GPT (12G) 34 1024 1 1 (512K) 1058 1024 2 LabelName (512K) 2082 1024 3 1 (512K) 3106 1024 4 2 (512K) 4130 25161661 - free - (12G) ### note that when explicitly giving '1' or '2' as label name, this does get seen by glabel and the device node: # ls -l /dev/gpt total 0 crw-r----- 1 root operator 0x77 Aug 4 19:34 1 crw-r----- 1 root operator 0x75 Aug 4 19:35 2 crw-r----- 1 root operator 0x73 Aug 4 19:34 LabelName # glabel status Name Status Components iso9660/ZFSGURU-LIVECD N/A cd0 gpt/LabelName N/A ada0p2 gpt/1 N/A ada0p3 gpt/2 N/A ada0p4 diskid/DISK-VB5bfe914e-38cf2b58 N/A ada0 *** Conclusion It appears gpart always says '1' instead of '-' (dash character) when a partition has no label. When explicitly giving '1' as label, this works but the gpart show output shows no distinction between the fake '1' label partitions and ones that have a genuine '1' label. This is a bug. This triggers a bug in the ZFSguru storage appliance product, which uses GPT labels to prevent user error. But now all partitions have a '1' label which causes all kinds of problems in the ZFSguru web-interface. A workaround/patch or fix is highly appreciated! Thanks for all your efforts on improving BSD! It is highly appreciated by myself and others!