svn commit: r292058 - head/sbin/geom/class/part

[Ravi Pokala]

-----Original Message-----


From: <owner-src-committers at freebsd.org> on behalf of Ian Lepore <ian at freebsd.org>
Date: 2015-12-12, Saturday at 09:20
To: Alexey Dokuchaev <danfe at FreeBSD.org>, "Andrey V. Elsukov" <ae at FreeBSD.org>
Cc: <src-committers at freebsd.org>, <svn-src-all at freebsd.org>, <svn-src-head at freebsd.org>
Subject: Re: svn commit: r292058 - head/sbin/geom/class/part

>I spent much of the last week fighting with "geom destroy" and trying
>to prevent the ressurection of old geoms during the creation of new
>ones.  It's a Big Mess and it doesn't really work well at all.  I came
>to the conclusion that it's not geom destroy that needs a force flag so
>much as geom create, where it would mean "it is okay to replace any
>existing geom with the new one."
>
>For example if you have a freebsd slice da0s1 that contains freebsd
>partitions within it, and you geom destroy -F da0 then that slice and
>the partitions within it disappear.  Then as soon as you create a new
>geom for the device and add a slice that happens to fall on the same
>sector that da0s1 used to live at, suddenly that whole geom tree comes
>back to life and your next command to create a new geom da0s1 fails
>because it already exists.

At work, we frequently boot from LAN and do automated installs. The partitioning ~never changes, so we run into exactly the scenario you described. I ended up doing a horrible hack which parses the existing partition table (both slice/label and GPT), and zeros out the first and last few sectors of each partition. AND parse the partitioning info we're passing to the installer, and zeroing out the first and last sectors of the partitions we're ABOUT TO create. It's a medium-sized PITA, but it works.

-Ravi (rpokala@)