Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
reopen 768314 reassign 768314 systemd tags 768314 + help thanks It would be very nice, if concerned people could test systemd from experimental with a cryptsetup, so the patches could be maybe backported into jessie. (reopening since this bug is closed and reassigning to systemd, since that's currently the scope within which this problem could be solved IMHO) *t On Wed, 7 Jan 2015, Tomas Pospisek wrote: Thanks Zbigniew Kjetil and Christian is it possible for you to test this? *t On Wed, 7 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jan 06, 2015 at 06:56:11PM +0100, Tomas Pospisek wrote: Hello Zbigniew, I was told on IRC in #debian-systemd: mbiebl_ tpo, I remember Zbigniew had a patch without wanting to stress anybody: could you maybe tell me what the status of that patch is? Are you considering it ready for inclusion in Debian's systemd? Is it possible that it would be ready and included prior to jessie's release? systemd git should now avoid output when waiting for the password. IIRC, my initial patch was followed up by a few cleanups, so it might not be very backportable, but latest systemd in experimental should have all the changes. I'd suggest that you test if that version works for you. Zbyszek
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
Hello Kjetil, On Wed, 7 Jan 2015, Kjetil Kjernsmo wrote: On Wednesday 7. January 2015 08.23.32 Tomas Pospisek wrote: Kjetil and Christian is it possible for you to test this? As of now, I only have my laptop to test Jessie, which is something I use every day, and so I'm anxious about putting such an important thing as systemd from experimental on it. I've had the ambition to be able to easily set up virtual hosts for these occasions for a long time, but alas, ENOTIME. well, this is quite demotivating. I am not concerned by the cryptosetup problem, I just wanted to help make the upgrade to the coming release better for people that are using crypted partitions. But lets see, whether you're maybe able to contribute just a tiny bit - Other than dropping the effort to try to improve on this particular problem I see two ways forward: a) you could test on your computer and I help you a bit b) I could test on my computer and you help me a bit ab=c) we could both test Let's see a) You can do: # apt-get install lxc # lxc-create -n test_VM -t debian -- -r jessie This will create a VM under /var/lib/lxc/test_VM, that you can easilly remove later with # rm -r /var/lib/lxc/test_VM You can start the VM with: # lxc-start -n test_VM If you go and do something different while lxc-create is downloading its stuff, the whole thing takes about 1 minute of your time. After that you can set up the crypted device and install systemd from experimental inside and see whether it works. Now way forward b) == Could you tell me how to quickly set up a crypt device? Please let me know what you think, greetings, *t -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
On Wednesday 7. January 2015 08.23.32 Tomas Pospisek wrote: Kjetil and Christian is it possible for you to test this? As of now, I only have my laptop to test Jessie, which is something I use every day, and so I'm anxious about putting such an important thing as systemd from experimental on it. I've had the ambition to be able to easily set up virtual hosts for these occasions for a long time, but alas, ENOTIME. Cheers, Kjetil
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
On Tue, Jan 06, 2015 at 06:56:11PM +0100, Tomas Pospisek wrote: Hello Zbigniew, I was told on IRC in #debian-systemd: mbiebl_ tpo, I remember Zbigniew had a patch without wanting to stress anybody: could you maybe tell me what the status of that patch is? Are you considering it ready for inclusion in Debian's systemd? Is it possible that it would be ready and included prior to jessie's release? systemd git should now avoid output when waiting for the password. IIRC, my initial patch was followed up by a few cleanups, so it might not be very backportable, but latest systemd in experimental should have all the changes. I'd suggest that you test if that version works for you. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
Thanks Zbigniew Kjetil and Christian is it possible for you to test this? *t On Wed, 7 Jan 2015, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Jan 06, 2015 at 06:56:11PM +0100, Tomas Pospisek wrote: Hello Zbigniew, I was told on IRC in #debian-systemd: mbiebl_ tpo, I remember Zbigniew had a patch without wanting to stress anybody: could you maybe tell me what the status of that patch is? Are you considering it ready for inclusion in Debian's systemd? Is it possible that it would be ready and included prior to jessie's release? systemd git should now avoid output when waiting for the password. IIRC, my initial patch was followed up by a few cleanups, so it might not be very backportable, but latest systemd in experimental should have all the changes. I'd suggest that you test if that version works for you. Zbyszek
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
Hello Zbigniew, I was told on IRC in #debian-systemd: mbiebl_ tpo, I remember Zbigniew had a patch without wanting to stress anybody: could you maybe tell me what the status of that patch is? Are you considering it ready for inclusion in Debian's systemd? Is it possible that it would be ready and included prior to jessie's release? *t On Sat, 3 Jan 2015, Tomas Pospisek wrote: Hello systemd maintainers Laurent, bug #768314 [0] has been reassigned to the release-notes. It's about a user not being able to enter his cryptsetup password. A solution seems to be to install plymouth. It seems, that's a known problem, as noted in your titanpad [1]. However I could not find a respective issue in the BTS entries for systemd [2] - is there one that tracks this problem? Do you have any idea how this problem should be resolved for jessie? The original owner of the bug report suggests raising plymouth to a Recommends dependency. I suggested that systemd could recognize that there are mounted crypted partitions and suggest to the user to install plymouth at postinst time. Another workaround would be to just document the problem in the release notes and hope users won't run into it. Do you see or prefer any other approach? Second question: in the titanpad entry you write The plan with plymouth 0.9.0-9 is to not require any modification to the kernel cmdline and enable the I/O multiplexing functionality by default when the pkg is installed. As far as I can see from the plymouth changelog [3] no solution was implemented for this problem [4] in 0.9.0-9 and there hasn't been any activity in that bug report since Nov 14th. What's the current goal/aim wrt that bug? Thanks, *t [0] https://bugs.debian.org/768314 [1] https://debian.titanpad.com/23? [2] http://bugs.debian.org/systemd [3] http://metadata.ftp-master.debian.org/changelogs//main/p/plymouth/plymouth_0.9.0-9_changelog [4] https://bugs.debian.org/768329 @bugs.debian.org -- Forwarded message -- Date: Tue, 30 Dec 2014 23:11:58 +0100 From: Jonas Meurer jo...@freesources.org To: Tomas Pospisek t...@sourcepole.ch, 768...@bugs.debian.org Cc: Kjetil Kjernsmo kje...@kjernsmo.net Subject: Re: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping Hi Tomas, thanks for taking care of the bugreport. Am 30.12.2014 um 19:27 schrieb Tomas Pospisek: Hello Jonas Kjetil, (context: I'm reading through release-notes bug reports). I'm not sure I understand what you are expecting as a result by cloning/reassigning this to the release notes - Let me try to understand the problem: * if there's an encrypted partition, then systemd, who aparently would be responsible to do so will not prompt for the password, if plymouth is not installed. Is my understanding of the problem correct? Yes. Actually, it is even more complicated, but your understanding is correct: Systemd includes its own dm-crypt/cryptsetup device unlocking functions. With systemd as init system, it processes all dm-crypt encrypted devices that shall be unlocked during the boot process and *after* initramfs. I don't know systemd, but from the bugreports I learned that it apparently doesn't implement a proper mechanism to prompt for user input itself. Instead it relies on plymouth doing that task. As a result, systemd without plymouth doesn't wait for user input at unlocking dm-crypt devices but instead continues to print boot logging output to the console. So I think the right thing to do would be, that during the upgrade the systemd postinstallation should check whether there are some mounted partitions that are crypted and then recommend to install plymouth. Do you concur? I would even go futher and say that systemd should recommend plymouth in any case. Still, if it's only recommended and not a hard dependency, the discovered behaviour should be documented in the release notes in my eyes. Otherwise, should the release-notes recommend to install plymouth to the user if s/he has crypted partitions that should get mounted during boot? Yes, that's what needs to be done at least. Ideally IMHO the release notes should also explain the problem in sufficient technical detail to allow the user to take his own steps to further understand the problem and to choose an alternative solution if he deems so. Optimally you could suggest a wording? Unfortunately I've not enough knowledge about systemd to propose a wording. But feel free to use anything I wrote in the bugreport for a draft. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping (fwd)
Hello systemd maintainers Laurent, bug #768314 [0] has been reassigned to the release-notes. It's about a user not being able to enter his cryptsetup password. A solution seems to be to install plymouth. It seems, that's a known problem, as noted in your titanpad [1]. However I could not find a respective issue in the BTS entries for systemd [2] - is there one that tracks this problem? Do you have any idea how this problem should be resolved for jessie? The original owner of the bug report suggests raising plymouth to a Recommends dependency. I suggested that systemd could recognize that there are mounted crypted partitions and suggest to the user to install plymouth at postinst time. Another workaround would be to just document the problem in the release notes and hope users won't run into it. Do you see or prefer any other approach? Second question: in the titanpad entry you write The plan with plymouth 0.9.0-9 is to not require any modification to the kernel cmdline and enable the I/O multiplexing functionality by default when the pkg is installed. As far as I can see from the plymouth changelog [3] no solution was implemented for this problem [4] in 0.9.0-9 and there hasn't been any activity in that bug report since Nov 14th. What's the current goal/aim wrt that bug? Thanks, *t [0] https://bugs.debian.org/768314 [1] https://debian.titanpad.com/23? [2] http://bugs.debian.org/systemd [3] http://metadata.ftp-master.debian.org/changelogs//main/p/plymouth/plymouth_0.9.0-9_changelog [4] https://bugs.debian.org/768329 @bugs.debian.org -- Forwarded message -- Date: Tue, 30 Dec 2014 23:11:58 +0100 From: Jonas Meurer jo...@freesources.org To: Tomas Pospisek t...@sourcepole.ch, 768...@bugs.debian.org Cc: Kjetil Kjernsmo kje...@kjernsmo.net Subject: Re: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping Hi Tomas, thanks for taking care of the bugreport. Am 30.12.2014 um 19:27 schrieb Tomas Pospisek: Hello Jonas Kjetil, (context: I'm reading through release-notes bug reports). I'm not sure I understand what you are expecting as a result by cloning/reassigning this to the release notes - Let me try to understand the problem: * if there's an encrypted partition, then systemd, who aparently would be responsible to do so will not prompt for the password, if plymouth is not installed. Is my understanding of the problem correct? Yes. Actually, it is even more complicated, but your understanding is correct: Systemd includes its own dm-crypt/cryptsetup device unlocking functions. With systemd as init system, it processes all dm-crypt encrypted devices that shall be unlocked during the boot process and *after* initramfs. I don't know systemd, but from the bugreports I learned that it apparently doesn't implement a proper mechanism to prompt for user input itself. Instead it relies on plymouth doing that task. As a result, systemd without plymouth doesn't wait for user input at unlocking dm-crypt devices but instead continues to print boot logging output to the console. So I think the right thing to do would be, that during the upgrade the systemd postinstallation should check whether there are some mounted partitions that are crypted and then recommend to install plymouth. Do you concur? I would even go futher and say that systemd should recommend plymouth in any case. Still, if it's only recommended and not a hard dependency, the discovered behaviour should be documented in the release notes in my eyes. Otherwise, should the release-notes recommend to install plymouth to the user if s/he has crypted partitions that should get mounted during boot? Yes, that's what needs to be done at least. Ideally IMHO the release notes should also explain the problem in sufficient technical detail to allow the user to take his own steps to further understand the problem and to choose an alternative solution if he deems so. Optimally you could suggest a wording? Unfortunately I've not enough knowledge about systemd to propose a wording. But feel free to use anything I wrote in the bugreport for a draft. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hello Jonas Kjetil, (context: I'm reading through release-notes bug reports). I'm not sure I understand what you are expecting as a result by cloning/reassigning this to the release notes - Let me try to understand the problem: * if there's an encrypted partition, then systemd, who aparently would be responsible to do so will not prompt for the password, if plymouth is not installed. Is my understanding of the problem correct? So I think the right thing to do would be, that during the upgrade the systemd postinstallation should check whether there are some mounted partitions that are crypted and then recommend to install plymouth. Do you concur? Otherwise, should the release-notes recommend to install plymouth to the user if s/he has crypted partitions that should get mounted during boot? Ideally IMHO the release notes should also explain the problem in sufficient technical detail to allow the user to take his own steps to further understand the problem and to choose an alternative solution if he deems so. Optimally you could suggest a wording? Greets thanks, *t -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hi Tomas, thanks for taking care of the bugreport. Am 30.12.2014 um 19:27 schrieb Tomas Pospisek: Hello Jonas Kjetil, (context: I'm reading through release-notes bug reports). I'm not sure I understand what you are expecting as a result by cloning/reassigning this to the release notes - Let me try to understand the problem: * if there's an encrypted partition, then systemd, who aparently would be responsible to do so will not prompt for the password, if plymouth is not installed. Is my understanding of the problem correct? Yes. Actually, it is even more complicated, but your understanding is correct: Systemd includes its own dm-crypt/cryptsetup device unlocking functions. With systemd as init system, it processes all dm-crypt encrypted devices that shall be unlocked during the boot process and *after* initramfs. I don't know systemd, but from the bugreports I learned that it apparently doesn't implement a proper mechanism to prompt for user input itself. Instead it relies on plymouth doing that task. As a result, systemd without plymouth doesn't wait for user input at unlocking dm-crypt devices but instead continues to print boot logging output to the console. So I think the right thing to do would be, that during the upgrade the systemd postinstallation should check whether there are some mounted partitions that are crypted and then recommend to install plymouth. Do you concur? I would even go futher and say that systemd should recommend plymouth in any case. Still, if it's only recommended and not a hard dependency, the discovered behaviour should be documented in the release notes in my eyes. Otherwise, should the release-notes recommend to install plymouth to the user if s/he has crypted partitions that should get mounted during boot? Yes, that's what needs to be done at least. Ideally IMHO the release notes should also explain the problem in sufficient technical detail to allow the user to take his own steps to further understand the problem and to choose an alternative solution if he deems so. Optimally you could suggest a wording? Unfortunately I've not enough knowledge about systemd to propose a wording. But feel free to use anything I wrote in the bugreport for a draft. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
On Monday 15. December 2014 07.34.07 Jonas Meurer wrote: Thanks for your feedback. Can you provide me with some further information? Yes, I hope so! :-) Which init system do you use? Is this systemd, sysvinit or something completely different? I think it is systemd (no conscious decision from my side): kjetil@owl:~$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Nov 28 06:55 /sbin/init - /lib/systemd/systemd Did I get you right, that unlocking the encrypted root fs (sda5_crypt) works as expected (i.e. you see a prompt asking for passphrase) while at unlocking the encrypte home fs (owl-home_crypt) no prompt is displayed? Yes, that is correct. The main difference is, that the root fs is unlocked in initramfs, while the home fs is unlocked by a initscript. OK! In case that you use systemd: I know that systemd introduced some internal magic to handle encrypted devices at startup and to my knowledge this is tried before the initscript from my packages are started. So could you try the following: press return a few times when the system boot stops waiting for the passphrase of you encrypted home partition (without prompt) and see, whether it continues afterwards - optionally showing the expected prompt afterwards? H. Not sure about it. After hitting return a couple of times, it scrolls on, and there is another prompt that looks identical. If I continue hitting return, I get to the the maintainance prompt, where I can type the root passwd ot Ctrl+D. Anyway, I don't know if this ends up in a log somewhere? I certainly can't find the phrase passphrase by grepping all logs in /var/log (expect some installer logs). I managed to snap some real screenshots with my mobile phone. Don't know if that could help? Anyway, there's something that I suppose could be related, since /usr is currently mounted just after /home: [ 20.600434] systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. [ 20.689337] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. So, my idea was that /usr didn't need to be encrypted, and since it can also be mounted ro, I figured it could be a good idea to make a separate partition for it. But that seems to have been a Bad Idea, perhaps cryptsetup needs something in /usr that isn't there when /home is mounted? Sorry to bother you with extra debugging work, but unfortunately you seem to be the only one suffering from this bug so far. No problem! One of the reasons why i run testing is of course to help bring out such issues to help you guys fixing it before it goes stable, so this is something I had expected to deal with. :-) I wish I could do more to help, but alas, ENOTIME. Cheers, Kjetil
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hi Kjetil, after discussing this issue with other fellow debian developers, i might have a better understanding of what's going on. to be honest, i don't have much experience with systemd myself yet. Am 2014-12-15 12:07, schrieb Kjetil Kjernsmo: On Monday 15. December 2014 07.34.07 Jonas Meurer wrote: Which init system do you use? Is this systemd, sysvinit or something completely different? I think it is systemd (no conscious decision from my side): kjetil@owl:~$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Nov 28 06:55 /sbin/init - /lib/systemd/systemd as written earlier, systemd has it's own cryptsetup agent and uses that one to unlock encrypted devices instead of the the cryptdisks initscripts used by sysvinit. the problem is, that systemd doesn't wait for optional user input after running cryptsetup. the boot logger plymouth is responsible for this task. could you try to install plymouth on your system and see whether that fixes your issues? you can configure plymouth to use a text-mode theme if you don't like the graphical boot splash screen that hides all the boot log messages. if missing plymouth is the reason for the issues you discovered, then i fear that there's no easy solution to fix this bug. it seems like systemd simply requires something like plymouth to properly display user prompts at boot time :-/ Anyway, there's something that I suppose could be related, since /usr is currently mounted just after /home: [ 20.600434] systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. [ 20.689337] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. So, my idea was that /usr didn't need to be encrypted, and since it can also be mounted ro, I figured it could be a good idea to make a separate partition for it. But that seems to have been a Bad Idea, perhaps cryptsetup needs something in /usr that isn't there when /home is mounted? that's a separate issue. seems like systemd indeed doesn't support separate /usr partitions. that has been fixed in initramfs recently by mounting /usr in initramfs, but it's not clear yet whether that one makes it into jessie in time. still, the issue with separate /usr partition seems to be unrelated. if you're lucky, then installing plymouth will simply fix your boot process for the moment. cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
On Monday 15. December 2014 17.13.05 Jonas Meurer wrote: Hi Kjetil, after discussing this issue with other fellow debian developers, i might have a better understanding of what's going on. to be honest, i don't have much experience with systemd myself yet. OK! It seemed a little bit rushed to me to get as much as possible into systemd for jessie, but I suppose I shouldn't get involved as a non-DD :-) Am 2014-12-15 12:07, schrieb Kjetil Kjernsmo: On Monday 15. December 2014 07.34.07 Jonas Meurer wrote: Which init system do you use? Is this systemd, sysvinit or something completely different? I think it is systemd (no conscious decision from my side): kjetil@owl:~$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Nov 28 06:55 /sbin/init - /lib/systemd/systemd as written earlier, systemd has it's own cryptsetup agent and uses that one to unlock encrypted devices instead of the the cryptdisks initscripts used by sysvinit. the problem is, that systemd doesn't wait for optional user input after running cryptsetup. the boot logger plymouth is responsible for this task. Aha, OK! could you try to install plymouth on your system and see whether that fixes your issues? you can configure plymouth to use a text-mode theme if you don't like the graphical boot splash screen that hides all the boot log messages. Ah, yeah, that did work! In fact, I only had to write the passphrase once, which is kinda weird, what if I didn't use the same passphrase for both partitions? (Oh, I shouldn't say that I do ;-)) if missing plymouth is the reason for the issues you discovered, then i fear that there's no easy solution to fix this bug. it seems like systemd simply requires something like plymouth to properly display user prompts at boot time :-/ Mmmm, yeah... And I can't use a different init at this point? that's a separate issue. seems like systemd indeed doesn't support separate /usr partitions. Hmpf, yeah... :-( And plymouth didn't fix it... :-( Oh well, I suppose you could say wontfix on this bug, then! Cheers, Kjetil
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
clone 768314 -1 severity -1 normal retitle -1 systemd without plymouth kills input prompts at boot process reassign -1 release-notes close 768314 thanks Hi, Am 15.12.2014 um 20:50 schrieb Kjetil Kjernsmo: Am 2014-12-15 12:07, schrieb Kjetil Kjernsmo: I think it is systemd (no conscious decision from my side): as written earlier, systemd has it's own cryptsetup agent and uses that one to unlock encrypted devices instead of the the cryptdisks initscripts used by sysvinit. the problem is, that systemd doesn't wait for optional user input after running cryptsetup. the boot logger plymouth is responsible for this task. Aha, OK! could you try to install plymouth on your system and see whether that fixes your issues? you can configure plymouth to use a text-mode theme if you don't like the graphical boot splash screen that hides all the boot log messages. Ah, yeah, that did work! In fact, I only had to write the passphrase once, which is kinda weird, what if I didn't use the same passphrase for both partitions? (Oh, I shouldn't say that I do ;-)) Good to know. So at least we know the root for this issue now :) if missing plymouth is the reason for the issues you discovered, then i fear that there's no easy solution to fix this bug. it seems like systemd simply requires something like plymouth to properly display user prompts at boot time :-/ Mmmm, yeah... And I can't use a different init at this point? Sure, you can. Sysvinit should still be supported as well as openrc. 'apt-get install sysvinit-core systemd-shim' should do the trick, but I didn't test that myself yet. that's a separate issue. seems like systemd indeed doesn't support separate /usr partitions. Hmpf, yeah... :-( And plymouth didn't fix it... :-( Sorry, but I cannot help here. I suggest that you discuss this issue on debian-user or on IRC in #debian-systemd. But read this as well: https://wiki.debian.org/systemd#Booting_with_lvm_.28especially_with_separate_.2Fusr.29_fails https://lists.debian.org/debian-user/2014/10/msg02504.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742048 Oh well, I suppose you could say wontfix on this bug, then! Honestly, I prefer to close this bugreport. It's not a bug in cryptsetup at all, rather a shortcoming of systemd without plymouth that is intended. Maybe the best would be to add a note to jessie release notes? I cloned the bugreport and assigned it to release-notes with the bts commands above. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
On Monday 8. December 2014 23.21.05 Jonas wrote: Hello Kjetil, I guess that you discovered the bug due to a separate /usr partition. I just prepared packages that should fix the bug for you. Could you give them a try and report back? I'd like to get this fixed in time for jessie. So, it is rather more apparent that it stops at some point now, but there still isn't clear prompt as far as I can see. Adding to the problem is that things happen so fast, so I haven't got the time to understand what is going on. But it appears that there is kinda a prompt, then it rolls half a screen of unrelated messages, before it halts, and some kind of counter starts. I suppose this isn't really clear enough, please let me know if there is anything else I can do to help, but I'm terribly busy these days, so I can't promise anything. Kjetil
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hi Kjetil, Am 15.12.2014 um 00:23 schrieb Kjetil Kjernsmo: On Monday 8. December 2014 23.21.05 Jonas wrote: I guess that you discovered the bug due to a separate /usr partition. I just prepared packages that should fix the bug for you. Could you give them a try and report back? I'd like to get this fixed in time for jessie. So, it is rather more apparent that it stops at some point now, but there still isn't clear prompt as far as I can see. Adding to the problem is that things happen so fast, so I haven't got the time to understand what is going on. But it appears that there is kinda a prompt, then it rolls half a screen of unrelated messages, before it halts, and some kind of counter starts. I suppose this isn't really clear enough, please let me know if there is anything else I can do to help, but I'm terribly busy these days, so I can't promise anything. Thanks for your feedback. Can you provide me with some further information? Which init system do you use? Is this systemd, sysvinit or something completely different? Did I get you right, that unlocking the encrypted root fs (sda5_crypt) works as expected (i.e. you see a prompt asking for passphrase) while at unlocking the encrypte home fs (owl-home_crypt) no prompt is displayed? The main difference is, that the root fs is unlocked in initramfs, while the home fs is unlocked by a initscript. In case that you use systemd: I know that systemd introduced some internal magic to handle encrypted devices at startup and to my knowledge this is tried before the initscript from my packages are started. So could you try the following: press return a few times when the system boot stops waiting for the passphrase of you encrypted home partition (without prompt) and see, whether it continues afterwards - optionally showing the expected prompt afterwards? Sorry to bother you with extra debugging work, but unfortunately you seem to be the only one suffering from this bug so far. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hey Kjetil, Am 09.12.2014 um 16:42 schrieb Kjetil Kjernsmo: On Monday 8. December 2014 23.21.05 Jonas wrote: . Could you give them a try and report back? Great! Yes, I'll try them, but there's something I need to finish first, I'll do it as soon as I can. Thanks a lot. I'll wait for your feedback before uploading the packages. Cheers, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768314: [pkg-cryptsetup-devel] Bug#768314: cryptsetup: Passphrase prompt rolls by without stopping
Hello Kjetil, I guess that you discovered the bug due to a separate /usr partition. I just prepared packages that should fix the bug for you. Could you give them a try and report back? I'd like to get this fixed in time for jessie. You can find the prepared packages here: https://people.debian.org/~mejo/debian/mejo-unstable/ Cheers, jonas Am 06.11.2014 um 13:56 schrieb Kjetil Kjernsmo: Package: cryptsetup Version: 2:1.6.6-3 Severity: normal Dear Maintainer, I just upgraded my Wheezy laptop with an SSD to Jessie, and making notes to hopefully make it useful for stabilizing the next release. The only real issue I came across is the following, but it was pretty scary. See the crypttab below for the details about my encrypted partitions. * What led up to the situation? A dist-upgrade to Jessie was performed. There were some warnings about LVM stuff, but that alerted me to anything that I deemed serious or relevant. Some packages weren't cleanly installed, it stopped with some texlive stuff that is surely not relevant, but the kernel was not upgraded when I did the first reboot. After reboot, I get prompted for the passphrase of the root partition. From there, the bootup is so fast, I don't have to time to react to anything, before I get a message that isn't very specific about a problem with a the /home partition. After a while, it just times out, and I enter a shell as root to find a journal that tells me it failed. * What exactly did you do (or not do) that was effective (or ineffective)? The journal gave me some hints that the passphrase was missing, which I kinda knew, so I just tried another reboot, and now I saw the prompt to enter passphrase just flashing by in a split second. I enter it anyway, even though the prompt has disappeared. * What was the outcome of this action? And that worked! * What outcome did you expect instead? The bootup should pause at the prompt, so that there is no doubt what should be done. So, basically, it works, but the UX of this is horrible and really scary since you are afraid that you cannot recover the data in the partition (yeah, I have backup, so I was just marginally worried :-) ) BTW, remote filesystems have been deleted from the below fstab. I hope this is helpful. Cheers, Kjetil -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16-3-amd64 root=/dev/mapper/owl-root ro quiet -- /etc/crypttab owl-home_crypt UUID=ffe18d19-c031-42ec-a6bb-b75aa7ddd9bc none luks sda5_crypt UUID=db58ea52-3415-4737-863b-5129cf2db308 none luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass /dev/mapper/owl-root / ext4 discard,noatime,errors=remount-ro 0 1 # /boot was on /dev/sda1 during installation UUID=b0442da3-f1e7-41ac-a324-07322b487586 /boot ext2defaults 0 2 /dev/mapper/owl-home_crypt /home ext4discard,noatime0 2 /dev/mapper/owl-lvol0 /usr ext4discard,noatime 0 1 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 -- lsmod Module Size Used by rpcsec_gss_krb534296 0 nfsv4 414796 1 dns_resolver 12641 1 nfsv4 xt_tcpudp 12527 54 ip6table_mangle12540 0 iptable_nat12646 1 nf_conntrack_ipv4 18455 20 nf_defrag_ipv4 12483 1 nf_conntrack_ipv4 nf_nat_ipv412912 1 iptable_nat nf_nat 18241 2 nf_nat_ipv4,iptable_nat xt_TCPMSS 12588 6 xt_LOG 17171 45 ipt_REJECT 12465 0 iptable_mangle 12536 0 xt_multiport 12518 0 xt_state 12503 0 xt_limit 12601 49 xt_conntrack 12681 19 nf_conntrack_ftp 16783 0 nf_conntrack 87432 7 nf_nat,xt_state,nf_nat_ipv4,xt_conntrack,nf_conntrack_ftp,iptable_nat,nf_conntrack_ipv4 ip6table_filter12540 1 ip6_tables 26025 2 ip6table_filter,ip6table_mangle iptable_filter 12536 1 ip_tables 26011 3 iptable_filter,iptable_mangle,iptable_nat x_tables 27111 14 ip6table_filter,ip6table_mangle,ip_tables,xt_tcpudp,xt_limit,xt_state,xt_conntrack,xt_LOG,xt_multiport,iptable_filter,xt_TCPMSS,ipt_REJECT,iptable_mangle,ip6_tables binfmt_misc16949 1 nfsd 263053 2 auth_rpcgss51240 2 nfsd,rpcsec_gss_krb5 oid_registry 12419 1 auth_rpcgss nfs_acl12511 1 nfsd nfs 188053 2 nfsv4 lockd 83417 2 nfs,nfsd fscache
