@ceg: thank you, I'm aware of that now. There are several howtos about simply
setting up ubuntu to send out emails using postfix and any gmail account so I
get all mdadm notification in my email.
also, I can confirm system doesn't boot with a degraded array (I added
Thank you for testing, Phillip!
Cryptsetup support should be on the CD. But it only seemed to run in the first
boot up stage of the rescue CD and used to try to open the raid members there,
even before you set up the raids with the debian installer.
Good that it does not do that any more.
I
@alfonso: mdadm monitor will send you an email if the raid can not be
set up completely (is degraded)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/531240
Title:
silently breaking raid: root
If you still have the vm setup, you could just try to boot the text
installer media again, enter the rescue mode and see how it wants to
mount the existing raid disks (not degraded, both present) in the vm.
That's where it used to always happen. Oherwise, only occasionally
during normal reboots.
When I try to boot the alternate cd in rescue mode, it gives me a screen
to choose the root fs, which has an option to activate raid arrays.
After activating the raid array, and selecting it, it tells me the mount
failed. It looks like rescue mode has no cryptsetup support at all, but
it isn't
Best way to reproduce the actual wrong opening seemed to be in a
virtualbox as in comment #42.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/531240
Title:
silently breaking raid: root raid_members
I used qemu-kvm. The disk partition was identified as a raid member and
bound to mdadm, the md array was identified as a luks member and bound
to dm-crypt. When trying to boot with one disk missing, the system
would not boot at all, which appears to be another bug ( mdadm won't
activate the
I tried to reproduce this with 12.04 and it seems that both blkid and
now cryptsetup both report the underlying raid component as such, and
not as a luks component, so I think it's time to put this bug to bed.
** Changed in: cryptsetup (Ubuntu)
Status: Confirmed = Fix Released
** No
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cryptsetup (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/531240
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: rescue (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/531240
Title:
Hi,
I'm using LUKS over a RAID6 array created with mdadm...
is this bug still existing?
When using luks encryption on top of software raid devices, it can eventually
break because linux_raid_member devices get opened directly as luks instead of
being assembled into md devices (Bug #531240),
The UUID of the filesystem created on a raid mirror is of course present
and identical on any member devices of the raid mirror mirror.
The raid member device (superblocks) are probably also all taged with
(another) UUID of the raid device they assemble, plus the device ID.
Mdadm seems to handle
@ceg, wont the uuid for the raid array be different from that of the
individual raid member device?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/531240
Title:
silently breaking raid: root
Just booted a 10.04 machine with root on lvm on on luks on raid with
an incomplete array.
It failed to degrade the array and boot of course because the mdadm
package is broken and unmaintained since years in ubuntu, but what is
relevant here is the cryptsetup prompt that showed before failing
Thank you for helping to track this down.
So the superblock on the member that got mis-opened appears to have been
overwritten. Maybe by writing/using to the opened luks device that
thought the full partition is used by luks, without respecting the room
of the raid superblock at the end of the
Importance was set to wishlist for cryptsetup, could you please
revisit that with the new findings in mind?
--
silently breaking raid: root raid_members opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Ubuntu
Bugs, which is
No. It's still a wishlist request on cryptsetup for the reasons already
stated, and the util-linux bug does not exist in lucid.
--
silently breaking raid: root raid_members opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of
I would not thing blkid (util-linux) has altered the metadata on disk.
As it got altered blkid may actually never have (occasionally)
misreported anything to cause the behaviour. (The util-linux bug may not
have exsted in karmic nor lucid.) I have seen blkid reporting raid
correctly after
I'd suggest to make cryptsetup isLuks check with blikid prior to probing the
luks header (and have it report errors), as the next step in finding/fixing the
root cause and reestablishing trust in using luks on raid.
--
silently breaking raid: root raid_members opened as luks
On Tue, 2010-04-27 at 11:21 +, ceg wrote:
Can we be sure that blkid ever had a time when it would actually
(occasionally) misreport luks on raid as luks in karmic?
I don't think so; reading the code history, blkid has always tried to
report RAID before LUKS - however this may have been
ceg was able to provide me a copy of the front and back 1MB of his block
device. Having carefully looked through it, I cannot see what this bug
is about.
The block device given to me is LUKS encrypted with no RAID metadata.
** Changed in: util-linux (Ubuntu)
Status: Confirmed = Invalid
** Changed in: ubuntu-release-notes
Status: New = Invalid
--
silently breaking raid: root raid_members opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
** Also affects: rescue (Ubuntu)
Importance: Undecided
Status: New
--
silently breaking raid: root raid_members opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Description changed:
Note:
When using luks encryption on top of software raid devices, it can eventually
break because linux_raid_member devices get opened directly as luks instead of
being assembled into md devices (Bug #531240), and all this happens silently
because mdadm monitoring
** Description changed:
- Binary package hint: util-linux
-
- When using luks on top of software raid devices, linux_raid_member
- devices can get opened as luks instead of being assembled into md
- devices. It is adviseable not to use luks on raid since some updates
- introduced in karmic and
** Summary changed:
- breaking raid: root raid_member opened as luks
+ silently breaking raid: root raid_members opened as luks
--
silently breaking raid: root raid_members opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of
26 matches
Mail list logo
