Description of problem: Running the QA:Testcase partitioning guided encrypted Beta test with the FC21 Alpha RC3 ISO image. I was able to select the "Encrypt my data" checkbox, then provide a disk encryption passphrase. After reclaiming some space on the disk and begin the installation, I got "An unknown error has occured" message box. Version-Release number of selected component: anaconda-21.48.11-1 The following was filed automatically by anaconda: anaconda 21.48.11-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devicelibs/crypto.py", line 103, in luks_format raise CryptoError("luks_format failed for '%s'" % device) File "/usr/lib/python2.7/site-packages/blivet/formats/luks.py", line 239, in create min_entropy=self.min_luks_entropy) File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 560, in execute options=self.device.formatArgs) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 361, in processActions action.execute(callbacks) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 364, in doIt self.devicetree.processActions(callbacks) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 216, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 190, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run threading.Thread.run(self, *args, **kwargs) CryptoError: luks_format failed for '/dev/sda3' Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: BOOT_IMAGE=/ppc/ppc64/vmlinuz ro executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.17.0-301.fc21.ppc64 product: Fedora" release: Cannot get release name. type: anaconda version: Fedora
Created attachment 953606 [details] File: anaconda-tb
Created attachment 953607 [details] File: anaconda.log
Created attachment 953608 [details] File: environ
Created attachment 953609 [details] File: lsblk_output
Created attachment 953610 [details] File: nmcli_dev_list
Created attachment 953611 [details] File: os_info
Created attachment 953612 [details] File: program.log
Created attachment 953613 [details] File: storage.log
Created attachment 953614 [details] File: syslog
Created attachment 953615 [details] File: ifcfg.log
Created attachment 953616 [details] File: packaging.log
*** Bug 1148513 has been marked as a duplicate of this bug. ***
The luks_format blivet's function calls libcyptsetup's crypt_format function which in this case returned -5 ('rc: -5' in the anaconda-tb file). The docs for the crypt_format function say: @returns @e 0 on success or negative errno value otherwise. and errno 5 is: #define EIO 5 /* I/O error */ So the traceback seems to have been triggered by an I/O error caused by the underlying (probably failing) hardware. I'm closing this as NOTABUG because that's nothing Anaconda or python-blivet could do something about. If the problem appears again and is reproducible please reopen this bug.
Created attachment 954863 [details] logs files Still have this problem on a FC21 Beta RC1 ISO image to be installed on a qemu guest ppc64le. As is a guest, I doubt the hardware is in the loop. qemu.ppc64 2:2.0.0-5.fc21
switching to cryptsetup per comment #13 Jakub will try reproduce the error by creating an encrypted device on freshly installed f21 system.
What is output of 'getconf PAGE_SIZE' on the test system? If the answer is anything >= 32KiB, then I suspect this known kernel bug fixed in 3.18-rc1 with e2cffb5f493a8b431dc87124388ea59b79f0bccb
(In reply to Dan Horák from comment #15) > Jakub will try reproduce the error by creating an encrypted device on > freshly installed f21 system. If so, please attach debug output (with cryptsetup binary add --debug, if blivet uses libcryptsetup/python wrapper, it should be able to use debugLevel(pycryptsetup.CRYPT_DEBUG_ALL); to provide more info
Hello everyone. I just tested cryptsetup on a clean F21 installation (PPC64) and the result is: [root@test ~]# cryptsetup --verbose --cipher "aes-cbc-essiv:sha256" --key-size 256 --verify-passphrase luksFormat /dev/sda2 --debug # cryptsetup 1.6.6 processing "cryptsetup --verbose --cipher aes-cbc-essiv:sha256 --key-size 256 --verify-passphrase luksFormat /dev/sda2 --debug" # Running command luksFormat. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. WARNING! ======== This will overwrite data on /dev/sda2 irrevocably. Are you sure? (Type uppercase yes): YES # Allocating crypt device /dev/sda2 context. # Trying to open and read device /dev/sda2. # Initialising device-mapper backend library. # Timeout set to 0 miliseconds. # Iteration time set to 1000 miliseconds. # Interactive passphrase entry requested. Enter passphrase: Verify passphrase: # Formatting device /dev/sda2 as type LUKS1. # Crypto backend (gcrypt 1.6.1) initialized. # Detected kernel Linux 3.17.1-302.fc21.ppc64p7 ppc64. # Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes. # Checking if cipher aes-cbc-essiv:sha256 is usable. # Using userspace crypto wrapper to access keyslot area. # Releasing crypt device /dev/sda2 context. # Releasing device-mapper backend. # Unlocking memory. Command failed with code 5: Input/output error
Created attachment 955036 [details] cryptsetup-strace.txt
So, # Detected kernel Linux 3.17.1-302.fc21.ppc64p7 ppc64. ... # Using userspace crypto wrapper to access keyslot area. unless the kernel contains patch mentioned by Ondra in comment #16, this cannot work. Cryptsetup detects if userspace crypto API is available, but it cannot detect that it is completely broken (which it is without that patch ;-) I think that the best is to backport patch e2cffb5f493a8b431dc87124388ea59b79f0bccb into Fedora PPC kernel. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/crypto/algif_skcipher.c?id=e2cffb5f493a8b431dc87124388ea59b79f0bccb (Can anyone please verity it fixes the problem? I do not have PPC arch available.)
(The previous cryptsetup version will work because kernel userspace crypto wrapper for LUKS was added now. It will fallback to old temporary device way but not if kernel pretends API is available but in fact it is broken...)
Hello, (just for the record, without proposed patch) tested on fresh F21 Beta ppc64le, same result as comment #18. kernel 3.17.1-302.fc21.ppc64le PAGE_SIZE = 64k...
Building kernel-3.18-rc3 ...
The kernel build fails on PPC64: --------------------------------- + make -s ARCH=powerpc V=1 -j16 modules In file included from sound/ppc/pmac.h:25:0, from sound/ppc/awacs.c:29: sound/ppc/awacs.c: In function 'snd_pmac_awacs_init': include/sound/control.h:212:2: warning: 'master_vol' may be used uninitialized in this function [-Wmaybe-uninitialized] return _snd_ctl_add_slave(master, slave, 0); ^ sound/ppc/awacs.c:886:23: note: 'master_vol' was declared here struct snd_kcontrol *master_vol, *speaker_vol; ^ fs/gfs2/dir.c: In function 'get_first_leaf': fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, bh_out); ^ fs/gfs2/dir.c: In function 'dir_split_leaf.isra.15': fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized] error = get_leaf(dip, leaf_no, &obh); ^ net/bridge/netfilter/nft_reject_bridge.c: In function 'nft_reject_br_send_v6_unreach': net/bridge/netfilter/nft_reject_bridge.c:240:3: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration] csum_ipv6_magic(&nip6h->saddr, &nip6h->daddr, ^ cc1: some warnings being treated as errors scripts/Makefile.build:263: recipe for target 'net/bridge/netfilter/nft_reject_bridge.o' failed make[3]: *** [net/bridge/netfilter/nft_reject_bridge.o] Error 1 make[3]: *** Waiting for unfinished jobs.... scripts/Makefile.build:402: recipe for target 'net/bridge/netfilter' failed make[2]: *** [net/bridge/netfilter] Error 2 scripts/Makefile.build:402: recipe for target 'net/bridge' failed make[1]: *** [net/bridge] Error 2 make[1]: *** Waiting for unfinished jobs.... Makefile:936: recipe for target 'net' failed make: *** [net] Error 2 make: *** Waiting for unfinished jobs.... drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer not defined for this architecture. [-Wcpp] #warning Precise timer not defined for this architecture. ^ drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf': drivers/infiniband/hw/ehca/ehca_mrmw.c:1907:6: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wmaybe-uninitialized] if (pgaddr - PAGE_SIZE != *prev_pgaddr) { ^ drivers/infiniband/hw/ehca/ehca_mrmw.c:1924:14: note: 'prev_pgaddr' was declared here u64 pgaddr, prev_pgaddr; ^ drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_reg_mr': drivers/infiniband/hw/ehca/ehca_mrmw.c:2430:5: warning: 'hret' may be used uninitialized in this function [-Wmaybe-uninitialized] if (hret == H_SUCCESS) ^ drivers/infiniband/hw/ehca/ehca_mrmw.c:2413:6: note: 'hret' was declared here u64 hret, *kpage; ^ drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom': drivers/net/ethernet/broadcom/tg3.c:12059:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(buf, &start, 4); ^ drivers/net/wireless/cw1200/wsm.c: In function 'wsm_handle_rx': drivers/net/wireless/cw1200/wsm.c:1457:2: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] return ret; ^ + exit 1
(In reply to Milan Broz from comment #20) > So, > # Detected kernel Linux 3.17.1-302.fc21.ppc64p7 ppc64. > ... > # Using userspace crypto wrapper to access keyslot area. > > unless the kernel contains patch mentioned by Ondra in comment #16, > this cannot work. > > Cryptsetup detects if userspace crypto API is available, > but it cannot detect that it is completely broken > (which it is without that patch ;-) > > I think that the best is to backport patch > e2cffb5f493a8b431dc87124388ea59b79f0bccb > into Fedora PPC kernel. > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/crypto/ > algif_skcipher.c?id=e2cffb5f493a8b431dc87124388ea59b79f0bccb > > (Can anyone please verity it fixes the problem? I do not have PPC arch > available.) Ahoj Milane, yes, we can include the backport in the Fedora kernels. Do you know what kernel versions are affected? 3.17 only?
(In reply to Dan Horák from comment #25) > yes, we can include the backport in the Fedora kernels. Do you know what > kernel versions are affected? 3.17 only? I think all kernels (probably other archs too) using >= 64k page and which provides crypto algif_skcipher interface. I would say, patch all archs in all supported kernels... (IOW: this interface never worked properly with large pages.) It should go into stable@kernel queue anyway.
(In reply to Jaromír Cápík from comment #24) > net/bridge/netfilter/nft_reject_bridge.c: In function > 'nft_reject_br_send_v6_unreach': > net/bridge/netfilter/nft_reject_bridge.c:240:3: error: implicit declaration > of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration] > csum_ipv6_magic(&nip6h->saddr, &nip6h->daddr, > ^ > cc1: some warnings being treated as errors > scripts/Makefile.build:263: recipe for target > 'net/bridge/netfilter/nft_reject_bridge.o' failed > make[3]: *** [net/bridge/netfilter/nft_reject_bridge.o] Error 1 a patch [1] for this error is floating around, but can't see where it is going to be merged [1] http://thread.gmane.org/gmane.linux.kernel/1824400
Back (In reply to Milan Broz from comment #26) > (In reply to Dan Horák from comment #25) > > yes, we can include the backport in the Fedora kernels. Do you know what > > kernel versions are affected? 3.17 only? > > I think all kernels (probably other archs too) using >= 64k page and which > provides crypto algif_skcipher interface. > I would say, patch all archs in all supported kernels... > I sent the patch to stable with request for inclusion to 3.17 & co.
Patch landed in 3.17.x http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/commit/?id=c772a7266f82062834eb96723ea80bbf5b912ac9 so I suppose it'll be in 3.17.3 release. Also it's been accepted for all other longterm 3.x kernels.
*** Bug 1164059 has been marked as a duplicate of this bug. ***
Proposed as a Blocker for 21-final by Fedora user sharkcz using the blocker tracking app because: This kernel deficiency breaks encrypted installs on systems with page size > 4k (ppc*, aarch64), will be fixed in 3.17.3 kernel.
switching to correct component (kernel)
We already grabbed this patch for Fedora.
kernel-3.17.3-300.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kernel-3.17.3-300.fc21
Package kernel-3.17.3-300.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.17.3-300.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15159/kernel-3.17.3-300.fc21 then log in and leave karma (feedback).
kernel-3.17.3-300.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Another user experienced a similar problem: Trying to use encrypted volumes on SW RAID 1 devices addons: com_redhat_kdump cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=/distrotrees/68727/initrd method=http://download-01.eng.brq.redhat.com/pub/fedora/releases/21/Server/x86_64/os/ repo=http://download-01.eng.brq.redhat.com/pub/fedora/releases/21/Server/x86_64/os/ BOOT_IMAGE=/distrotrees/68727/kernel hashmarkername: anaconda kernel: 3.17.4-301.fc21.x86_64 package: anaconda-21.48.21-1 product: Fedora" reason: CryptoError: luks_format failed for '/dev/md/swap' release: Cannot get release name. version: Fedora