My USB (/dev/sdc1) disk is not yet there when, earlier in the boot process, it is checked to be assigned by cryptsetup. So, the corresponding /dev/mapper/foo is not created. After booting I am able to use cryptsetup to create /dev/mapper/foo. I also have another normal hd partition using cryptsetup and that one works perfectly as expected.
Created attachment 146373 [details] emerge --info
that is why the script will keep checking over and over ... once the usb device settles, cryptsetup should find it just fine just dont cancel the cryptsetup process until the usb disk is available
(In reply to comment #2) > that is why the script will keep checking over and over ... once the usb device > settles, cryptsetup should find it just fine > > just dont cancel the cryptsetup process until the usb disk is available > Sorry, but what do you mean by the "cryptsetup process"? Earlier during the boot process, it is claimed that /dev/sdc1 does not exist (can't remember the exact message - I am on my laptop now). Later, by the end of the boot process, it says something like "some devices were not mapped". After the boot process ends, the mapping device is never created. I need to create it manually.
what does your /etc/conf.d/cryptfs look like ? if you set "remdev" properly, the cryptfs hook will loop over and over trying to find the device until you tell it to stop
(In reply to comment #4) > what does your /etc/conf.d/cryptfs look like ? if you set "remdev" properly, > the cryptfs hook will loop over and over trying to find the device until you > tell it to stop > target=C-usb remdev='/dev/disk/by-id/usb-...-0:0-part1' source='/dev/disk/by-id/usb-...-0:0-part1' #remdev='/dev/sdc1' #source='/dev/sdc1' key='/dev/fd0/foo' The device is connected an power on Console boot: loops forever { Please insert the removable device for C-usb removable device for C-usb not present Abort(yes/no) no } Answering yes completes the boot process but didn't create C-usb. BTW, in general shouldn't the cryptsetup command be issued only when I power on the device? What if I used a pen drive for example? Shouldn't it be issued only at the time I insert the pen? Thanks.
if cryptsetup says it isnt present, then that's because it isnt at the time cryptsetup is running. edit the dm-crypt-start.sh file in /lib/rcscripts/addons/ and you can see dm_crypt_execute_volumes(). as for hotplugging, that is not what the cryptsetup scripts are designed for. feel free to write something along those lines.
(In reply to comment #6) > if cryptsetup says it isnt present, then that's because it isnt at the time > cryptsetup is running. If you mean the drive is not physically there or is disconnected, no. It is there, connected and powered. Besides, when the boot process ends I can immediately issue a cryptsetup command. So there must be a bug somewhere ... May be the needed USB modules are still not loaded at that time ... > ... > as for hotplugging, that is not what the cryptsetup scripts are designed for. > ... That's OK. Since the drive I referred is used mainly for backups, the startup scripts are not very useful to me. So I wrote a little mount script to properly mount/unmount this drive.
it doesnt matter if it's plugged in, it matters if the kernel/udev detected and processed it properly cryptsetup is not related in anyway to the device node creation ... if it doesnt exist, that isnt cryptsetup's problem edit the function in question and try putting some `ls` statements in the for loop
I'll chime in late here Ben (strerror) the maintainer of cryptsetup and the person that wrote this support. It's a known issue that hotplugging does not work and won't work. I can't remember the bug # but it's mentioned there and I believe it was closed since that would require monitoring of plugging in of devices which was deemed outside the scope of this. You might want to look at HAL + gnome-volume-manager + gnome-mount, I know for a fact that combo supports this and does the right thing. HAL + ivman is a possibility and I would also expect HAL + KDE 3.5.8 or 4.0.x to do the right thing. This is just something that the boot scripts can not and will not support. Targeting the bug as such.
i dont think this is a hotplugging issue ... udev should create an appropriate symlink for the device when it's plugged in and assuming the symlink is the same as in the configuration file, things work
