Bug 12151

Results:

§ several drak tools naturally fail; NFS and SMB sharing, start configuration...

§ without interfering it rebooted sucessfully, but the old kernel.
= system is useable, and a suitable update can probably repair it.

Thierry?

still valid drakxtools-16.18-2.mga4 ; on a real machine, my Thinkpad R61, same partitioning:
§ /boot
§ encrypted partition LVM containing /, /home,  swap

# diskdrake
Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 258.
Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 296.
device-mapper: table ioctl on crypt_sda5 failed: Enheten eller adressen finns inte
Command failed
INTERNAL ERROR: unknown device mapper/crypt_sda5
MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:186
devices::entry() called from /usr/lib/libDrakX/devices.pm:201
devices::make() called from /usr/lib/libDrakX/fs/type.pm:276
fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:284
fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fs/dmcrypt.pm:144
fs::dmcrypt::_get_existing_one() called from /usr/lib/libDrakX/fs/dmcrypt.pm:103
fs::dmcrypt::_get_existing_one_with_state() called from /usr/lib/libDrakX/fs/dmcrypt.pm:43
fs::dmcrypt::read_crypttab_() called from /usr/lib/libDrakX/fs/dmcrypt.pm:49
fs::dmcrypt::read_crypttab() called from /usr/lib/libDrakX/fsedit.pm:86
fsedit::dmcrypts() called from /usr/lib/libDrakX/fsedit.pm:296
fsedit::get_hds() called from /usr/libexec/drakdisk:74

# cat /etc/crypttab
crypt_sda5 UUID=5ee6a003-cbf4-4f8a-a653-4851e53bc126

# cat /etc/fstab
/dev/vg-mga/root / ext4 acl,noatime 1 1
# Entry for /dev/sda1 :
UUID=783df074-71a1-41c7-9d45-53f687bf485d /boot ext4 noatime,acl 1 2
/dev/vg-mga/home /home ext4 acl,noatime 1 2
none /proc proc defaults 0 0
/dev/vg-mga/swap swap swap defaults 0 0

Assignee: bugsquad => thierry.vignaud
Source RPM: (none) => drakxtools-16.18-2.mga4

Created attachment 4741 [details]
picture of log when running dmsetup failed for drakdisk

Created attachment 4742 [details]
picture of booting, see comment

As seen on picture: during boot it manages to open encrypted LVM, mount contents, then complain.

# systemctl status systemd-cryptsetup@crypt_sda5.service
systemd-cryptsetup@crypt_sda5.service - Cryptography Setup for crypt_sda5
   Loaded: loaded (/etc/crypttab)
   Active: activating (start) since ons 2014-01-08 11:57:19 CET; 10min ago
     Docs: man:systemd-cryptsetup@.service(8)
           man:crypttab(5)
 Main PID: 2325 (systemd-cryptse)
   CGroup: /system.slice/system-systemd\x2dcryptsetup.slice/systemd-cryptsetup@crypt_sda5.service
           ââ2325 /usr/lib/systemd/systemd-cryptsetup attach crypt_sda5 /dev/disk/by-uuid/5ee6a003-cbf4-4f8a-a653-485...

As an effect (of dracut not working?) this machine now since updates also have compatibility problem with kernel versus graphics driver and virtualbox module versions. :(

I've not much experience with crypted partitions.

CC: (none) => mageia, pterjan, thierry.vignaud
Assignee: thierry.vignaud => bugsquad

could be b/c they're several soft links to the same devices and the one in /etc/cryptab differs from the one used after ("mapper/foobar" vs "foobar").

I would guess it is not named /dev/mapper/crypt_sda5
IIRC it should be a symlink to /dev/dm<something>

Can you also add the content of /etc/mdadm.conf?

I have no idea how things are done nowadays, I have never touched dracut or systemd :(

So dracut should copy/use the /etc/crypttab and thus bring it up as /dev/mapper/crypt_sda5. If it doesn't it would bring it up as /dev/mapper/luks-$UUID

I've got a similar-ish VM somewhere I'll update it and see if I can reproduce.

thanks guys for looking into this

/etc/mdadm.conf does not exist

While you have loaded this landscape in your brain, i suggest a couple more exercises ;)


Bug 12033 : make an encrypted logical volume inside a LVM, and later try to remove it.


Also check it can create and remove a encrypted regular physical partition.


Also a question, can it resize an encrypted logical volyme correctly nowadays?  I remember it had some problem when i tried a couple years ago.



  I would be very grateful if the issues can be solved :)

I also now and then get the KDE systray informational popup saying:

Broadcast message from root@bamse (Fri 2014-01-10 09:36:55 CET): Password entry required for 'Please enter passphrase for disk Corsair_Force_GT (crypt_sda5)!' (PID 21560). Please enter password with the systemd-tty-ask-password-agent tool!

Closing then

Status: NEW => RESOLVED
Resolution: (none) => FIXED

@TV did you mean to close this one?

Yes. Isn't it fixed?
If not, sorry

(In reply to Thierry Vignaud from comment #15)
> Yes. Isn't it fixed?
> If not, sorry

I don't see any comments relating to it being fixed but perhaps I missed something?

Maybe my comment 12 was misunderstood.
I meant to report a side effect (or possible another bug).

Except for diskdrake and related tools like dracut the system is working and runs on /, swap, /home logical LVM partitions inside the encrypted partition.

Still not working after todays updates.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Created attachment 4774 [details]
log of update where it think it need password

Another effect of the same problem: update triggered a bunch of:
"
Password entry required for 'Please enter passphrase for disk Corsair_Force_GT (crypt_sda5)!' (PID 15380).
Please enter password with the systemd-tty-ask-password-agent tool!
 "

Webmin see it, and use the form
Device file	/dev/vg-mga/home

I just setup a test VM installing with the same layout from the final x86_64 iso.

Installed same disk layout + GNOME.
After first boot, I installed updates, including new kernel.

All went smoothly and reboot also worked fine.

Can I ask if in your testing you've done a fresh install or if this is continually being upgraded?

I suspect the problem stems from an invalid dracut initrd fixed some time ago. It wouldn't use the crypttab properly and would ultimately startup the luks under a different name. THe system could then misbehave.

This is now resolved (I fixed it just before this bug was posted, but it may have taken a while to get into the ISO etc. and thus the fix wouldn't come in until later), as a result, you may have a /dev/mapper/luks-* device instead and can't really escape from using it, even if your cryptab refers to a different device.

I suspect a fresh install from latest ISO would be fine and not encounter this problem.

Thank you Colin

final iso available already?

Ah, nice, I take your word that fresh installs should work now.


The system where i initially encountered the bug was a mga2 system x86_64, upgraded using mga4-beta2 DVD.

Then i tried a fresh install in a virtualbox VM, (see bug description) but had time to post this bug only a few days after.
- so probably just before your fix.



What about upgrading asystem (mga2 or 3) which have this layout (encrypted LVM containing /home and more)
I guess they are locked into this bug, or is there a workaround?
Should there be a notice in the errata maybe?

Related: https://bugs.mageia.org/show_bug.cgi?id=12070#c6

In reply to my comment 21:

I made a sucessfull reinstall on a system that had /, /home, swap on LVM on a luks partition, separate /boot.

(mga4 installer unlocked the encrypted partiton with the key i gave, and the LVM  tab then appeared)

I reformatted all but /home

Full OK.  Closing fixed.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED