Description of problem: Installation of an encrypted filesystem works perfectly on the DVD. Upon reboot to an installed system, the passhphrases seems to be ignored or we have data interfering with the input. This seems to be related to the hvc0 console. But again, it works perfectly on the install media including booting into rescue mode. Version-Release number of selected component (if applicable): 1007-respin and earlier How reproducible: Install off 1007-respin and encrypt a filesystem like /home systemd-fsck[397]: /dev/sda2: clean, 22/128016 files, 67122/512000 blocks Starting Forward Password Requests to Plymouth... Started Forward Password Requests to Plymouth. Started File System Check on /dev/disk/by-uuid/fb993e12-bc34-4e80-9ea1-50afdc1f541a. Starting /boot... Please enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ed) on /home!:[ 4.120385] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) Started /boot. [ 4.236496] fedora-storage-init[425]: Setting up Logical Volume Management: No volume groups found [ 4.243392] fedora-storage-init[425]: [ OK ] Started Initialize storage subsystems (RAID, LVM, etc.). Please enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ePlease enter passphrase for disk VDASD (luks-103c7200-8144-4b1e-b4b1-d00e02f1b7ed) on /home!:******** [ 52.240673] systemd-tty-ask-password-agent[432]: Failed to query password: Input/output error [ 52.240692] systemd-tty-ask-password-agent[432]: Failed to show password: Input/output error
does this work if you disable plymouth? try booting with "plymouth.enable=0" and "rd_NO_PLYMOUTH" on the kernel cmdline.
Lennart, disabling plymouth with both of those does not impact it.
@Lennart: If you need a PPC machine with console access for debugging, I might be able to configure one for you
(In reply to comment #3) > @Lennart: If you need a PPC machine with console access for debugging, I might > be able to configure one for you yes, please :-)
Created attachment 528040 [details] /bin/systemd-tty-ask-password-agent strace I entered the wrong password "nopasshase", but the interesting thing is: access("/run/systemd/ask-password/ask.tO5zHE", F_OK) = 0 poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}], 2, 89744) = 1 ([{fd=9, revents=POLLIN}]) read(9, "\5", 2048) = 1 open("/proc/self/maps", O_RDONLY) = 10 fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfff7d180000 read(10, "10000000-10020000 r-xp 00000000 "..., 1024) = 1024 close(10) = 0 munmap(0xfff7d180000, 4096) = 0 write(9, "*\2]Please enter passphrase for d"..., 96) = 96 access("/run/systemd/ask-password/ask.tO5zHE", F_OK) = 0 poll([{fd=9, events=POLLIN}, {fd=8, events=POLLIN}], 2, 89743) = 1 ([{fd=9, revents=POLLIN}]) read(9, "\2\n\0\0\0nopasshase", 2048) = 15 close(8) = 0 close(9) = 0 writev(2, [{"Failed to query password: Input/"..., 44}, {"\n", 1}], 2Failed to query password: Input/output error ) = 45 close(7) = 0 munmap(0xfff7d4a0000, 65536) = 0 getdents(6, /* 0 entries */, 32768) = 0 close(6) = 0 writev(2, [{"Failed to show password: Input/o"..., 43}, {"\n", 1}], 2Failed to show password: Input/output error ) = 44
Is "\2\n\0\0\0nopasshase" a correct answer from plymouth?? I also had to add "console=hvc0" to the kernel command line, so that the plymouth message/question is displayed.
Hmm, so what we expect to read is a byte with value 2, followed by a 32bit length value followed by one or more strings separated by NUL, not necessarily terminated by NUL. From a first peek this appears to look right. But there might be an LE/BE issue here. The systemd side expects NE. Let's see what Ply sends.
hmm, so yupp, seems ply is enforcing LE order for the proto, and systemd doesn't do any conversion. But I guess it should.
http://cgit.freedesktop.org/systemd/commit/?id=bb53abeb8c3407ea250be69bc43510b03c0df3da Would be great if someone with a BE systemd could test this.
We'll give it a shot, Lennart and post results here as soon as we tested it. Thanks! Regards, Phil
The updated systemd with the endian patch fixed the problem. As someone noted, you have to pass the proper console= or you will not get prompted for the passphrase. We're looking into that now.
Does the system have a graphics device, and thus normal ttys? If so - the kernel defaults to putting the console on the graphical devices, unless you tell it otherwise by saying 'console=XXX'. So that would seem to be the expected behavior.
No graphics card.
Okay, I've discussed a bit with the plymouth maintainer - there's some bugs/shortcomings of the F16 plymouth that keep it from requesting the password on /dev/hvc0 *unless* 'console=hvc0' is passed. That bug probably won't get fixed for F16, so the plan is to make anaconda set 'console=hvc0' (as it apparently did in RHEL6 and earlier), which should solve the problem. That's bug 758530.
http://wwoods.fedorapeople.org/iso/Fedora-16-ppc64-netinst-20111130.iso has a proposed fix for bug 758530 (and thus this bug too). Could someone test that out?
systemd-37-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-6.fc16
Package systemd-37-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16 then log in and leave karma (feedback).
Package systemd-37-7.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-7.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-7.fc16 then log in and leave karma (feedback).
Package systemd-37-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16 then log in and leave karma (feedback).
Package systemd-37-10.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-10.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-10.fc16 then log in and leave karma (feedback).
Package systemd-37-11.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-11.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-11.fc16 then log in and leave karma (feedback).
systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.