Am Mittwoch, 26. August 2015, 10:21:51 schrieb David Wright: > 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. No problem. This is /etc/fstab with which I can boot
------- snip --- # <file system> <mount point> <type> <options> <dump> <pass> and this is the form, it should be , but boot hangs: # <file system> <mount point> <type> <options> <dump> <pass> > > > 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?) Not quite, I mean, I am typing the characters of the encrypted partitions password and the sytem spontaneously goes on booting and asks of the next partition password. > > > 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. This is a longer story. Let me short explain. I installed kali-linux on a second drive. During this installation, the kali installer overwrote grub with its version. As I could not restore grub again, I decided to install debian on the first hard drive again. So I installed new, with the same partition structure as before - same size, same construct (/ and /boot unencrypted and /home, /usr and /var encrypted). The installation was unencrypted. When the system was up and running fine, I backuped all data from /home, /usr and /var to another computer via rsync. After this I encrypted /home, /user and /var, made ext4 filesystem as before and rsynced the data back. Finally I edited /etc/crypttab and /etc/fstab with the new UUID's, checked the mountpoints and did not forget to create a new initrd with added modules aes, dm-crypt, dm-mo and sha256. I have two more computers running exatly with the same construct. Both debian/testing and both show no errors. Alle computers get daily updates by me. > > > I am running debian/testing, 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. > I tried with both kernel versions, same results as before. IMO there are only crypttab and fstab as editable files involved or did I forget one? Thanks for the help, I really appreciate this!!! > Cheers, > David. Best Hans
