GELI file systems unusable after "glabel label" operations

Scott Bennett bennett at
Thu Jan 14 12:53:11 UTC 2010

     On Thu, 14 Jan 2010 10:30:00 +0100 Ivan Voras <ivoras at>
>Scott Bennett wrote:
>>      I used "glabel label" to label each of the file systems I have on external
>> disk drives.  Unfortunately, afterward I am now unable to "geli attach" any of
>> the GELI-encrypted file systems.  The system is FreeBSD 7.2-STABLE.  
>Hmm, did you say you had geli-encrypted drives, then you have 
>overwritten the last sector with glabel, and then you are surprised you 
>cannot get to the data any more?

     No, I am not surprised, just disappointed that when I asked exactly
that question on this list, the only response I got was one that missed
the point of my question.  So I experimented first with an unencrypted UFS2
file system and saw no problem with it.  I then proceeded, but stupidly
did it to both the primary encrypted file systems and the encrypted backup
file system at the same time, so I can't restore from the backups I had
taken because they are also hosed.
     Neither the man page nor the handbook covers the combination of a
partition labeled by "glabel label" and encryption with GELI.  Apparently,
though, the two are completely incompatible.  The label metadata have to be
readable at boot time in order to create the /dev/label/whatever device file,
but the metadata apparently occupy the same place as GELI metadata.  What a
mess.  I have no idea how many hundreds, or perhaps thousands, of hours of
work were lost, but it was a *lot* of time and effort.
> > Or have I just lost everything in the encrypted
> > file systems?
>I think you did.
> From the geli(8) man page:
>"init ... The last provider’s sector is used to store metadata."
> From the glabel(8) man page:
>"label ... metadata is stored in a provider’s last sector."

     That was why I had originally posted my questions.  It seemed to me
that the usage of that sector might have been designed in such a way as
to allow both GELI and labeling to be used together.  It seem, however,
that that capability was not included in the design.
>If you did "geli init ... da0" and then "glabel label ... da0" then you 
>have lost the geli metadata, which contains keys, etc. You might recover 
>this, though, by reading geli(8) about the "restore" command.

     The "restore" only works if a "backup" operation had been done to
produce a file from which to restore the metadata, which I had never done.
>There is no way you can label your devices after you applied geli to 
>them (which is one of the points of using geli...). You could destroy 
>the geli layer (and the data), apply the label and then apply geli to 
>the label.
     As noted above, that would not work because then the label would not
be readable at boot time.  It now looks to me as though the only way the
two could be used in combination would require that the label and the GELI
metadata be stored in separate places and that the label would have to be
applied *after* the GELI data were created, so that the label would be
readable at boot time.  So the two features are currently unusable in
combination.  That means that a GELI-encrypted partition cannot be mounted
by a /dev/label/whatever device, which means, in effect, that a GELI-
encrypted partition cannot be mounted from a drive in a multiple-drive
system using a device name given in /etc/fstab.  Such a partition has to
be mounted manually with the device file name entered explicitly. :-(
     Now I have one more question.  If I use the same key file to do a
"geli init" on one of the damaged partitions, what will happen?  Is there
a chance that the rest of the data might then be accessible?

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *

More information about the freebsd-questions mailing list