every six months i update, and then i run into this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/139057
Title:
Should try given password for next partition
To manage notifications about this bug
** Changed in: cryptsetup (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: cryptsetup (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/139057
Tit
>From time to time I start googling for this feature - and I always end
up here. I would appreciate this feature very much. :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/139057
Title:
Should try
Here is a solution I am using in Lucid and Maverick, when not using LVM
so as to alllow use of separately encrypted partitions. This is to
support multi-disk video editing machines. It is crude and uses
hardcoded UUID values for each partition, not reading crypttab for now.
Eventually I will play w
Well, even with all the patches mentioned so far, you still have to type
your password twice. A solution might be Novells approach on openSuSE
11.1: They add kernel options.
it goes like this:
$ cat /proc/cmdline
root=/dev/mapper/root luks_root=/dev/sda5
swap=/dev/mapper/swap luks_swap=/dev/sda2
@Luke
I don't know the internals of the shell...
Maybe a function like this will help:
unset_pass()
{
[ -n "$1" ] || return 0
eval "$1=\$(dd if=/dev/urandom bs=1k count=4 2>/dev/null)"
unset $1
return 0
}
unset_pass PASS
--
Should try given password for next par
Question: Does unsetting the PASS variable actually reset the bits in
ram to zero-or do they stay set to the values the variable stored there
until power is removed?
If unsetting the variable doesn't reset RAM bits to zero, I would
suggest forcing them to an alternate value or to zero by resetting
** Attachment added: "/etc/initramfs-tools/hooks/cryptdevs"
http://launchpadlibrarian.net/24247628/cryptdevs
** Attachment removed: "/etc/initramfs-tools/hooks/cryptdevs"
http://launchpadlibrarian.net/24246671/cryptdevs
--
Should try given password for next partition
https://bugs.launchp
And if you want to force decryption of all devices in "/etc/crypttab"
during the "initramfs" stage, you can drop this additional file in the
"hooks" folder.
Tested on Jaunty alpha.
** Attachment added: "/etc/initramfs-tools/hooks/cryptdevs"
http://launchpadlibrarian.net/24246671/cryptdevs
--
I have the same issue with Jaunty.
Here is the script to try same password for next device.
You can patch the file in place, or copy the file to
"/etc/initramfs-tools/scripts/local-top/" before to patch it: it will override
the file in "/usr/share".
Then run "sudo update-initramfs -u".
--- /usr
The patched file.
** Attachment added: "/etc/initramfs-tools/scripts/local-top/cryptroot"
http://launchpadlibrarian.net/24246510/cryptroot
--
Should try given password for next partition
https://bugs.launchpad.net/bugs/139057
You received this bug notification because you are a member of Ubun
Hi, i had a similar problem on my laptop:
* I have 2 encrypted partitions: sda5 and sda6:
/dev/sda5 -> swap partition
/dev/sda6 -> mapped to /var (with binding /var/home -> /home)
* Both partitions use the same password
* I use uswsusp for hibernate/resume features
* The initramfs step asks m
Well, the purpose of the initramfs script is not only to decrypt rootfs
but also to decrypt an encrypted swap (which is necessary because you
might wanna resume from suspend-to-disk).
--
Should try given password for next partition
https://bugs.launchpad.net/bugs/139057
You received this bug noti
the is a reason for having two hooks: one for initramfs and one for the init
script.
the initramfs hook is only for mounting the root filesystem. So the only point
in the patch above is when you have your root device across several crypted lvm
or raid volumes on different hard drives.
I think h
With usplash it is pretty easy to implement. However the problem is that
it will work with usplash and usplash only. If you disable usplash its
behaviour will still be the same. The problem is that without usplash
the cryptsetup binary is fetching the password from console directly -
leaving no cha
Since there is an approved blueprint this should be confirmed.
** Changed in: cryptsetup (Ubuntu)
Status: New => Confirmed
--
Should try given password for next partition
https://bugs.launchpad.net/bugs/139057
You received this bug notification because you are a member of Ubuntu
Bugs, whi
I too would be interested in seeing this functionality added.
--
Should try given password for next partition
https://bugs.launchpad.net/bugs/139057
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubunt
17 matches
Mail list logo
