search for: keystatus

Author: Darren Moffat <darrenm at opensolaris.org> Repository: /hg/zfs-crypto/gate Latest revision: 4c9597e1e4e9b6cbd6c20be06f0cdf9c409d3629 Total changesets: 1 Log message: 885 dataset creation panics if pool keystatus not ''available''. 360 check for key on creation should be in dmu_objset_create_check() 782 zfs keysource=raw fails with keyscope=dataset when file doesn''t exist Files: update: usr/src/lib/libzfs/common/libzfs_crypto.c update: usr/src/lib/libzfs/common/libzfs_dataset.c...

...l''for_each_pool+0x39 zpool''zpool_do_key+0x1a4 zpool''main+0x138 zpool''_start+0x7a Abort (core dumped) -bash-3.2$ zpool get keysource pool_105153_2 NAME PROPERTY VALUE SOURCE pool_105153_2 keysource hex,prompt default -bash-3.2$ zpool get keystatus pool_105153_2 NAME PROPERTY VALUE SOURCE pool_105153_2 keystatus undefined default -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

...hidden per dataset property key_check would be undefined). The big concern I have with this is how it looks to the user/admin when looking at the properties and the steps they have to take. After step 2 but before step 3 they would likely see: encryption=on keytype=dataset kek=passphrase keystatus=undefined Example 2: A similar case with the same issue is this one: 1$ zfs create -o encryption=on -o keytype=dataset tank/foo 2$ zfs key -l tank/foo Enter new passphrase: Re-Enter passphrase: 3$ zfs mount tank/foo Some discussion that Tony and I had recently I think we came to the conc...

...hidden per dataset property key_check would be undefined). The big concern I have with this is how it looks to the user/admin when looking at the properties and the steps they have to take. After step 2 but before step 3 they would likely see: encryption=on keytype=dataset kek=passphrase keystatus=undefined Example 2: A similar case with the same issue is this one: 1$ zfs create -o encryption=on -o keytype=dataset tank/foo 2$ zfs key -l tank/foo Enter new passphrase: Re-Enter passphrase: 3$ zfs mount tank/foo Some discussion that Tony and I had recently I think we came to the conc...

...tml DEA-12: Typo: safety 3152 * This probably isn''t needed but it is a useful saftey net. ------------------------------------------------------------------ usr/src/uts/common/fs/zfs/sys/zio_crypt.h.html DEA-13 Typos partially persistent, appropriate, converted, value: 84 * keystatus is partialy persitent and partially temporary. 86 * If the on disk state is defined we return the appopriate "in memory" 131 * The userland passphrase was convered to a key using PKCS#5 PBE 143 * zic_keydata is the PIN valule Period needed at end of line 119 (to...

http://defect.opensolaris.org/bz/show_bug.cgi?id=752 Summary: zfs set keysource no longer works on existing pools Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: blocker Priority: P1 Component: other AssignedTo:

Looking for help regaining access to encrypted ZFS file systems that stopped accepting the encryption key. I have a file server with a setup as follows: Solaris 11 Express 1010.11/snv_151a 8 x 2-TB disks, each one divided into three equal size partitions, three raidz3 pools built from a "slice" across matching partitions: Disk 1 Disk 8 zpools +--+ +--+ |p1| .. |p1| <-

...ub\i386-efi\iorw.mod (2.9 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\iso9660.mod (8.7 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\jfs.mod (6.1 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\jpeg.mod (6.2 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\keylayouts.mod (5.0 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\keystatus.mod (2 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\ldm.mod (6.6 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\legacy_password_test.mod (14.2 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\legacycfg.mod (30.3 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\linux16.mod (8 KB) Extracting: F:\EFI\BOOT\grub\i386-efi\lin...

On 3/3/2016 07:43, Pete Batard via Syslinux wrote: > [...] as far as I am concerned, 'A "version" such as "6.03" [is not] > enough'. [...] I'd like to help to improve Syslinux with regards to version-related concerns. Having typed that, perhaps we could discuss your (or Rufus') specific needs, in parallel? Do I understand correctly that the primary