I'm rebuilding a GPT table from scratch which was previously mirrored, attempting using... gpart backup ada0 > /tmp/bk gpart restore ada1 < /tmp/bk And noticed that it didn't restore the labels for the device when I ran `gpart list ada1`. All of the other data was in synch. These devices were previously being synched via a single gmirror.
On 26.07.2013 06:21, Garrett Cooper wrote: >> Description: > I'm rebuilding a GPT table from scratch which was previously mirrored, attempting using... > > gpart backup ada0 > /tmp/bk > gpart restore ada1 < /tmp/bk > > And noticed that it didn't restore the labels for the device when I ran `gpart list ada1`. You forgot to specify -l flag when restoring. But anyway it can't restore scheme specific labels, like gptids. -- WBR, Andrey V. Elsukov
On Fri, Jul 26, 2013 at 3:03 AM, Andrey V. Elsukov <bu7cher@yandex.ru> wrote: > On 26.07.2013 06:21, Garrett Cooper wrote: >>> Description: >> I'm rebuilding a GPT table from scratch which was previously mirrored, attempting using... >> >> gpart backup ada0 > /tmp/bk >> gpart restore ada1 < /tmp/bk >> >> And noticed that it didn't restore the labels for the device when I ran `gpart list ada1`. > > You forgot to specify -l flag when restoring. But anyway it can't > restore scheme specific labels, like gptids. Ack, ok. From a usability perspective though I would hope that -l would default to on, not off. It caught me by surprise more than anything else when the labels weren't present.
On 26.07.2013 23:18, Garrett Cooper wrote: > On Fri, Jul 26, 2013 at 3:03 AM, Andrey V. Elsukov <bu7cher@yandex.ru> wrote: >> On 26.07.2013 06:21, Garrett Cooper wrote: >>>> Description: >>> I'm rebuilding a GPT table from scratch which was previously mirrored, attempting using... >>> >>> gpart backup ada0 > /tmp/bk >>> gpart restore ada1 < /tmp/bk >>> >>> And noticed that it didn't restore the labels for the device when I ran `gpart list ada1`. >> >> You forgot to specify -l flag when restoring. But anyway it can't >> restore scheme specific labels, like gptids. > > Ack, ok. From a usability perspective though I would hope that -l > would default to on, not off. It caught me by surprise more than > anything else when the labels weren't present. It isn't on by default, because GEOM_LABELS doesn't like when different providers have the same labels. -- WBR, Andrey V. Elsukov
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
As of 12.0-ALPHA9, gpart does partial label restore in case of GPT labels, when user is specifying -l flag and label contains whitespace(s). Everything post 1st whitespace gets lost. E.g. MS-Windows Setups set labels with whitespaces. Parsing to the end of line instead of whatever [^[:alnum:]] might be in use should do the trick, but haven't had a look into the code and the trivial fix isn't as trivial for me as it should be ;-) If /dev/ada0 has a GPT with labels containing whitespaces, you can falsify with disk=ada0 file="${TMP:-/tmp}"/${disk}.gpart.txt /sbin/gpart backup ${disk} > "${file}" /bin/cat "${file}" | /sbin/gpart restore -Fl ${disk} If you look at $file, there's something like "Basic data partition", which became "Basic" during restore. -harry