what is in /etc/crypttab? (In reply to Harald Hoyer from comment #2) > what is in /etc/crypttab? You saw it couple of times already? matej@wycliff: ~$ sudo cat /etc/crypttab swap /dev/vg_wycliff/lv_swap none home /dev/vg_wycliff/lv_home none matej@wycliff: ~$ But meanwhile swap works again, so you probably are lucky. OK, reopening. Currently the situation is that with kernel as upgraded it doesn't boot up without me prior running 'dracut -f' on the command line as a root after the upgrade. Created attachment 846771 [details]
sosreport (just before upgrade)
Created attachment 847004 [details]
output of journalctl SYSLOG_IDENTIFIER=dracut (as root)
After upgrade
Created attachment 847005 [details]
/var/log/dracut
Created attachment 847007 [details]
/boot/initramfs-3.10.0-65.el7.x86_64.img (after upgrade before dracut -f)
wycliff:~# rpm -q kernel
kernel-3.10.0-60.el7.x86_64
kernel-3.10.0-64.el7.x86_64
kernel-3.10.0-65.el7.x86_64
wycliff:~#
Created attachment 848414 [details]
shot of the screen when the boot frozen
I have unfortunate development in the case. With kernel-3.10.0-65.el7.x86_64 and kernel-3.10.0-67.el7.x86_64 my trick with rebuilding initramfs doesn’t work anymore, and even after multiple rebuildings (I have checked everything thrice to be sure I haven’t screwed up anywhere). Unfortunately, I don’t know how to get journalctl when I have never got a prompt during the failed boot in the first place. Here is at least the shot of the screen in moment when it got frozen.
Created attachment 848416 [details]
/boot/initramfs-3.10.0-65.el7.x86_64.img (after upgrade after dracut -f)
Created attachment 848417 [details]
rdsosreport.txt
Created attachment 848418 [details]
/boot/logs/strace.txt
Created attachment 848419 [details]
output of ausearch -m AVC after the failed boot
Created attachment 848420 [details]
audit2allow processed of ausearch output
are you saying that older versions of dracut showed this problem, but rebuilding the initrd with dracut -f on these older kernels fixes it? If so, that's totally expected. "yum update" won't rebuild old initrds, it will only rebuild the initrd of new kernels (when those kernels get installed) (In reply to Ray Strode [halfline] from comment #17) > are you saying that older versions of dracut showed this problem, but > rebuilding the initrd with dracut -f on these older kernels fixes it? “fixed it” up until and including kernel -60. More recent versions of kernel are hopeless. > If so, that's totally expected. "yum update" won't rebuild old initrds, it > will only rebuild the initrd of new kernels (when those kernels get > installed) No, I haven’t meant rebuilding old initrds. I meant that even the kernel being upgraded was useless and I had to manually run dracut -f on it to get working initramfs? that's very strange, installing a new kernel causes dracut -f to get run "behind the scenes". maybe some selinux issue? (In reply to Ray Strode [halfline] from comment #19) > that's very strange, installing a new kernel causes dracut -f to get run > "behind the scenes". maybe some selinux issue? Not sure, how to reproduce it without further kernel update. I believe I have checked ausearch output, but not 100% certain. Let me know, when new kernel update happens. (In reply to Ray Strode [halfline] from comment #19) > that's very strange, installing a new kernel causes dracut -f to get run > "behind the scenes". maybe some selinux issue? Actually, attachment 848419 [details] and attachment 848420 [details] is the SELinux stuff. Created attachment 851510 [details]
journalctl -f when the installation happened
We have new kernel in the system, so I have managed to capture journalctl during it.
Also, ausearch -m AVC -ts <relevant-time> shows '<no matches>' Upgraded to dracut-033-84.el7.x86_64 and plymouth-0.8.9-0.3.20140113.el7.x86_64.rpm and this happened wycliff:~# dracut -f --kver=3.10.0-71.el7.x86_64 /usr/lib/dracut/modules.d/99base/dracut-lib.sh: line 1: !/bin/sh: No such file or directory wycliff:~# rpm -q dracuát package dracuát is not installed wycliff:~# rpm -q dracut wycliff:~# Actually with kernel-3.10.0-89.el7.x86_64 dracut-033-124.el7.x86_64 systemd-208-4.el7.x86_64 plymouth-0.8.9-0.2014.01.13.1.el7.x86_64 this seems to be working. Without any rebuilding mkinitrd I get the system booting again. Thanks! presumably a dupe of bug 1015564 then. *** This bug has been marked as a duplicate of bug 1015564 *** |
Description of problem: wycliff:~# systemctl restart systemd-cryptsetup Please enter passphrase for disk vg_wycliff-lv_swap (swap) on swap! ********* Job for systemd-cryptsetup failed. See 'systemctl status systemd-cryptsetup' and 'journalctl -xn' for details. wycliff:~# systemctl status systemd-cryptsetup systemd-cryptsetup - Cryptography Setup for swap Loaded: loaded (/etc/crypttab) Active: failed (Result: exit-code) since Sat 2013-10-05 08:09:54 CEST; 1min 31s ago Docs: man:systemd-cryptsetup@.service(8) man:crypttab(5) Process: 618 ExecStop=/usr/lib/systemd/systemd-cryptsetup detach swap (code=killed, signal=TERM) Process: 2745 ExecStart=/usr/lib/systemd/systemd-cryptsetup attach swap /dev/vg_wycliff/lv_swap none (code=exited, status=1/FAILURE) Main PID: 2745 (code=exited, status=1/FAILURE) Oct 05 08:09:46 wycliff.ceplovi.cz systemd[1]: Starting Cryptography Setup for swap... Oct 05 08:09:53 wycliff.ceplovi.cz systemd-cryptsetup[2745]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/vg_wycliff/lv_swap. Oct 05 08:09:54 wycliff.ceplovi.cz systemd[1]: systemd-cryptsetup: main process exited, code=exited, status=1/FAILURE Oct 05 08:09:54 wycliff.ceplovi.cz systemd[1]: Failed to start Cryptography Setup for swap. Oct 05 08:09:54 wycliff.ceplovi.cz systemd[1]: Unit systemd-cryptsetup entered failed state. wycliff:~# Version-Release number of selected component (if applicable): systemd-207-2.el7.x86_64 How reproducible: Happened now, but so far I haven't been able to start swap at all. Steps to Reproduce: 1.see above 2. 3. Actual results: no swap Expected results: swap should be set on and working using encrypted storage Additional info: