@Ulrich Lukas
I agree that only encrypting home, var, tmp.. is a good way to secure personal
data while keeping the system fast.
@5tan
Indeed security is gone if someone unnoticedly gets hardware access and returns
modified hardware/software; This is true even if the whole root filesystem is
To me it seems that cryptsetup has two startup scripts (in /etc/init.d):
cryptdisks-early
cryptdisks
AFAIK both read /etc/crypttab and cryptdisks-early reads the 1st line
(probably what's needed to boot) and cryptdisks reads the remaining lines.
For some reason upstart doesn't wait for the entry
AFAIK, The reason is that upstart never wait for a task to end before
starting another one, unless a task depend on the first task. No task
depends on cryptsetup and actually no task should depend on it. However,
many tasks depend on root filesystem and won't start until filesystem
gets available.
cryptsetup can't have the power to stop - why not?
If I need the filesystems, everything depends on it, so everything else should
wait (or at least it should be possible to set that manually). I mean, if I
don't set the noauto option in crypttab, I want 'auto' and not manual.
--
cryptsetup
vbar : Giving the ability to a software to freeze the boot can lead to
many problems, this is not how upstart works. Upstart let you do it in a
very more flexible way as you can define which tasks require each other,
which slightly reduce probabilities of boot problems. This concept boost
boot
vbar wrote:
cryptsetup can't have the power to stop - why not?
Because that would interfere with Ubuntu's boot speed ambitions, I
recon. I.e. there might be cases (e.g. with key files, RFID-cards etc.)
where it might make sense to continue booting while cryptsetup does its
work unattendedly.
but the computer does not need other filesystem than root to be mounted
to boot correctly, therefore it makes no sense to depend on
other filesystems then root.
What if any of the essential directories (/var, /home, ...) reside on
other filesystems, are mounted onto the root filesystem,
So, isn't it a solution to simply make root filesystem depend on
cryptsetup in cases where interactive input is needed? I.e. when no
other (xsplash, key file) method is used?
Actually, root filesystem already depends on cryptsetup by design when
root partition is encrypted, since it will never
@5tan: Strange, my 'target=...' in '/etc/initramfs/conf.d/cryptroot' IS
respected in my two LUKS setups, one on Karmic and the other one still
on Jaunty.
--
cryptsetup prompt is overriden by upstart and xsplash in Karmic
https://bugs.launchpad.net/bugs/434232
You received this bug notification
I tried to do an install of karmic amd64 from alternate installation
disc with encrypted root, /var, /home, swap partitions on top of a
RAID10 fp2 4 disks array.
Results are:
System boots then xsplash starts asking me for the passphrase of the root
partition. I enter the passphrase then I get to
Well, the EXACT (and USB-disk-proof) syntax is:
echo 'target=#TARGET#,source=/dev/disk/by-uuid/#UUID#'
/etc/initramfs-tools/conf.d/cryptroot
(thus leading to a '/dev/mapper/#TARGET#' device; otherwise, you get a
'/dev/mapper/cryptroot' device)
Also, make sure to add the proper modules in
Cédric Dufour,
You right! In my testing system target is /dev/mapper/cryptroot and it was OK.
But when I try change it to anything else... device path is still
/dev/mapper/cryptroot
source=/dev/SOMETHING (where SOMETHING means something like hda2, sda1,
sda2, ...) should also work, but your way
On Fri, Oct 30, 2009 at 03:41:56AM -, Ulrich Lukas wrote:
While I admit that that concerns a smaller number of installations,
using a non-encrypted root partition with encrypted /home, /tmp, /var is
best practice
It most certainly is not best practice.
--
cryptsetup prompt is overriden
Thanks for the reply and the workarounds, but please consider that there
are systems with custom kernels and without an initramfs.
While I admit that that concerns a smaller number of installations,
using a non-encrypted root partition with encrypted /home, /tmp, /var is
best practice if you run
First, I'm sorry for my bad english, but I want help with this
cryptsetup problem :)
Saïvann Carignan: according to:
My /etc/crypttab file contains this :
X /dev/sda7 none luks
My /etc/fstab file contains this :
/dev/mapper/X /media/X ext4 defaults,relatime 0 0
echo
Hi, Steve,
the current situation is unbearable.
If I set up my encrypted /home exactly like all the HOWTOs say (i.e.
manually after installation), the password prompt is not accessible
unless switching back to the first text console. (And even there the
password prompt is horribly broken and
Ulrich Lukas : Please don't change the bug status, Triaged is more
appropriate than Confirmed here. As mentionned in previous comments,
this bug affect very rare user customisations where the root filesystem
does not depend on cryptsetup. In your case, you can easily use a
workaround to enjoy
As of the latest upload of initramfs-tools, this should be working
again, but only by accident: cryptsetup is now setting up usplash
unconditionally in the initramfs, whereas it should only do this if it's
needed for decrypting the root filesystem or swap. So I'm leaving this
bug open since we
Having looked into this, it's too much effort to bother with to get
usplash /not/ started in initramfs for the case where cryptsetup is not
needed for the rootfs; so I'm wontfix'ing this bug for karmic and
downgrading it since we effectively will always have usplash already
running before reaching
Steve Langasek : You probably means upstart? Anyway that sounds
correct AFAIK, unless there was some easy way to prompt the password
through xsplash rather than usplash or console. Since root filesystem
does not depend on cryptsetup in this case, upstart does not need to
wait on cryptsetup while
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/32180333/Dependencies.txt
--
cryptsetup prompt is overriden by upstart and xsplash in Karmic
https://bugs.launchpad.net/bugs/434232
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Scott James Remnant : subscribed at your request in bug 430496 since it
does not seem to be fixed in that situation.
--
cryptsetup prompt is overriden by upstart and xsplash in Karmic
https://bugs.launchpad.net/bugs/434232
You received this bug notification because you are a member of Ubuntu
22 matches
Mail list logo
