Quoting Hans (hans.ullr...@loop.de): > Yes, and I have new knoledges. I managed to get the debian startes with a > trick. > > First I changes the entry in /etc/fstab from example > /dev/mapper/usr to UUID=rz98u98127290502957whatever
Is there any reason not to post your /etc/fstab before and after the changes. I'm sure I won't be able to help with an encryption problem, but it might help others to see that information. > Then, at boot it is not possible to enter the complete password, as the > system is going > on to boot soon after the first letters were entered. > This behaves so at every partition. I find this difficult to follow. Do you mean you are typing the characters of the encrypted partition's password, and the system spontaneously reboots? (If so, the last sentence seems unlikely; how do you get ever past the first one?) > At last, I can get into the rescue console with CTRL-D. > Now I can manually open the partitions (cryptsetup luksOpen /dev/sda7) and > mount them correctly. > After this I exit the rescue console with CTRL-D again (to proceed with the > boot process) and > it is starting correctly. That's good. > the strange thing is, when I set /dev/mapper/usr into /etc/fstab, it will not > boot and hangs at the > point "scripts/local-blocks/", trying about 10 times, then stops with > initramfs error. > > Maybe the initramfs-tool might be defective, but I do not know. This system > is now running for several > years in this constellation, so I can not imagine, what has changed. Actually, I meant to start by asking you that. You have this dual- booting system and it's worked for years. Did this problem just happen one day when you switched it on, or were you making some changes after which you got this error. > I am running debian/testin, with kernel 4.1, but the same problem appears > with 3.16. Maybe the actual > initramfs-tool is buggy, but dunno. Er, that's something worth revealing in your first post. Cheers, David.
