According to one line fix for Edgy by John Leach:
Don't forget to also change line 318 (no_luks) also
from:
$CRYPTCMD $PARAMS create $dst $src 1
to:
$CRYPTCMD $PARAMS create $dst $src /dev/console
Now it should work for al people who have the new edgy
cryptdisks.function
--
Upstart
Hi Marc,
Just FYI, I've tested your Edgy patch [1], and it doesn't work for me,
didn't dig much into why, found it not working and reversed the changed
and went back to the old, break usplash and ask for password fix from
the beginning of this thread.
[1] :
Please ignore my last comment! My /etc/crypttab was fucked up... I can configm
Lennart's observations; It's working with luks devices but not with the old
ones!
Also one problem remains for me. If I have the quiet parameter in the boot
options my keyboard is just not working during the boot
I'm sorry, but this is still not working for me on an up to date feisty
machine!
When splash is enabled, all I'm getting is upslash freezing when the bootup
process is trying to mount the encrypted partitions and after a while it turns
into a black screen, where i can't do anything.
If I
Okay, I found out some important things. What I did is to reinstall
dapper, activate all repositories in /etc/apt/sources.list (including
multiverse) and made an update of dapper.
After a reboot I then changed all dapper into edgy in the
sources.list and updated the whole system once again. There
I am facing the same problem. Is the fix already included in new install
cd? If not, when will this be done?
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
It is not yet included. As I am quite new to this subject, it would be
nice to give me a real step for step instruction what to do exactly
after a new edgy installation! Thanks in advance!
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs
Ok
I upgraded my system to ubuntu 6.10 then cryptodisk wasn't working anymore - I
found the edgy patch and patched my system.
(sudo patch -p0 cryptdisks.functions.edgy.patch)
but after that i can't start cryptodisk anymore. not even manually.
every time I trie to it says starting cryptodisk...
Tried an easy, dirty fix today. Simply did:
sudo cp -s /etc/rcS.d/S26lvm /etc/rcS.d/S29lvm
Which just creates a symbolic link so it runs lvm again after setting up the
cryptdisks. Seems to work. Had some problems when just moving S28cryptdisks in
front of lvm.
--
Upstart doesn't activate luks
Just did a fresh install of Edgy Eft and found to my delight that the
mounting of encrypted volumes now works without any patching. It stops
and asks repeatedly for a passphrase. There is only a small problem, LVM
tries to mount before the encrypted volumes. If I enter the passphrase,
continue the
** Changed in: usplash (Ubuntu)
Status: Unconfirmed = Rejected
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
This bug is partly fixed now, still pending is the patch proposed by
Marc Schiffbauer.
** Changed in: cryptsetup (Ubuntu)
Status: Fix Committed = In Progress
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
and this problem is maybe fixed only in feisty+1 not in edgy.
Has anyone tested that fixes on non-root crypto partition?
for example /home mounted with cryptsetup init.d script (not initrd).
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs
and this problem is maybe fixed only in feisty+1 not in edgy.
That essentially means Ubuntu is useless for anyone having sensitive data on
his laptop!
Has anyone tested that fixes on non-root crypto partition?
for example /home mounted with cryptsetup init.d script (not initrd).
The
I used the fix from Scott James and the patch from Marc Schiffbauer on a new
edgy install with encrypted home partition. Everything works as expected:
- with usplash I get asked for the password via usplash
- without usplash I get asked for the password on the console
I do not get a blank screen
I made one patch from the different patches in this bug for the file
/lib/cryptsetup/cryptdisks.functions that works for me in
usplash und console mode.
** Attachment added: Patch from Scott James, Swen Thümmler and Marc
Schiffbauer together
I made one patch from the different patches in this bug for the file
/lib/cryptsetup/cryptdisks.functions that works for me in usplash und
console mode.
Thanks, that works for me just fine in console mode (I reinstalled cryptsetup
and then applied the patch).
With splash I get asked for
Matthias Hilbig [EMAIL PROTECTED] writes:
I used the fix from Scott James and the patch from Marc Schiffbauer on
a new edgy install with encrypted home partition. Everything works as
expected I do not get a blank screen when booting ends.
Thank you for your feedback. I'll see that I prepare
I just discovered one minor bug in my patch: the returncode-check is
somewhat useless now as it would check only the rc of the last
usplash_write command in case we have usplash running.
Here is an updated patch. (This patch is against the 1.0.4-8ubuntu1
package from feisty that I backported to
Sorry guys. Another update. This one fixes a potential syntax error in
case with type the correct passphrase with usplash. (RC got not set in
that case)
-Marc
** Attachment added: latest patch with RC-code checking fix
http://librarian.launchpad.net/5148419/cryptdisks.functions.patch
--
Marc: your patch doesn't apply cleanly (on Edgy) for me:
sudo patch -p0 cryptdisks.functions.patch
patching file /lib/cryptsetup/cryptdisks.functions
Hunk #1 FAILED at 265.
1 out of 1 hunk FAILED -- saving rejects to file
/lib/cryptsetup/cryptdisks.functions.rej
--
Upstart doesn't activate
As I mentioned here [1] this patch was for the latest feisty version of
the package.
The diff against the original edgy script is mich bigger because there
changed some other things, too.
So for your convenience here is the patch against the current edgy
version. I guess it will work, but its
Marc: and while entering the passphrase there are no asterisks shown.
[...] For John Doe user it might be good if he sees those while typing
the passphrase. Somewhat cosmetic, but for the records.
I'd rather not see asterisks when entering my passphrase because once an
attacker knows how many
Marc: Your patch now applies, but I still can't load X when using splash. I
don't care too much for splash (in fact I usually deactivate it to see better
what's going on) but some might care more than I do
I agree with Stefan, no asteriskes is safer. Besides, it's very much standard
in
cryptsetup (2:1.0.4-8ubuntu1) feisty; urgency=low
* merge debian changes, remaining patches:
- Always output and read from the console. Ubuntu: #58794.
* other changes have been merged or do noy apply anymore
* read password via usplash if available in initramfs for rootfs. based
hi, i have same problem. i have /crypt mounted as encrypted partition.
I'm using passphrase. i don't' have root partition encrypted so swen's
patch doesn't fix my problem :( - it's only for crypt root partition.
--
Upstart doesn't activate luks volumes in cryptsetup
I have solved this issue for my crypted root filesystem by making the following
modification to /usr/share/initramfs-tools/scripts/local-top/cryptroot:
--- cryptroot.orig 2006-11-12 12:31:08.0 +0100
+++ cryptroot 2006-11-12 12:30:41.0 +0100
@@ -160,7 +160,11 @@
# Loop
Vielen Dank Swen!
Together with the modifications of /lib/cryptsetup/cryptdisks.functions
it works like a charm.
//Jari
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Keybuk: is Swen's patch above the Right Thing To Do(tm)?
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Hi,
I'm also trying to get encryption to work under Edgy Eft. The tip given
above seems to work, but after entering the LUKS password I get dumped
into a root shell. I can exit and everything seems to continue as
normal. Is there anyway to avoid getting into the root shell?
The tip I followed (I
Hmmm, this only seems to be true when I boot with an image created by yaird.
The Ubuntu one works fine. Sorry guys. I'm trying to follow this but I'm
adapting it to Ubuntu:
http://www.debianhelp.org/node/1116
--
Upstart doesn't activate luks volumes in cryptsetup
hey - i've got a workaround that I use, but not a fix.
ive set up an encrypted partition on /dev/hdb3
to get it to ask for the password when gnome loads up (and mount it
then), ive taken the reference to it out of /etc/fstab, and included it
into /etc/pmount.allow
then in the gnome startup
Isn't this a problem with cryptsetup? I have a setup where a partition
on my harddrive is encrypted with a key. This key is saved in a file,
encrypted with openssl. Then I use pam_mount to mount it, whenever I log
in.
I have this on two laptops, so when the first laptop was reinstalled
with Edgy,
I'm using loop-aes for encryption, and experiencing similar issues when
/etc/init.d/mountall.sh attempts to mount the encrypted volumes listed
in /etc/fstab with loop= and encryption= options.
Adding console owner to /etc/event.d/rcS fixed that, but I also found
that the password was echoed to
I did what mish says above, but for me the fix don't work.
i get a command prompt, with this:
Enter Password: Enter Password: there must be a error, cause it seems
that the second Enter Password is inserted automaticaly.when i then
try to enter my real password (plaintext) i get an error about a
according to a tip from somebody, i forgot to change the line:
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 $@
to
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 $@
Now it works, but in plaintext like some other users posted before.
maybe this can be changed in the near
I can confirm that removing 'splash' from the boot options, together
with scott's patch solves the problem for me.
I'm not sure what this has to do with usplash, but I created a bugtask
for it and leave it unconfirmed.
** Also affects: usplash (Ubuntu)
Importance: Undecided
Status:
I prepared a new upload with the fixes and workarounds so far.
I had to disable translations because of an unsubstituted MKINSTALLDIRS
variable in Makefiles. Debian's cryptsetup pakage doesn't run automake
at build time, and we have probably no time left to investigate that
issue, so better
The fix worked for me :)
As a possible improvement to the code, to include the old option (ie
ON_VT == yes )
stdin=`readlink /proc/self/fd/0`
if [ ${stdin#/dev/null} != $stdin ]; then
if [ $ON_VT != yes ]; then
exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 $@
else
Oh and I had to do a little searching for the file (as no one seems to
mention it in the text above). The fix should be applied to
/lib/cryptsetup/cryptdisks.functions
(I'm not familiar with patch, so after a little blundering around
failing to get it to work I went for the direct edit).
--
The init script fix works for me too. When I started ubuntu with the
kernel parameters quiet and splash, the password was visible on the
console. When I removed quiet and splash the password was not visible.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
Oddly, I can't confirm those observations. The patches work for me and
the password is not displayed when used via init. Very odd. I saw that
upstart was updated recently, maybe that changed something?
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
This has absolutely nothing to do with upstart.
This bug is caused by the decision to not have standard input or output
available to boot scripts by default.
If we still used sysvinit, the same bug would be present
--
Upstart doesn't activate luks volumes in cryptsetup
I have a proposed fix for this, could somebody who uses cryptsetup try
this...
Edit the init.d script, at the top you'll find some code that looks
like:
stdin=`readlink /proc/self/fd/0`
if [ ${stdin#/dev/null} != $stdin ]; then
exec /dev/console /dev/console 21
fi
Modify that so it reads:
The patch works somehow, in the sense that it is now possible to enter
something. But
* the boot process continues, so that the graphical system pops up
before it is possible to enter the complete passphrase. Particularly,
mountall.sh is executed (and the crypted partitions are not mounted...).
*
The alternate fix is to add console owner to /etc/event.d/rcS and
/etc/event.d/rc2
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Oh, add -w to the openvt call
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
For me, both patches work, but the passphrase is still displayed (which
was never the case before...)
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Bug 65979 has been marked a duplicate of this bug
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
I can confirm jott's observations.
When using cryptsetup on the shell (manually), the password is hidden.
When used via the init script, the passphrase is shown in plaintext!
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
this bug is reproducible. Importance high, because this is a regression
from previous ubuntu releases. Before, with sysvinit, it was possible to
have filesystems like /home mounted at boot-time.
** Changed in: cryptsetup (Ubuntu)
Importance: Undecided = High
Status: Unconfirmed =
** Bug 56319 has been marked a duplicate of this bug
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Note that this is also a universe package, so it's very low priority for
main developers.
The problem appears to be that whatever asks for the password does so
from /dev/tty, which isn't openable.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
any progress on this? can we target this for edgy?
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Ok. What is the supported mechanism for reading user input during the
boot process? I'm happy to attempt a patch.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
An alternative to reading the password from console might be to use
pam_mount, to mount the encrypted filesystem when the user logs in.
Here is a description of using pam_mount together with dmcrypt:
http://deb.riseup.net/storage/encryption/dmcrypt/
--
Upstart doesn't activate luks volumes in
Yes, if it was just the home directory, that would be a possibility. But
I also encrypt a partition that daemons (e.g., Apache) need, so it's not
really practical to postpone it all to login time.
With respect, it seems to me that even if cryptdisk is in Universe, this
is a pretty substantial
I can confirm the behavior as well, FWIW. And it is certainly
annoying...
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Also FWIW, this is probably the same issue as bug #56319.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
no news on this?
imho we are talking about a very important feature ...
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Quite annoying bug each time you boot the system.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Bug 62406 has been marked a duplicate of this bug
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Same problem here. I get this message two times before it tries to mount
my partition:
Enter LUKS passphrase: Command failed: error reading passphrase
Init/upstart offers me to enter root-pw to login, but even with this
login I get the same error. After boot is completed I can log into a
sysv-rc calls cryptsetup, as it iterates /etc/rc?.d
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Is cryptsetup perhaps being loaded and sent to the background detached
from the console? If I boot the kernel without splash I see it
complaining about not being able to read the password. It definitely
needs to be run interactively.
--
Upstart doesn't activate luks volumes in cryptsetup
It's loaded detached from the console, which is why it has code at the
top of the cryptsetup.functions file to explicitly reattach it to the
console.
Unfortunately it appears that it may also need that to be its
controlling tty
--
Upstart doesn't activate luks volumes in cryptsetup
Not an upstart bug, cryptsetup is incorrectly accessing the console to
ask for input during boot
** Also affects: cryptsetup (Ubuntu)
Importance: Undecided
Status: Unconfirmed
** Changed in: upstart (upstream)
Status: Unconfirmed = Rejected
--
Upstart doesn't activate luks
Same problem here, encrypted volumes not mapped. I could see cryptsetup
messages briefly flowing by during boot, so it really looks like upstart
calls cryptsetup to map these volumes.
--
Upstart doesn't activate luks volumes in cryptsetup
https://launchpad.net/bugs/62751
--
ubuntu-bugs mailing
68 matches
Mail list logo
