On Wed, 2010-04-21 at 11:52 +, ceg wrote:
> I can't tell if the metadata has been altered. Scott do the dd files
> contain data that looks altered or irregular in any way?
>
I wouldn't know how to tell that.
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
silently breaking raid: root rai
Just installed lucid beta2-alternate with luks on raid in virtualbox.
Guess what, all turning down of this seems to be based on false speculations.
If I boot the CD again in rescue mode after the install
* It wants to open all md member devices as luks and asks for passphrases for
each member.
*
I can't tell if the metadata has been altered. Scott do the dd files
contain data that looks altered or irregular in any way?
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Ubuntu
Bugs, which
I don't see anything to release note here. Scott has said the code
appears to do the right thing in lucid; the only counterexample given is
of a disk that has had its metadata irreversibly *altered* by a previous
version of util-linux in karmic. So we don't even really have a
confirmed bug here t
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
** 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.
+
+ -
Anybody tested if karmic to lucid upgrades work with raid_members
wrongly identified as luks?
Is there a ubuntu VM farm/cloud where test cases and bug replications
can be run?
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notifica
** Changed in: cryptsetup (Ubuntu)
Status: Incomplete => New
--
breaking raid: root raid_member 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 list
ubu
Does cfdisk (in lucid) deliberately show blkid output instead of types
given in the partition table? If so, would it make sense to show that
additionally not exclusively.
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification be
I got the beginning with
dd if=/dev/sdc7 of=raid-part-head bs=1M count=1
Fdisk etc. output with various units and "block sizes" but never stating the
actual unit sizes is a mess.
#blockdev --report /dev/sdc7
RORA SSZ BSZ StartSecSize Device
rw 256 512 512 19589667
On Sat, 2010-04-03 at 14:07 +, ceg wrote:
> I only have one of the luks on raid member drives left to examine (I
> reinstalled the system since I have no use for data corrupting raid
> setups and not unlimited disks available.), but I booted lucid beta1 CD
> and looked at that drive.
>
Could
Are newer blkid and cfdisk still probing the end of devices (older
metadata)?
--
breaking raid: root raid_member 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 mailin
Back on 9.10: cfdisk and fdisk see those partitions as raid and only
blkid gives luks (just as reported)
--
breaking raid: root raid_member 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 Ubun
At the same time "fdisk -l" output looks OK:
Disk /dev/sdc: 120.1 GB, 120060444672 bytes
255 heads, 63 sectors/track, 14596 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical / optimal IO): 512 bytes / 512 bytes
Device Boot Start End Blocks Id
(The sdc/sdd change was due to me disconnecting the USB drive in
between.)
--
breaking raid: root raid_member 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 l
I only have one of the luks on raid member drives left to examine (I
reinstalled the system since I have no use for data corrupting raid
setups and not unlimited disks available.), but I booted lucid beta1 CD
and looked at that drive.
The blkid output looks just the same as on 9.10 to me:
/dev/s
The lucid util-linux code looks right to me; it should report RAID over
LUKS since RAID is higher in the probe list, and the first successful
probe is returned.
If you can reproduce this problem on lucid, please re-open this bug
** Changed in: util-linux (Ubuntu)
Status: Confirmed => Fix R
Sorry, I was unclear: I did not try raid with lucid.
** Changed in: util-linux (Ubuntu)
Status: Incomplete => Confirmed
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Ubuntu
Bugs, whic
On Thu, 2010-04-01 at 22:59 +, ceg wrote:
> Yeah, it was a production karmic machine where this got in with update
> to 2.16-1ubuntu5.
>
So you *haven't* tried this with lucid?
Scott
--
Scott James Remnant
sc...@ubuntu.com
--
breaking raid: root raid_member opened as luks
https://bugs.lau
Can you confirm the behavior for 2.16-1ubuntu5?
Else:
As I reported the type was correctly reported as raid member upon (re)setting
the array up (while it was mounted). But on one of the subsequent reboots
things got changed around, and then blkid reported luks type (while it was
mounted as suc
Yeah, it was a production karmic machine where this got in with update
to 2.16-1ubuntu5.
I'm sorry, noticed I only mentioned that in the the issue that led to
adding this behaviour.
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug not
On Thu, 2010-04-01 at 21:18 +, ceg wrote:
> > blkid currently, deliberately, returns only the first detected RAID or LUKS
> > container
> > for a filesystem - with the checking order being raid first.
>
> Did someone change it already?
>
Not that I know of. blkid has been refactored, but t
> blkid currently, deliberately, returns only the first detected RAID or LUKS
> container
> for a filesystem - with the checking order being raid first.
Did someone change it already?
The issue I reported is actually the other way around. A RAID member
device partition (version 0.90 metadata, l
My understanding of this problem:
blkid currently, deliberately, returns only the first detected RAID or
LUKS container for a filesystem - with the checking order being raid
first.
This means if a partition has both a RAID and LUKS signature, it will
always be returned as RAID.
You request that
Agreed.
Cryptsetup can just use blkid (if available) to safety check if the user
or a buggy/incorrect script of his is not trying to open a RAID type
device.
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you ar
No, you're looking at it backwards. cryptsetup should not have to carry
any embedded information about what identifies a RAID container, that's
the responsibility of blkid. The bug is that the cryptsetup job is
*being called at all* for this block device.
--
breaking raid: root raid_member open
> Well, we can consider it a wishlist bug that 'cryptsetup isLuks' returns true
> in this case;
> fixing that isn't actually relevant to resolving the problem you're having.
As the cryptsetup init checks the device with "cryptsetup isLuks" it
would actually stop that raid desyncing (i.e. fix the
** Description changed:
Binary package hint: util-linux
After the member is opened as luks device it is booted instead of the md
device, while the raid remains "inactive".
I first noticed /proc/mdstat reported the root raid as inactive
(although the system seemed to run fine!).
finaly found that "cryptsetup isLuks" is actually used in
scripts/local-top/cryptroot line 236:
if /sbin/cryptsetup isLuks $cryptsource > /dev/null 2>&1; then
Please remember to have the bootscripts output messages about what they
are doing and their results to the (hidden) text console.
** Description changed:
Binary package hint: util-linux
After the member is opened as luks device it is booted instead of the md
device, while the raid remains "inactive".
I first noticed /proc/mdstat reported the root raid as inactive
(although the system seemed to run fine!).
concerning cryptsetup "wishlist":
Precautions like this show the level of safety and quality in
implementing basic OS operations. If cryptsetup would check the given
device before opening, this data loss would not occur now or any time
later if blkid, an admin or another script makes an error.
It
> Yes, your of course right, and if "cryptsetup isLuks" is itself scanning
> for a luks signature (without giving RAID precedence) it got the same
> bug.
Well, we can consider it a wishlist bug that 'cryptsetup isLuks' returns
true in this case; fixing that isn't actually relevant to resolving the
Cool, that I didn't know from the thread my search turned up about
blkid. (increases the bug weight though)
--
breaking raid: root raid_member 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 U
On Wed, 2010-03-10 at 11:34 +, ceg wrote:
> Upstream seems to generally refrain from prioritizing. There is of
> course the basic rule to return -1 (no type) if there are conficts, and
> no resolving rule applies.
>
Err, Ubuntu ships unmodified upstream code here (to which we are a major
con
My current conception: (WARNING)
Both blkid and "cryptsetup isLuks" misreport a raid_member as luks when
checking devices, but blkid correctly reports RAID if the device is set
up (mounted/active) in the system as intended (after
install/update/recover).
On boot what happens depends on the order
** Description changed:
Binary package hint: util-linux
After the member is opened as luks device it is booted instead of the md
device, while the raid remains "inactive".
I first noticed /proc/mdstat reported the root raid as inactive
(although the system seemed to run fine!).
Lets think some more of signature rules.
Crypt vs Container
-> any crypt should be lower then other containers (not fs) because whaterver
is in it wouldn't be visible or is random.
Crypt vs FS
<- old fs signatuers may have remained.
RAID vs LVM-LV
<- LVs never reside on RAIDs directly (alway
> it's still a bug in blkid. It's blkid that wrongly detects the LUKS
UUID on a device that's a RAID member.
Yes, your of course right, and if "cryptsetup isLuks" is itself scanning
for a luks signature (without giving RAID precedence) it got the same
bug. Can you rule that out / know for sure tha
On Tue, Mar 09, 2010 at 10:53:29PM -, Scott James Remnant wrote:
> Steve: why is this a bug in blkid? You yourself proposed the patch that
> whenever LUKS metadata is detected, it *always* returns LUKS.
Scott, AIUI this is a case where a given partition has both LUKS and RAID
signatures, and
ceg: I'm a little confused as to the devices involved here. Could you
provide the uncensored output of running "sudo blkid" on your system,
then point out to me which line you think is wrong
** Changed in: util-linux (Ubuntu)
Status: New => Incomplete
** Changed in: util-linux (Ubuntu)
Steve: why is this a bug in blkid? You yourself proposed the patch that
whenever LUKS metadata is detected, it *always* returns LUKS.
If we drop that patch, we'll have all the old bugs back again when
people added LUKS to a partition without clearing what was there before.
--
breaking raid: roo
> blkid (now again) returns TYPE="crypto_LUKS" for the raid member.
> I see this Bug set to invalid for cryptsetup, but as cryptsetup is
> determining $cryptsource (devices it waits for to appear) on its own,
> and isLuks wrongly reports raid members as being luks, I think this this
> is valid cry
Err, it happened again, reduncancy in the system is destroyed,
cryptsetup opened a raid member and it got mounted leaving the raid
incomplet/inactive:
md3 : inactive sda7[0](S)
blkid (now again) returns TYPE="crypto_LUKS" for the raid member.
When I run "su cryptsetup isLuks" on raid members or
>[cryptsetup] waits for the physical device to be available, decrypts it
as needed, then mounts it. No other event handling is required or
appropriate.
Think of the following example.
As far as I can see cryptsetup in initramfs is not called on the event
that a crypt device appears. It seems cryp
> including in initramfs?
The initramfs is always event driven. It waits for the physical device
to be available, decrypts it as needed, then mounts it. No other event
handling is required or appropriate.
> can you tell if "cryptsetup isLuks" correctly reports false for luks
on raid members?
S
>cryptsetup is event-driven in lucid.
good news!
including in initramfs?
can you tell if "cryptsetup isLuks" correctly reports false for luks on
raid members?
(or with what test command can I tell? This gives me nothing:
r...@localhost:~# cryptsetup isLuks /dev/hda7
r...@localhost:~#
)
--
brea
cryptsetup is event-driven in lucid.
** Changed in: cryptsetup (Ubuntu)
Status: New => Invalid
--
breaking raid: root raid_member 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:
Binary package hint: util-linux
- I noticed /proc/mdstat reported the root raid as inactive (although the
- system seemed to run fine!).
+ After the member is opened as luks device it is booted instead of the md
+ device, while the raid remains "inactive".
+
+ I first
** Summary changed:
- blkid reports root raid_member (on usb) as luks, which is booted while raid
remains "inactive"
+ breaking raid: root raid_member opened as luks
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification becau
48 matches
Mail list logo
