Booting iamben's install-amd64-minimal-20180529.iso image, I get an unexpected result using cryptsetup from the install environment, as noted below. This doesn't happen when using iamben's older install-amd64-minimal-uefi-20180207.iso. (I'm using these for UEFI installs, in particular for VMs, as sysresccd doesn't boot on KVM/OVMF.) Steps: 1. Create minimal VM with one disk, booting using the noted media. 2. Prepare the disk with one 512M ESP partition and one Linux partition covering the remainder of the disk. 3. Run "cryptset luksFormat" on the Linux partition. ------------------------------------------------------------------------------ Please report any bugs you find to https://bugs.gentoo.org. Be sure to include detailed information about how to reproduce the bug you are reporting. Thank you for using Gentoo Linux! livecd ~ # sgdisk --zap-all /dev/sda Creating new GPT entries. GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. livecd ~ # sgdisk --clear /dev/sda Creating new GPT entries. The operation has completed successfully. livecd ~ # sgdisk -n 1:2048:+512M -t 1:ef00 /dev/sda The operation has completed successfully. livecd ~ # sgdisk -n 2:$(sgdisk -F /dev/sda):$(sgdisk -E /dev/sda) -t 2:8300 /dev/sda The operation has completed successfully. livecd ~ # sgdisk --change-name=1:efi0 --change-name=2:root0 /dev/sda Setting name! partNum is 0 REALLY setting name! Setting name! partNum is 1 REALLY setting name! The operation has completed successfully. livecd ~ # cryptsetup luksFormat /dev/sda2 WARNING! ======== This will overwrite data on /dev/sda2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: System is out of entropy while generating volume key. Please move mouse or type some text in another window to gather some random events. Generating key (75% done). Generating key (93% done). Generating key (93% done). Generating key (100% done). device-mapper: remove ioctl on temporary-cryptsetup-10282 failed: Device or resource busy ------------------------------------------------------------------------------ There's nothing in dmesg indicating an error, following this. I'll be happy to supply more data as we determine what would be useful.
For ease of reproduction: sgdisk --zap-all /dev/sda sgdisk --clear /dev/sda sgdisk -n 1:2048:+512M -t 1:ef00 /dev/sda sgdisk -n 2:$(sgdisk -F /dev/sda):$(sgdisk -E /dev/sda) -t 2:8300 /dev/sda sgdisk --change-name=1:efi0 --change-name=2:root0 /dev/sda cryptsetup luksFormat /dev/sda2 cryptsetup luksOpen /dev/sda2 lukssda2 pvcreate /dev/mapper/lukssda2 ...
Identical result with a freshly-downloaded, vanilla install-amd64-minimal-20180717T214502Z.iso and a legacy BIOS install: livecd ~ # cryptsetup luksFormat /dev/sda2 WARNING! ======== This will overwrite data on /dev/sda2 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: remove ioctl on temporary-cryptsetup-10797 failed: Device or resource busy
Looks pretty similar to this upstream issue: https://gitlab.com/cryptsetup/cryptsetup/issues/38 Gleaned a few things from reading that-- It's related to udev & locking somehow It doesn't seem to be fatal-- still returns 0/success
It does appear to be cosmetic. Despite the error message, I am able to go ahead and unlock the provider and use it.
Evidently it's not just install media. Here's a test from my build box: ------------------------------------------------------------------------------ root@gbuild /root# dd if=/dev/zero of=/testvol bs=1M count=20 20+0 records in 20+0 records out 20971520 bytes (21 MB, 20 MiB) copied, 0.0609034 s, 344 MB/s root@gbuild /root# losetup --find --show /testvol /dev/loop0 root@gbuild /root# cryptsetup luksFormat /dev/loop0 WARNING! ======== This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: device-mapper: remove ioctl on temporary-cryptsetup-4015 failed: Device or resource busy root@gbuild /root# cryptsetup luksOpen /dev/loop0 luksloop Enter passphrase for /testvol: root@gbuild /root# pvcreate /dev/mapper/luksloop /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. Physical volume "/dev/mapper/luksloop" successfully created. ------------------------------------------------------------------------------ The error messages from pvcreate are expected and unproblematic. Please ignore. Included for completeness.
Comparing the non-working installcd to a working setup, I see a major difference is whether udev is able to be used. I think this boils down to USE=-udev on cryptsetup.
I'm in error - I just tested it, and the February media *does* show the cosmetic error too.
I rebuilt cryptsetup to include the udev USE flag, and the cosmetic error no longer appears: root@gbuild /root# rm /testvol root@gbuild /root# dd if=/dev/zero of=/testvol bs=1M count=20 20+0 records in 20+0 records out 20971520 bytes (21 MB, 20 MiB) copied, 0.0469951 s, 446 MB/s root@gbuild /root# losetup --find --show /testvol /dev/loop0 root@gbuild /root# cryptsetup luksFormat /dev/loop0 WARNING! ======== This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: root@gbuild /root#
Created attachment 540136 [details] cryptsetup output from installcd Here is the non-working cryptsetup output from installcd where it's built with USE=-udev
Created attachment 540138 [details] cryptsetup output from working env Here is the cryptsetup output from a full gentoo environment where it's been built with USE=udev enabled
@base-system: do you think we can set IUSE=+udev on cryptsetup? This current bug will affect both installcds AND anyone picking a base profile w/o global USE=udev.
I am not sure if bug from $URL is related to this: Upstream bug seems to result in a fatal error. I.e. whatever user tried, failed. According to our bug report, requested action will succeed. On my own systems where I use LUKS to encrypt complete system I haven't enabled "udev" USE flag for cryptsetup package and haven't experienced any issues yet. What do we get if we will turn on linking against UDEV all the time? Like shown, cryptsetup does not *need* UDEV. Am I missing the problem or any strong benefits aside a warning the UDEV cannot be used (which is expected)?
Agreed, I no longer think that the upstream link is directly related to the current failure. The problem is that the output, in my opinion, indicates failure. I don't know if there are any longterm consequences to ignoring that behavior. On your working setup, do you have USE=udev set on lvm2?
Well, for lvm2 package I have "udev" USE flag enabled because package is enabling that USE flag by default. Like Mike (floppym) said in IRC, I would support a request for a profile change to enable "udev" USE flag by default for any Linux profile. Back to question if we should change cryptsetup's IUSE from "udev" to "+udev": The only argument to do that change is that IUSE defaults should represent upstream defaults and upstream seems to always build with UDEV support. For me, this is a strong argument. People who don't care/want small system are supposed to disable it on their own.
As I'm sure you've seen on the ML, I'm pursuing the profile change =) If that doesn't happen, I do think we should +udev this anyway. To match upstream defaults yes, but also to match related packages (eg lvm2) which already have +udev.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92e5412ed2f4b79c97e0f381dad9f53bc6ec416d commit 92e5412ed2f4b79c97e0f381dad9f53bc6ec416d Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-07-20 19:55:40 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-07-20 21:38:02 +0000 sys-fs/cryptsetup: Enable "udev" USE flag by default Bug: https://bugs.gentoo.org/661584 Package-Manager: Portage-2.3.43, Repoman-2.3.10 RepoMan-Options: --force sys-fs/cryptsetup/cryptsetup-1.7.5-r1.ebuild | 126 ++++++++++++++++++++++++++ sys-fs/cryptsetup/cryptsetup-2.0.3-r1.ebuild | 128 +++++++++++++++++++++++++++ 2 files changed, 254 insertions(+)
Assigning back to Ben, base-system has done everything requested. Feel free to close or assign to someone else.
Thanks, fixed in install-amd64-minimal-20180722T214501Z.iso, closing
