@fm: This bug is fixed on 2010-01-14. Please open a new bug report with
ubuntu-bug cryptsetup if you still have problems with cryptsetup.
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a
Today I deemed it safe to upgrade my ubuntu 9.04 to 9.10. After 5+ months I
expected a smooth upgrade.
I had splash disabled. I have /home on a lvm luks volume.
Multiple cryptsetup processes seem to be started, directing output/input to
something else than tty1.
With rebooting, trying again,
Hi,
i've the same issue which is driving me nuts actually.
Setup is Ubuntu 9.10 with /home and swap encrypted (setup since 6.10 or so,
can't remeber exactly when i added it). It worked fine till 9.10, then the
insane problems started. It sometimes work (e.g. i can enter the passphrase at
Just another data point. I've been seeing the asks for your passphrase
3 times problem ever since I upgraded to 9.10 back in 2009-10, along
with the press ESC to get a root shell type message, sometimes twice.
I only have /home encrypted.
Although it feels a bit like the passphrase input is
I am seeing very similar, frustrating behaviour, with a brand new
install of 9.10 (amd64), which I then updated meaning I have cryptsetup
2:1.0.6+20090405.svn49-1ubuntu7.2 and mountall 1.0, watershed 4, etc..
No 'essential' mount points are encrypted (which I believe is a factor),
only swap and
I will say that after some time, my current set up works a lot of the
time (using usplash), but I occasionally get the same error that Dave
mentions above about usplash telling me to hit ESC to drop to a
console, but no keyboard input does anything (except ctrl + alt + del
still reboots for me
I guess I need to retract my last post. The first few times, it behaved
as I described above, but now it seems to be completely random. Most of
the time I can only get in by doing the recovery mode grub option, then
trying to type in my password unsuccessfully a few times, dropping to a
root
On Sun, Jan 24, 2010 at 11:15:49PM -, WilliamWolf wrote:
It seems that the latest watershed + cryptsetup packages do not solve the
problem, in my case at least. I'm not sure what information I can
provide to help pinpoint the problem, but let me know if I can be of any
further help.
Are
Ahh, you are right. I had gotten used to using the recovery mode kernel
instances in grub, but when I do the non-recovery mode (with splash), it
does work, but as I noted in my first message, I always have to type my
password 3 times. It's as if the first 2 times don't get to cryptsetup
The watershed + cryptsetup packages from -proposed fixed the problem for
me, but for my /home partition to be decrypted/mounted, itasks me for my
password 3 times every time. The root partition only asks once, and
then the /home asks me 3 times every time.
I have / encrypted, /home encrypted,
ChrisOlin пишет:
I appear to have the same problem yens is having, except I'm not
prompted for the passphrase at all. Trying to mount the root device
times out and I'm dropped into a busybox shell, where I can manually run
cryptsetup luksOpen /dev/sda1 crypt1, but it won't continue booting.
Steve Langasek пишет:
Trying to mount the root device times out and I'm dropped into a
busybox shell
This bug report is about decrypting disks after the root filesystem is
already mounted. Please file a separate bug report for the issue you're
seeing.
Also, the library dependencies
Посмотри фильм Аватар я думаю мы скоро к этому придем.
This is not a movie discussion forum. Please take this elsewhere.
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
I appear to have the same problem yens is having, except I'm not
prompted for the passphrase at all. Trying to mount the root device
times out and I'm dropped into a busybox shell, where I can manually run
cryptsetup luksOpen /dev/sda1 crypt1, but it won't continue booting.
This problem appeared
Actually, I forgot something. Originally, I did get a prompt to enter my
passphrase, but it kept coming back as incorrect. When I started trying
to fix this problem is when the passphrase prompt went away entirely,
and I would get the shared library error if I try manually mounting the
cryptsetup
Trying to mount the root device times out and I'm dropped into a
busybox shell
This bug report is about decrypting disks after the root filesystem is
already mounted. Please file a separate bug report for the issue you're
seeing.
Also, the library dependencies of cryptsetup are expected to be
I found the attached workaround on the internet and everything worked
fine until today.
Then there was this apt-get update : ...
Préparation du remplacement de cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7.2 (en
utilisant .../cryptsetup_2%3a1.0.6+20090405.svn49-1ubuntu7.2_amd64.deb) ...
yens,
Please be specific - why do you need several reboot attempts to enter
the password? What is happening when you try to enter the password?
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you
This bug was fixed in the package cryptsetup -
2:1.0.6+20090405.svn49-1ubuntu7.2
---
cryptsetup (2:1.0.6+20090405.svn49-1ubuntu7.2) karmic-proposed; urgency=low
* Depend on watershed.
* cryptdisks.functions: do_tmp should mount under /var/run/cryptsetup for
changing the
** Tags added: verification-done
** Tags removed: verification-needed
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Thanks, installing 'watershed' made it.
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
I have tested the package (I believe, I have version
2:1.0.6+20090405.svn49-1ubuntu7.1). My configuration is
/etc/crypttab:
home /dev/sda6 none luks,tries=5
From /etc/fstab:
/dev/mapper/home/home ext4defaults,nofail,relatime0 2
With previous cryptsetup I got prompted for
Tomas,
Please check that you have the 'watershed' package installed. There is
an updated SRU package, -1ubuntu7.2, that adds this missing dependency.
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification
Accepted cryptsetup into karmic-proposed, the package will build now and
be available in a few hours. Please test and give feedback here. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
** Changed in: cryptsetup (Ubuntu
Following discussion at UDS, an SRU has been uploaded to the queue with
a more complete fix for this, involving an upstart job that triggers on
the udev block-device-added event. There are still some corner cases
with risk of regression (documented in other bug reports linked from the
changelog),
I think I'm running into this bug also.
I have two encrypted partitions, one on a non-removable drive and one on
a firewire drive. GDM started up without waiting for me to enter any
passwords, and I now have the following showing up in pstree--
I should also point out that the encrypted partition on the non-
removable drive is currently set to noauto in fstab, but it still
seems to be stalling the boot process to some degree.
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You
On Mon, Nov 30, 2009 at 10:04:28PM -, Jesse Michael wrote:
I should also point out that the encrypted partition on the non-
removable drive is currently set to noauto in fstab, but it still
seems to be stalling the boot process to some degree.
For karmic, you will want to mark it 'noauto'
As Scott has argued, users don't choose disk encryption if their priority is
boot performance.
And users can always mark devices 'noauto' in /etc/crypttab, if they don't
want them
autostarted - if they *do* want them autostarted, it would be nice to do so
more reliably
than we do currently.
Fixed for lucid with the upload of -1ubuntu8. Changelog:
cryptsetup (2:1.0.6+20090405.svn49-1ubuntu8) lucid; urgency=low
[ Steve Langasek ]
* Make the 'start' action of the init script a no-op, this should be
handled entirely by the upstart job now; and remove any symlinks from
Subscribing ubuntu-sru for the karmic side of this.
Martin, would appreciate some input on this proposed change prior to
upload, since it does carry significant risk; an alternative approach
would be to also hook the upstart job into a udev rule at the same time,
to completely eliminate the
** Branch linked: lp:~ubuntu-core-dev/cryptsetup/karmic
--
cryptsetup init scripts are redundant and can break the boot
https://bugs.launchpad.net/bugs/473615
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
32 matches
Mail list logo
