This is a somewhat old LP bug, but for completeness it worth mentioning
here that recently some patches were merged on initramfs-tools and
cryptsetup, that allow a good experience booting with LUKS-encrypted
rootfs on top of a degraded RAID1 array; for details, please check:
I also can confirm this bug on 14.04 First time notices on Ubuntu
8.04.2. Take a look here:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/324997
and here:
http://feeding.cloud.geek.nz/posts/the-perils-of-raid-and-full-disk-
encryption-on-ubuntu/
--
You received this bug notification
Actually, the solution proposed by François Marier should work, but only
if you have one RAID array and this array is called md0.
A completely flexible and at the same time simple solution is to use the
function mountroot_fail located at /usr/share/initramfs-tools/scripts
/mdadm-functions, which
There is a similar solution mentioned here:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1196693,
which proposes to link /usr/share/initramfs-tools/scripts/local-
premount/mdadm - /etc/initramfs-tools/scripts/local-top/mdadm. Looks
like it's the simplest, but I'm not sure it
My problem (encrypted RAID1 drive refusing to boot when degraded) was
fixed by adding a new initramfs boot script to start the RAID array
before cryptsetup runs:
http://feeding.cloud.geek.nz/posts/the-perils-of-raid-and-full-disk-
encryption-on-ubuntu/
That's on 12.04.3.
--
You received this
*** This bug is a duplicate of bug 1003309 ***
https://bugs.launchpad.net/bugs/1003309
** This bug has been marked a duplicate of bug 1003309
Boot fails after installing updates, error: “cryptsetup: evms_activate is
not available
--
You received this bug notification because you are a
** This bug is no longer a duplicate of bug 1003309
Boot fails after installing updates, error: “cryptsetup: evms_activate is
not available
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251164
** Also affects: cryptsetup
Importance: Undecided
Status: New
** No longer affects: cryptsetup
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251164
Title:
boot impossible due to missing
I confirm behavior described by Teemu Toivola (vergo) in Ubuntu server 12.10.
After removing one (no matter which one) drive from RAID1 i got:
cryptsetup evms_activate is not available
Begin: Waiting for encrypted source device.
If Raid1 is valid (with both drives connected) initram asks
I am sorry I had to find out the same as Teemu for 12.04.1.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251164
Title:
boot impossible due to missing initramfs failure hook / event driven
Commenting here since bug #324997 has been marked as duplicate and the
behaviour appears to have changed since the original report. With Ubuntu
12.04, booting with a degraded raid (due to missing disk) causes the
boot process to stop at Begin: Waiting for encrypted source device...
There's a
Looking at the timouts suggested in Comment #15, I think they may actually be
realizable with modular scripts. A base rootdelay script, and separate mdadm
and cryptsetup sripts (that get called by their udev rules) can halt/extend the
regular rootdelay (exported variable? named pipe?), if
I believe the initramfs only sets up the rootfs, other partitions
(/home) are set up afterwards. If I remeber correct cryptsetup is called
by udev rules. In any case, that is the way it has to be, event driven,
to catch on upon (/home) devices appearing without polling loops and
sleep delays.
mdadm is event driven via udev. The special part in the initramfs is
the failure hook so that a degraded array will only be activated after a
timeout. I'm not sure if we want to auto degrade arrays post boot, but
I suppose if we did, we could move that logic from the failure hook to
the udev
On Mon, May 14, 2012 at 02:15:10PM -, Phillip Susi wrote:
mdadm is event driven via udev. The special part in the initramfs is
the failure hook so that a degraded array will only be activated after a
timeout. I'm not sure if we want to auto degrade arrays post boot, but
I suppose if we
Can't the udev rule fork and let the child wait for the timeout, then
activate the array degraded?
I think the source of my confusion is that upstart is bluring the line
between udev, which was designed to do event driven processing in
response to hardware detection, and conventional sysvinit,
The udev rules don't need to prompt, the cryptsetup that gets called
will prompt. Actually, these things work quite well in the normal
system. It seems preferable to me to adjust/improve the regular tools to
be usable in initramfs as well, rather then trying to script up and
maintain! another
Since udev already provides an event driven framework in
the initramfs, why add another one?
Hmm, if you would like to realize event driven init scripts, I believe
you may be able to rework the scripts from doing linear pre...post
things to just call a watchdog script that mostly sleeps and
If the udev rule calls cryptsetup, then it would be trying to prompt,
and so it can't do that.
What invokes cryptsetup in the normal system? Don't you have to do it
by hand right now if you hot plug a luks disk?
The order doesn't have to match the setup as long as they keep being
called as long
Cryptsetup has to be done via script rather than udev rule since it has
to prompt for input, and udev rules can't do that.
I think just two things need done to fix this:
1) cryptsetup needs a failure hook
2) try_failure_hooks needs to continue trying all failure hooks rather than
return as soon
** Branch linked: lp:~csurbhi/+junk/mdadm.fixes
--
boot impossible due to missing initramfs failure hook / event driven initramfs
https://bugs.launchpad.net/bugs/251164
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Description changed:
the cryptsetup package needs proper integration into the initramfs
failure hooks
The system must not assume a particular layered setup or sequence of
appearance of (hotplug/udev/crypt/md/degraded-md/lvm) devices.
It must be able to boot with any possible
** Also affects: mdadm (Ubuntu)
Importance: Undecided
Status: New
** Changed in: mdadm (Ubuntu)
Status: New = Confirmed
--
boot impossible due to missing initramfs failure hook / event driven initramfs
https://bugs.launchpad.net/bugs/251164
You received this bug notification
** Summary changed:
- boot impossible due to missing initramfs failure hook integration
+ boot impossible due to missing initramfs failure hook / event driven initramfs
--
boot impossible due to missing initramfs failure hook / event driven initramfs
https://bugs.launchpad.net/bugs/251164
You
Scott, I put you on here because from your upstart/mountall experience you may
well spot flaws and benefits in the design.
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/comments/15
--
boot impossible due to missing initramfs failure hook / event driven initramfs
25 matches
Mail list logo
