Re: GELI file systems unusable after glabel label operations
On Sat, 16 Jan 2010 10:31:22 +0100 Roland Smith rsm...@xs4all.nl wrote: On Sat, Jan 16, 2010 at 12:38:14AM -0600, Scott Bennett wrote: 2) Create the geli device /dev/daXsYP.eli, and then create a label on th= at, yielding /dev/label/bar. [not sure what the utility of this is, since= the label will only appear after the geil provider has been attached] The important point here is that one of the above methods must be us= ed *before* the file system is created and the data loaded into it. Attempt= ing either method *after* data are loaded will result in loss of the data. Maybe not immediately, but since both the filesystem and geom can use the l= ast sector, there will be trouble. :-) The examples in the glabel manpage should how to set up a label correctly. Perhaps this provides a possible recovery method. As you read it, would it be possible to build an altered version of geli(8) that would si= mply use the existing key file without generating a new one to do a geli init operation? If so, it would certainly be worth my trouble to do that. In theory it is possible, I guess. But the salt is 512 bytes long. So it can have 2^512 different values. That is 1.340=C3=9710^154 different values, an= d you'd have to test them all. And by testing I mean use the modified 'geli init' to Why is that stored in the last sector of the device, rather than in the key file? What is the purpose of the key file if not to hold that type of information? generate a key, and then try if the key works, i.e. check if the relevant sector decrypted with that key yields a valid UFS2 superblock. Suppose you wrote a program capable of testing 10^9 keys every second, which sounds like quite alot to me. It would still be running for 2^512/1e9/(3600*24*365) =3D 4.25=C3=9710^137 years! So in practice, this is a hopeless task. And I think that the proper way to nest geoms is too obvious (at least f= or =3D the developers/maintainers) to explicitly list in the handbook. If you know = that geoms store metadata in their last sector, the proper way to nest them i= s to use the different devices for each geom stage, so that each has their = own metadata sector. =20 Well, it wasn't at all obvious to me, and reading the parts that men= tion metadata being written to the last sector suggests, if anything, that lab= eling and encryption are incompatible because both write to the last sector, = i.e., to the *same* sector. The idea of the last sector being different for = the two operations is not at all apparent. Well, it should be different, otherwise they overwrite the same sector. Ipso facto you should nest providers... ...unless, of course, the two had been designed to use different parts of the last sector for their own purposes, but also to avoid damaging the other's data when altering their own. Say you want to have a labeled, encrypted device on /dev/da0s1d. First, you create the label; glabel label =E2=80=90v foo /dev/da0s1d A device /dev/label/foo now appears. This device is one sector smaller than /dev/da0s1d, because the last sector of /dev/da0s1d is used for the glabel metadata. Now we want to create an encrypted device, so we do: geli init -l 256 /dev/label/foo geli attach /dev/label/foo This will create /dev/label/foo.eli. Again, /dev/label/foo.eli is one sector smaller than /dev/label/foo, because the last sector of /dev/label/foo contains the geli metadata. If one uses geli init -l 256 /dev/da0s1d geli attach /dev/da0s1d this will create and attach /dev/da0s1d.eli, but /dev/label/foo will be des= troyed, because 'geli init' overwrites glabel's metadata! Below I've tried to sketch the last sectors of the device, with the extents= of the geom-ed devices and the location of the metadata below. -- /dev/da0s1d ...N-5N-4N-3N-2 N-1N | | | | | | geli |glabel| -- /dev/label/foo --- /dev/label/foo.eli Nested geom devices are the only way to keep the metadata safe. Thanks for the explanation. However, if the key information is stored in the last sector rather than in the key file, then I guess I'm totally confused about how GELI works. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * 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 * **
Re: GELI file systems unusable after glabel label operations
On Fri, Jan 22, 2010 at 03:08:00AM -0600, Scott Bennett wrote: Why is that stored in the last sector of the device, rather than in the key file? What is the purpose of the key file if not to hold that type of information? All geom(4) providers use their last sector to store metadata; it's a design decision. Probably because the first sector(s) are used for boot blocks or filesystem metadata etc. It would have been possible to store the generated key in the user-provided keyfile. But since it is not mandatory to have a keyfile (you can also use just a passphrase), it makes more sense to use the already provided metadata space in the last sector. Well, it should be different, otherwise they overwrite the same sector. Ipso facto you should nest providers... ...unless, of course, the two had been designed to use different parts of the last sector for their own purposes, but also to avoid damaging the other's data when altering their own. The geom framework was designed to be _extensible_. It was designed so that it would be possible to combine (nest) different types of geom providers, even if those classes (types of providers) didn't even exist when the framework was designed. Trying to shoehorn all metadata for any combination of geom providers into on 512-byte sector would have severely limited the usability of the geom system. In my opinion the solition of using nested providers each using their own last sector for metadata is simple and elegant and avoids that problem rather nicely. As I've been trying to explain, the 'nesting' of geoms is _precisely_ what avoids the whole issue of damaging each others data. I've got the feeling that you do not 'get' that concept, which lead to your problem. Unfortunately, I don't know how to explain it more clearly. Thanks for the explanation. However, if the key information is stored in the last sector rather than in the key file, then I guess I'm totally confused about how GELI works. The encryption key is _not_ stored in the last sector. That would be unsafe, like locking your front door and leaving the key in the lock. But a part of the information necessary to create the encryption key is. Your keyfile is just one component of the en- / decryption key to unlock the data. They are not the same. You can use one or more keyfile(s), a passphrase or both. You can also have more than one key; a user key and a 'company' or system key. And geli uses a random component when the encryption key is initially created. The metadata sector is the natural place to store some of that info. This is safe because it is in itself not sufficient to create the en- / decryption key. One also need the keyfile and/or passphase. Personally, I would never use only a keyfile; it is not really secure, especially if you leave that key on another unencrypted partition of the same drive! So-called two-factor authentication (something you have [keyfile] and something you know [passphrase]) is much safer. If you really want to know how geli works, as always with free software, the source code is the ultimate reference. :-) Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpOg17AZwPNF.pgp Description: PGP signature
Re: GELI file systems unusable after glabel label operations
On 1/14/10, Scott Bennett benn...@cs.niu.edu 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. Is there a way to get this to work? Or have I just lost everything in the encrypted file systems? hellas# geli attach -k work.key /dev/label/work geli: Cannot read metadata from /dev/label/work: Invalid argument. hellas# ls -lgF /dev/label/ total 0 crw-r- 1 root operator0, 192 Jan 14 00:47 archives crw-r- 1 root operator0, 191 Jan 14 00:47 backupsi crw-r- 1 root operator0, 182 Jan 14 00:47 backupsl crw-r- 1 root operator0, 166 Jan 14 00:47 backupss crw-r- 1 root operator0, 179 Jan 14 00:47 sec crw-r- 1 root operator0, 161 Jan 14 00:47 usrobj crw-r- 1 root operator0, 184 Jan 14 00:47 usrports crw-r- 1 root operator0, 186 Jan 14 00:47 vboxdisk crw-r- 1 root operator0, 181 Jan 14 00:47 work hellas# Any help in recovering the lost data would be deeply appreciated. If that cannot be done, then at least knowing that would keep me from wasting further time on it. Thanks much. Are you aware that tunefs -L will label a device? It is stored as part of the filesystem, instead as a GEOM metadata. So you should be able to get both labeling (/dev/ufs/labelname) and GELI as you are asking for. As for recovering your data, I see other helpful posts in this thread, as I have no additional helpful information to recommend. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Sat, 23 Jan 2010 02:34:31 +0100 Roland Smith rsm...@xs4all.nl wrote: On Fri, Jan 22, 2010 at 03:08:00AM -0600, Scott Bennett wrote: Why is that stored in the last sector of the device, rather than in the key file? What is the purpose of the key file if not to hold that type of information? The keyfile is user generated, usually just some bytes from /dev/random All geom(4) providers use their last sector to store metadata; it's a design decision. Probably because the first sector(s) are used for boot blocks or filesystem metadata etc. It would have been possible to store the generated key in the user-provided keyfile. But since it is not mandatory to have a keyfile (you can also use just a passphrase), it makes more sense to use the already provided metadata space in the last sector. Having it on the last sector allows the auto-detection of geli partitions. It would be nice to have the option of having the metadata in a separate metadata file instead of the last sector, to allow geli partitions to be indistinguishable from securely erased partitions. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Sat, Jan 16, 2010 at 12:38:14AM -0600, Scott Bennett wrote: 2) Create the geli device /dev/daXsYP.eli, and then create a label on that, yielding /dev/label/bar. [not sure what the utility of this is, since the label will only appear after the geil provider has been attached] The important point here is that one of the above methods must be used *before* the file system is created and the data loaded into it. Attempting either method *after* data are loaded will result in loss of the data. Maybe not immediately, but since both the filesystem and geom can use the last sector, there will be trouble. :-) The examples in the glabel manpage should how to set up a label correctly. Perhaps this provides a possible recovery method. As you read it, would it be possible to build an altered version of geli(8) that would simply use the existing key file without generating a new one to do a geli init operation? If so, it would certainly be worth my trouble to do that. In theory it is possible, I guess. But the salt is 512 bytes long. So it can have 2^512 different values. That is 1.340×10^154 different values, and you'd have to test them all. And by testing I mean use the modified 'geli init' to generate a key, and then try if the key works, i.e. check if the relevant sector decrypted with that key yields a valid UFS2 superblock. Suppose you wrote a program capable of testing 10^9 keys every second, which sounds like quite alot to me. It would still be running for 2^512/1e9/(3600*24*365) = 4.25×10^137 years! So in practice, this is a hopeless task. And I think that the proper way to nest geoms is too obvious (at least for = the developers/maintainers) to explicitly list in the handbook. If you know that geoms store metadata in their last sector, the proper way to nest them is to use the different devices for each geom stage, so that each has their own metadata sector. Well, it wasn't at all obvious to me, and reading the parts that mention metadata being written to the last sector suggests, if anything, that labeling and encryption are incompatible because both write to the last sector, i.e., to the *same* sector. The idea of the last sector being different for the two operations is not at all apparent. Well, it should be different, otherwise they overwrite the same sector. Ipso facto you should nest providers... Say you want to have a labeled, encrypted device on /dev/da0s1d. First, you create the label; glabel label ‐v foo /dev/da0s1d A device /dev/label/foo now appears. This device is one sector smaller than /dev/da0s1d, because the last sector of /dev/da0s1d is used for the glabel metadata. Now we want to create an encrypted device, so we do: geli init -l 256 /dev/label/foo geli attach /dev/label/foo This will create /dev/label/foo.eli. Again, /dev/label/foo.eli is one sector smaller than /dev/label/foo, because the last sector of /dev/label/foo contains the geli metadata. If one uses geli init -l 256 /dev/da0s1d geli attach /dev/da0s1d this will create and attach /dev/da0s1d.eli, but /dev/label/foo will be destroyed, because 'geli init' overwrites glabel's metadata! Below I've tried to sketch the last sectors of the device, with the extents of the geom-ed devices and the location of the metadata below. -- /dev/da0s1d ...N-5N-4N-3N-2 N-1N | | | | | | geli |glabel| -- /dev/label/foo --- /dev/label/foo.eli Nested geom devices are the only way to keep the metadata safe. Hope this helps, Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpWo80zoDjvn.pgp Description: PGP signature
Re: GELI file systems unusable after glabel label operations
On Fri, Jan 15, 2010 at 01:25:50AM -0600, Scott Bennett wrote:
It has been a long time since I created those GELI partitions, but I
think I used the geli init -K keyfilename /dev/daXsYP, where P is the
partition identifier in slice Y of drive X. What I did when I screwed the
pooch on this was of the form glabel label fsname /dev/daXsYP, which I had
thought would produce a /dev/label/fsname device and that doing a geli
attach
afterward would produce a /dev/label/fsname.eli device.
You could have done two things to create a nested label/geli configuration;
1) Create a labeled device from /dev/daXsYP, which would yield /dev/label/foo,
then create a geli device _on the labeled device_, creating
/dev/label/foo.eli. This will work because the labeled device will be one
sector shorter than the raw da device. The .eli device will be yet another
sector shorter, leaving two adjacent metadata sectors for the nested
providers. This is the key point.
2) Create the geli device /dev/daXsYP.eli, and then create a label on that,
yielding /dev/label/bar. [not sure what the utility of this is, since the
label will only appear after the geil provider has been attached]
The first one seems most useful for things like automatic mounting.
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.
Probably. I didn't see them when I was running 7.2, and I only noticed it in
the 8.0 manpage.
Running 'geli init' again with the same parameters will not work, because
'geli init' uses a random component in the key generation. In other words, =
two
inits with the same password will not generate the same key!
Is there some way to recover using the existing key files, which I do
still have? And of course, I do know the passphrases.
Not as I read the geli source. It _always_ uses arc4rand to generate a random
salt for the key during 'init'. Read the function 'static void eli_init(struct
gctl_req *req)' in /usr/src/sbin/geom/class/eli/geom_eli.c. This means that
subsequent 'geli init' calls with the same password or keyfile will still
yield a different key. I'm afraid your data is lost.
You should always make a backup before playing with filesystems. Most people
learn this the hard way, although I realize that this is small consolation.
What you should have done (for future refrence) is use geli(8) to create the
encrypted device, then create a filesystem on that encrypted device with
newfs(8) using the '-L' flag to set the volume name. Or use tunefs(8) to set
the volume name later. These names will be automatically recognized next ti=
me
you attach it and listed in /dev/ufs/.
Thank you for that information. If only it had been laid out that way
in the man page of the handbook when I read it before starting on the labeling
procedure...sigh.
It _is_ listed in the glabel manpage, at least in 8.0.
And I think that the proper way to nest geoms is too obvious (at least for the
developers/maintainers) to explicitly list in the handbook. If you know that
geoms store metadata in their last sector, the proper way to nest them is to
use the different devices for each geom stage, so that each has their own
metadata sector.
Procedure #1 that I outlined above should be easier to automate, should you
want to, because you can then just use 'geli init /dev/label/foo'.
As of 7.2, each UFS filesystem automatically has an unique file system id that
is automatically created during boot in /dev/ufsid. These labels are unique
and do not change. You can use those to mount these filesystems. See §19.6 in
the latest version of the Handbook.
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.
Since the partitions are encrypted, don't bother with gzip. Encrypted data is
pretty close to random noise. No compression program can compress that vey
much. With the gzip header, it might even become bigger.
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpT6c9Yiukp2.pgp
Description: PGP signature
Re: GELI file systems unusable after glabel label operations
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/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Fri, 15 Jan 2010 23:18:40 +0100 Roland Smith rsm...@xs4all.nl
wrote:
On Fri, Jan 15, 2010 at 01:25:50AM -0600, Scott Bennett wrote:
=20
It has been a long time since I created those GELI partitions, but I
think I used the geli init -K keyfilename /dev/daXsYP, where P is the
partition identifier in slice Y of drive X. What I did when I screwed the
pooch on this was of the form glabel label fsname /dev/daXsYP, which I =
had
thought would produce a /dev/label/fsname device and that doing a geli a=
ttach
afterward would produce a /dev/label/fsname.eli device.
You could have done two things to create a nested label/geli configuration;
1) Create a labeled device from /dev/daXsYP, which would yield /dev/label/f=
oo,
then create a geli device _on the labeled device_, creating
/dev/label/foo.eli. This will work because the labeled device will be one
sector shorter than the raw da device. The .eli device will be yet anoth=
er
sector shorter, leaving two adjacent metadata sectors for the nested
providers. This is the key point.
2) Create the geli device /dev/daXsYP.eli, and then create a label on that,
yielding /dev/label/bar. [not sure what the utility of this is, since the
label will only appear after the geil provider has been attached]
The important point here is that one of the above methods must be used
*before* the file system is created and the data loaded into it. Attempting
either method *after* data are loaded will result in loss of the data.
The first one seems most useful for things like automatic mounting.
Okay. Thanks for the two methods.
Check /var/backups. There should be *.eli files there. Those are the aut=
oma=3D
tic
=20
No joy. :-(
=20
metadata backups that 'geli init' makes (at least in 8.0). You can resto=
re
those backups with 'geli restore'.
=20
Those must be new in 8.0. I don't see any in 7.2, just {aliases,gro=
up,
master.passwd}.bak{,2} in /var/backups.
Probably. I didn't see them when I was running 7.2, and I only noticed it in
the 8.0 manpage.
Running 'geli init' again with the same parameters will not work, because
'geli init' uses a random component in the key generation. In other word=
s, =3D
two
inits with the same password will not generate the same key!
=20
Is there some way to recover using the existing key files, which I do
still have? And of course, I do know the passphrases.
Not as I read the geli source. It _always_ uses arc4rand to generate a rand=
om
salt for the key during 'init'. Read the function 'static void eli_init(str=
uct
gctl_req *req)' in /usr/src/sbin/geom/class/eli/geom_eli.c. This means that
subsequent 'geli init' calls with the same password or keyfile will still
yield a different key. I'm afraid your data is lost.
Perhaps this provides a possible recovery method. As you read it,
would it be possible to build an altered version of geli(8) that would simply
use the existing key file without generating a new one to do a geli init
operation? If so, it would certainly be worth my trouble to do that.
You should always make a backup before playing with filesystems. Most people
learn this the hard way, although I realize that this is small consolation.
As I wrote previously, I had backups. My error was in labeling both
the original partition *and* the partition containing the backup series at
the same time. If I hadn't tried to save a reboot and a few other trivial
operations and had instead labeled only the original data partition at first,
I would have discovered the problem in time to rebuild the original correctly
from the backups. Sigh.
What you should have done (for future refrence) is use geli(8) to create=
the
encrypted device, then create a filesystem on that encrypted device with
newfs(8) using the '-L' flag to set the volume name. Or use tunefs(8) to=
set
the volume name later. These names will be automatically recognized next=
ti=3D
me
you attach it and listed in /dev/ufs/.
Thank you for that information. If only it had been laid out that w=
ay
in the man page of the handbook when I read it before starting on the lab=
eling
procedure...sigh.
It _is_ listed in the glabel manpage, at least in 8.0.=20
I don't have 8.0.
And I think that the proper way to nest geoms is too obvious (at least for =
the
developers/maintainers) to explicitly list in the handbook. If you know that
geoms store metadata in their last sector, the proper way to nest them is to
use the different devices for each geom stage, so that each has their own
metadata sector.
Well, it wasn't at all obvious to me, and reading the parts that mention
metadata being written to the last sector suggests, if anything, that labeling
and encryption are incompatible because both write to the last sector, i.e.,
to the *same* sector. The idea of the last sector being different for the
two operations is not at all apparent.
Procedure #1 that I outlined above
Re: GELI file systems unusable after glabel label operations
On Thu, 14 Jan 2010 10:55:35 +0300 Boris Samorodov b...@ipt.ru wrote: Thanks so much for responding so fast! On Thu, 14 Jan 2010 01:31:55 -0600 (CST) Scott Bennett wrote: hellas# geli attach -k work.key /dev/label/work geli: Cannot read metadata from /dev/label/work: Invalid argument. Did you try to mount it via geom consumer (/dev/daX)? Um, no, a GELI-encrypted partition must first be attached. The attach operation fails, as shown above, so there's no way to mount it. Can you show apropriate glabel list? hellas# geom ELI list geom: Cannot get GEOM tree: Unknown error: -1 hellas# I'm afraid I'm clueless here. What should I try next? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * 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 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
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? 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. 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. 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Thu, 14 Jan 2010 10:30:00 +0100 Ivan Voras ivo...@freebsd.org wrote: 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 cs.niu.edu * ** * 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 * ** ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
Scott Bennett wrote: As noted above, that would not work because then the label would not be readable at boot time. Yes it would. What you would have is a nested configuration, geli within a label. The label would be read when the device is present, then you would be able to attach the geli device (probably as /dev/label/blah.geli, I didn't try it). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Thu, Jan 14, 2010 at 01:31:55AM -0600, 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. Is there a way to get this to work? Or have I just lost everything in the encrypted file systems? Did you use 'geli init /dev/daXsY' and 'glabel label /dev/daXsY'? That will overwrite the geli metadata with the glabel metadata! Check /var/backups. There should be *.eli files there. Those are the automatic metadata backups that 'geli init' makes (at least in 8.0). You can restore those backups with 'geli restore'. Running 'geli init' again with the same parameters will not work, because 'geli init' uses a random component in the key generation. In other words, two inits with the same password will not generate the same key! What you should have done (for future refrence) is use geli(8) to create the encrypted device, then create a filesystem on that encrypted device with newfs(8) using the '-L' flag to set the volume name. Or use tunefs(8) to set the volume name later. These names will be automatically recognized next time you attach it and listed in /dev/ufs/. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpHuSU1N8tAm.pgp Description: PGP signature
Re: GELI file systems unusable after glabel label operations
On Thu, 14 Jan 2010 18:42:32 +0100 Roland Smith rsm...@xs4all.nl
On Thu, Jan 14, 2010 at 01:31:55AM -0600, Scott Bennett wrote:
I used glabel label to label each of the file systems I have on ex=
ternal
disk drives. Unfortunately, afterward I am now unable to geli attach a=
ny of
the GELI-encrypted file systems. The system is FreeBSD 7.2-STABLE. Is t=
here
a way to get this to work? Or have I just lost everything in the encrypt=
ed
file systems?
Did you use 'geli init /dev/daXsY' and 'glabel label /dev/daXsY'? That will
overwrite the geli metadata with the glabel metadata!=20
It has been a long time since I created those GELI partitions, but I
think I used the geli init -K keyfilename /dev/daXsYP, where P is the
partition identifier in slice Y of drive X. What I did when I screwed the
pooch on this was of the form glabel label fsname /dev/daXsYP, which I had
thought would produce a /dev/label/fsname device and that doing a geli attach
afterward would produce a /dev/label/fsname.eli device.
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.
Running 'geli init' again with the same parameters will not work, because
'geli init' uses a random component in the key generation. In other words, =
two
inits with the same password will not generate the same key!
Is there some way to recover using the existing key files, which I do
still have? And of course, I do know the passphrases.
What you should have done (for future refrence) is use geli(8) to create the
encrypted device, then create a filesystem on that encrypted device with
newfs(8) using the '-L' flag to set the volume name. Or use tunefs(8) to set
the volume name later. These names will be automatically recognized next ti=
me
you attach it and listed in /dev/ufs/.
Thank you for that information. If only it had been laid out that way
in the man page of the handbook when I read it before starting on the labeling
procedure...sigh.
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.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at cs.niu.edu *
**
* 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 *
**
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: GELI file systems unusable after glabel label operations
On Thu, 14 Jan 2010 01:31:55 -0600 (CST) Scott Bennett wrote: hellas# geli attach -k work.key /dev/label/work geli: Cannot read metadata from /dev/label/work: Invalid argument. Did you try to mount it via geom consumer (/dev/daX)? Can you show apropriate glabel list? -- WBR, bsam ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
