Summary says it. If remdev isn't defined, it'll look for it. Same if something goes wrong and the user requests a find.
Created attachment 128926 [details, diff] dm-crypt-start.sh-keyfind.patch
I don't understand what you mean by if remdev isn't defined it'll look for it, the 'if [ -n "$remdev" ];' clearly only executes if it IS defined. I'm also uncertain what you mean by if the user requests a find. Can you explain what you mean here please.
(In reply to comment #2) (I'm away from a linux box and will be for some time,but I'm quite sure:) it's simple: if you don't define "remdev" in your config file, but if you define "key", it'll try to guess the remdev by looking to the "usual" devices. With the patch you get a 'elif [ -z "$remdev" ];' test for that.
Oh I fo(In reply to comment #2) > I'm also > uncertain what you mean by if the user requests a find. I forgot to explain this. If it happens during boot that the user isn't able to boot with a certain $remdev, the message displayed now gives the option to the user to change to auto find (temporary, it doesn't change the configuration).
(In reply to comment #4) > I forgot to explain this. If it happens during boot that the user isn't able to > boot with a certain $remdev, the message displayed now gives the option to the > user to change to auto find (temporary, it doesn't change the configuration). This patch doesn't work for me as it is (haven't got the time to debug it). I like the idea of what you are doing but the current implementation doesn't work if for example you define a key on a USB stick and boot without that usb key in, it will prompt for auto scan or for you to specify. If you ask it to auto detect it doesn't work, if you specify the device, eg /dev/sda1, then it finds it but doesn't break out of the loop correctly not allowing you to mount that mountpoint. Submit a new patch against the new dm-crypt-start.sh I'm about to put in cvs.
(In reply to comment #5) > Submit a new patch against the new dm-crypt-start.sh I'm about to > put in cvs. I can't, I'm away from home for a semester and don't have a gentoo laptop. I noticed that behaviour, but I thought it was some kernel problem. Either way the autodetection works in the normal case, it should be easy to correct no?
Reassigning back to herd since Benjamin has retired as a Gentoo developer (#89719).
Created attachment 163583 [details, diff] new patch w/ problem solved So I returned a few months ago to my desktop and I solved the problem, it was the removal of the mount dir of the key that was causing it. Unfortunately I see you updated the file. This is for the old version. Made a new patch considering most updates, but (see new attach comment):
Created attachment 163585 [details, diff] same as before but for latest dm-crypt There are some lines here I didn't update since it would require a complete rewrite. I don't see these changes as important, it does remove the new timer feature. Since these were changes of the maintainer, could you merge them? If I get the time I'll finish, but not soon.
I just tested the currently available script. This new timeout feature can be ignored, 99% of the times the script doesn't find the key it's because it's in a new address, and this solves it. So please patch current 1.0.6-dm-crypt as it is.
