Having used Startup Disk Creator with a 10.10BETA release acquired on
9/25/2010 i386 Desktop... I had this problem where the OS didn't
recognize the disk that had the LUKS encrypted drive. I had initially
installed 9.10 from the Alternate install CD.
Anyway - I'll try installing from the CD
If blkid reports two signatures for one device (LUKS + ext3/swap) it is
bug (introduced when old cryptsetup did not wipe old signature).
You cannot solve it updating to new cryptsetup version but you can use
new cryptsetup version to fix it.
Read
---
util-linux (2.16-1ubuntu5) karmic; urgency=low
* Always return encrypted block devices as the first detected encryption
system (ie. LUKS, since that's the only one) rather than probing for
additional metadata and returning an ambivalent result. LP: #428435.
might that
I think, I've encountered this bug in Debian squeeze too, but in a safe
way. I have 9 partitions on my desktop computer (P5QC) and only the UUID
of sda9 isn't detected. Fortunately, it isn't the root partition.
I've never installed Windows on this computer but formatted its hard
with etx3 from
I forgot to say that none of my partitions is encrypted. So, I think
this bug isn't especially related to encryption.
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi Martin,
I am also struggling with a system that wouldn't boot because this bug
affecting my home' partition which is not encrypted. I have been using Karmic
for a few weeks and suddenly the system wouldn't boot because of this. I tried
the python, but that doesn't help: Found the wanted
** Branch linked: lp:ubuntu/util-linux
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Martin-Éric and I are having a problem very like this one, but with non-
encrypted partitions. Our bug is definitely not resolved in Karmic. It
looks like we should be here: https://bugs.launchpad.net/ubuntu/+source
/util-linux/+bug/426027. Sorry for the confusion.
--
luks encrypted partition
Martin-Éric -- if you need a workaround, try adding
'GRUB_DISABLE_LINUX_UUID=true' to your boot parameters, and changing
'root=UUID=foo' to 'root=/dev/hda1' or whatever your boot partition
actually is. This allowed me to boot my machine (which doesn't have an
encrypted partition either) after
Ben Willmore [2009-10-29 16:42 -]:
Martin-Éric -- if you need a workaround, try adding
'GRUB_DISABLE_LINUX_UUID=true' to your boot parameters, and changing
'root=UUID=foo' to 'root=/dev/hda1' or whatever your boot partition
actually is. This allowed me to boot my machine (which doesn't
resolved for karmic, doesn't need to be included in the final release
notes.
** Changed in: ubuntu-release-notes
Status: Fix Committed = Won't Fix
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member
While I don't have an encrypted partition, I however encountered the
issue that blkid reports an ambivalent filesystem signature on my root
partition, which suddenly makes udev skip detection of this partition
and, as a result, fail to reboot. Trying to run Antti's script, it
reports having found
I've got a manual cryptsetup setup, with /dev/sda1 as encrypted
partition which has ext2. On the encrypted pseudo-partition
/dev/mapper/_dev_sda1 I have an ext3 filesystem.
Can I safely upgrade to karmic? Seems like this case is somehow special.
--
luks encrypted partition not detected
Shouldn't be a problem because you don't use uuids.
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Er, what do you mean by I do bot use uuids? UUIDs for what?
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
you can access partitions using the automounter UUIDs, e,g.
/dev/disk/by-uuid/some_long_number. This way you'll stumble over this bug.
Using the tradiional way - /dev/sdx# you don't get this problem.
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received
Nice to see that at last some sanity finally got in. I am a bit late
here, but I have another suggestion below. Skip to the end to avoid the
rant.
Context: FYI, yesterday I had to patch (live) the bootblock of a Debian
squeeze system that stopped to boot a few updates ago. It was a pain
This bug was fixed in the package util-linux - 2.16-1ubuntu5
---
util-linux (2.16-1ubuntu5) karmic; urgency=low
* Always return encrypted block devices as the first detected encryption
system (ie. LUKS, since that's the only one) rather than probing for
additional metadata
If we want to concentrate on the real problem, like David put it, then
we should look at udev. Udev is responsible of creating the /dev/disks
/by-uuid/ entries and it uses blkid to do so. Missing entries cause the
boot to fail with fully encrypted hard drives and udev is the first
failing step on
Peter Matulis [2009-10-21 0:30 -]:
Is it too dangerous to incorporate the intelligence of your Python
script into karmic's cryptsetup?
I'm not sure it is a good idea to attempt the conversion on the fly
while the file system is being mounted (i. e. during dist-upgrade).
I think what we
From the discussion with upsptream it became clear that blkid's current
behaviour is considered correct, and that trying to choose between
several signatures is a dangerous trait that shouldn't be kept any more.
So from the recent discussion I think that we should modify cryptsetup
and its
Martin: What do you mean by modifying cryptsetup? It's not causing
anything anymore on karmic.
Patching cryptsetup on hardy, intrepid and jaunty however to clear the
superblock of newly created partitions would be in order.
--
luks encrypted partition not detected or mounted automatically
If we accept upstream's position that blkid shouldn't pick one fs id
over the other (which I disagree with - this is a case where we clearly
know which of the UUIDs is the correct one, which is why we're talking
about autocleaning the superblock on upgrades, so why don't we just fix
blkid to DTRT
Opening a release notes task, since this information was lost when
362315 was marked as a duplicate and we definitely want this added to
the release notes.
** Changed in: ubuntu-release-notes
Importance: Undecided = Low
** Changed in: ubuntu-release-notes
Status: New = Triaged
--
Steve: I must be missing something here.. how do we know which UUIDs is
the correct one? Especially with removable media?
And yes, you could use the uuid parameter from root boot option and
patch blkid to force read the uuid's from every type of signature it
founds and then guess the right type
We discussed that in #ubuntu-release. Given how close karmic's release
is, we think this is a viable strategy:
(1) For karmic, patch blkid to prefer luks over ext*
Rationale: This has been the behaviour for years, and worked well.
We also know that creating a luks volume did not properly
For the record, I'm not really insisting on putting the migration stuff
into cryptsetup; if another package is more appropriate (like udev), I'm
fine with that as well, of course. I just thought that we don't need the
migration scripts on systems where cryptsetup isn't even installed.
--
luks
Martin: this happens also with swap and probably other FS' too. Simply
prefer over ext is not sufficient.
** Summary changed:
- luks encrypted partition not detected when it was created over an ext
partition
+ luks encrypted partition not detected
--
luks encrypted partition not detected
If you decide to patch blkid, make sure to test it darn well! This is
not just like reverting a patch or two on blkid and you have to be very
careful. blkid has not been used on previous releases to detect
partitions so you can't make any assumptions how patched blkid will be
performing compared
Antti Kaijanmäki [2009-10-21 8:44 -]:
Martin: this happens also with swap and probably other FS' too. Simply
prefer over ext is not sufficient.
So for karmic, we should perhaps just prefer it over anything else? Or
at least over swap and ext*? I think these two are the only ones that
truly
I declined the hardy/intrepid/jaunty nominations. I don't think that
there's anything to do there:
* In these releases, cryptsetup still was broken, but vol_id preferred luks
over other FSes, so it didn't manifest as a practical problem.
* Fixing cryptsetup in those releases can't be
Only reason for nominations was to make sure existing releases do not
create *more* broken superblocks, but if you plan to handle them
automatically in future releases then it doesn't really matter.
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this
As a first step, I created a script which exercises all combinations of
luks with ext2/ext3/ext4/swap/vfat.
This runs fine on current karmic, which shows that all the mkfs.* are
fixed now and we don't create further breakage with the karmic versions.
The script needs to run as root, and uses
Improved version which uses blkid -p if available (not yet on
hardy/jaunty, but on karmic).
I installed hardy's cryptsetup (2:1.0.5-2ubuntu12) on karmic, and as
expected the script fails now:
$ sudo ./test-luks-blkid.sh
*** test pair: luks/ext2 ***
ext2 luks /dev/ram0: ambivalent result
I hit this a few weeks ago when upgrading from Jaunty to Karmic beta, here is
the upstream I found:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541823
At the time I asked a few colleagues about it and no one had hit it so I
assumed something wrong with my own setup. My original setup was
Documented in https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview:
When creating LUKS encrypted partitions, some earlier versions of
cryptsetup did not wipe out any pre-existing filesystem metadata on the
partition. The current version of blkid used in the Ubuntu 9.10 RC will
refuse to export a
Copying from IRC, the rationale why it's reasonable to fix this in
blkid:
Given that no LUKS partition *can* be activated without external
configuration telling how to decrypt it (i.e.: /etc/crypttab), I think
in all cases it's safe to prefer LUKS over * if the alternative is
returning no UUID at
** Changed in: util-linux (Ubuntu Karmic)
Assignee: Martin Pitt (pitti) = Scott James Remnant (scott)
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
i.e.: the rationale for not guessing which signature to prefer is that
it's not *safe*. But LUKS is always safe, because this never goes any
further than a symlink under /dev unless something else on the system is
already configured to look for *that specific UUID* and treat it as a
LUKS device.
Scott uploaded the fix, see http://launchpadlibrarian.net/34100474/util-
linux_2.16-1ubuntu5_source.changes (in unapproved now).
I confirm that this makes the test script succeed again, and also works
with Steven Harms' image:
$ blkid -p /tmp/ext3-luks.img
/tmp/ext3-luks.img:
** Changed in: util-linux (Ubuntu Karmic)
Assignee: Martin Pitt (pitti) = Scott James Remnant (scott)
--
luks encrypted partition not detected
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So is someone working on fixing cryptsetup in karmic? I see the
importance is Undecided and is not assigned to anyone.
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
AFAIK there's nothing to fix for karmic. Karmic's cryptsetup is already
fixed as it clears the superblock of newly created partitions. It's the
old versions of cryptsetup that are broken and it might be a good idea
to patch them up for every release which still is officially supported.
Anyway IMO
Antti Kaijanmäki wrote:
AFAIK there's nothing to fix for karmic. Karmic's cryptsetup is already
fixed as it clears the superblock of newly created partitions. It's the
old versions of cryptsetup that are broken and it might be a good idea
to patch them up for every release which still is
I agree with Peter. The problem isn't that an old cryptsetup was used,
that worked fine with the older release. That's just the cause of the
problem. The real problem is that upgrading to Karmic will result in a
system that isn't bootable and difficult for non-technical people to
fix. I
Here's a version of the Python script that I slightly modified so that
it will run (at least the check part) in Jaunty. The difference is
that Jaunty's blkid doesn't recognize the -p parameter and the format of
the partition ID lines is slightly different. Same caveats as the
original.
**
Now that I thought to check it, Karmic's blkid reports its version so
that the version check in fix_superblock_jaunty.py will not work
correctly. So, DON'T USE fix_superblock_jaunty.py IN KARMIC. Probably
you shouldn't use it at all.
--
luks encrypted partition not detected or mounted
I updated my original script to handle removing of swap signatures. I
created the test image on jaunty with 16MB USB memory stick by first
using mkswap followed by luksformat.
Make sure to read comment #24 before using!
And no, this will not work in jaunty. It's easiest to download karmic
Does this fix the problem permanently?
I come from https://bugs.launchpad.net/ubuntu/+bug/446591 and my workaround
there had to be applied after each kernel update (after each initrd creation to
be exact if i am right).
--
luks encrypted partition not detected or mounted automatically
Gunni: Yes, after fix_superblock.py removes any bogus signatures the
partition is once again correctly autodetected permanently. You can
safely run
$ sudo fix_superblock.py check /dev/sdXN
from karmic live-CD and you should see it reporting multiple signatures.
If this is not the case then
As i can start my system (with my workaround changing cryptsetup to
/dev/sda1 instead of the default /dev/disk/by-uuid/xyz1234-...), can i
run the script from the booted system (real or recovery)?
--
luks encrypted partition not detected or mounted automatically
After reformatting my usb using cryptsetup in karmik, it works again
with a window popping up requesting for a password. Of course, it was
just a pendrive, but it proves that different version of cryptsetup in
Karmik was the problem.
--
luks encrypted partition not detected or mounted
Gunni:
I would not recommend touching the superblock of a partition which is in use
just to be safe, but in theory it should work. I would give it a try, but don't
blame me if something breaks, OK ;-)
jordlilin:
actually as stated in this report, the problem is cryptsetup versions prior to
Thx, it worked. To be a bit more safe i started in recovery mode and ran
the script, and now its fine again.
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which
** Summary changed:
- external harddrive (luks encrypted) will not mount automatically
+ luks encrypted partition not detected or mounted automatically
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received this bug notification
** Description changed:
- Binary package hint: gvfs
+ Some encrypted partitions which were created with older versions of
+ cryptsetup ( 1.0.7) are not detected anymore in karmic. The problem is
+ that older cryptsetup does not properly clean the superblock of the
+ partition and this might leave
** Description changed:
Some encrypted partitions which were created with older versions of
cryptsetup ( 1.0.7) are not detected anymore in karmic. The problem is
that older cryptsetup does not properly clean the superblock of the
partition and this might leave bogus filesystem
NOTE!
if you see:
Found 2 signatures on partition /dev/sdXN:
- ext3
- ext2
do not try to remove the signatures! Multiple EXT signatures are not a
problem.
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received
I've got this problem as well. I have a usb partition with LUKS and in
Jaunty cryptsetup 1.0.6 a window pops up asking for a password. In
Karmik nothing happens and I have to mount it manually with mount.crypt
(I seem to remember as I don't have my karmik machine in here now).
--
luks encrypted
Great Job.
I have got the same problem with my external crypted storage.
The Python script solve it.
Thanks a lot !
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs,
The python script worked for me, too.
Thanks
--
luks encrypted partition not detected or mounted automatically
https://bugs.launchpad.net/bugs/428435
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
61 matches
Mail list logo
