GELI file systems unusable after "glabel label" operations

[cpghost]

On Fri, Jan 15, 2010 at 01:25:50AM -0600, Scott Bennett wrote:
> >Check /var/backups. There should be *.eli files there. Those are the automa=
> >tic
> 
>      No joy. :-(
> 
> >metadata backups that 'geli init' makes (at least in 8.0). You can restore
> >those backups with 'geli restore'.
> 
>      Those must be new in 8.0.  I don't see any in 7.2, just {aliases,group,
> master.passwd}.bak{,2} in /var/backups.

[No help here, just a me-too...]

I can confirm this: no metadata of GELI partitions generated on
RELENG_7 were saved in /var/backups, but GELI partitions created
since RELENG_8 were!

I've noticed this by chance with "geli init" on an external disk, and
thought that geli init would only create metadata backup automatically
for disks that are not the same than the one hosting /var/backups (for
obvious reasons, i.e. when you want to quickly destroy a key, and for-
getting to wipe out the metadata backup).

Apparently, it was the version bump, and not the different disks. Good
to know indeed.

Would a "geli backup" on those old RELENG_7 GELI partitions (or rather
provider partitions) have the same effect as a RELENG_8-style "geli init"
to get those metadata files? Maybe /usr/src/UPDATING should contain a
little hint for those of us with old GELI partitions without auto-backups
of metadata?

>      I have a new 1 TB drive that I will soon connect to the system and begin
> creating file systems.  I will make gzipped image files with dd(1) of the
> damaged partitions and store them on the new drive for a while in case a
> workable idea turns up.

I feel your pain (having lost some data in a similar scenario while
experimenting with glabel on geli partitions, but not as much as you).

There should really be a big obvious warning in the glabel(8) and
geli(8) man pages, because that's a big trap waiting to spring on
unsuspecting users (POLA violation). :-(

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/