hi arno, thank you for your explanation.
i don't understand why i cannot mount the root partition. when it does not boot, it comes up with initrd busybox shell. i do cryptsetup luksOpen /dev/disk/by-uuid/[uuid] toshiba-root. this works. blkid shows that /dev/mapper/toshiba-root is there and is ext4. then i do mount /dev/mapper/toshiba-root /root. it says no such file or directory. (i also tried -o ro.) ls shows that /root is there. so the filesystem exists and the mountpoint exists. why is it saying no such file or directory? anybody have an idea here? On 5/20/15, Arno Schuring <aelschur...@hotmail.com> wrote: > Hi, > > >> On 5/19/15, Arno Schuring <aelschur...@hotmail.com> wrote: >> > >> > Note that you can add break=premount to the kernel cmdline >> > to force an initramfs shell, then use sh -x /scripts/$phase/$script >> > to manually step through the initramfs procedure. >> > >> > You can use "grep maybe_break /usr/share/initramfs-tools/init" to >> > check the valid break= values, and their order. >> >> stepping sounds like a great way to debug, but i'm out of my depth. i >> don't know what premount is (is that a phase? a script? something >> else?), or what initrd does (all i know is it's a ramdisk and has a >> fake root fs for some reason). i will of course be happy to try this, >> but i won't know what scripts to run, in what order, or what the >> results will mean. >> > > premount is just one of the breakpoints in the initramfs where you can > break out and get a shell. The init procedure is completely shell-based, > you may try reading /init lines 208-238 to get a feel for it. Basically, > every phase is represented as a directory in /scripts, and the order in > which the scripts are run is determined by a /scripts/$phase/ORDER file > in each directory. > > /scripts/local-top/cryptroot is probably the most interesting script for > you to run, and I don't think it has many dependencies since you're > not using lvm. But ORDER is itself a shell script as well :) > > Beyond that, I don't think I can be of much help. I only know about this > because I'm using a custom unlock procedure for my rootfs. I can't tell > you about the design of the initramfs, nor do I know if what I'm > advising here is the easiest way. > >> >> > Also, can you verify that /conf/conf.d/cryptroot exists >> > in the initramfs and contains the correct line? >> >> instead of rebooting to determine this and trying to transcribe it, is >> it ok to extract the initrd as it is on disk? i did so and got this: >> "target=toshiba-root,source=UUID="...",key=none,rootdev" (where "..." >> is the correct uuid according to blkid for /dev/sda3, which is the >> partition on which encrypted root resides). >> >> does that seem correct? > > yes, that should be correct. > >> >> >> in fact, in the initrd busybox shell, i can do cryptsetup >> >> luksOpen /dev/sda3 toshiba-root. i do not know how or where >> >> to mount it, however. mounting it on / not work. >> > >> > You need to mount it (readonly) on /root. Then exit the initramfs shell >> > and the boot should continue normally. >> >> on /root, as in the superuser's home dir for dot files etc.? > > Yes. There is no home dir in the initramfs. It's a bit counterintuitive, > but > it does make sense to mount the real root filesystem on /root. It's just a > shame that 'root' has more than one meaning. > > > Regards, > Arno > > -- I rarely can send email, and cannot be counted on to read email, but please feel free to reply. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cadyyg0mjftcjcp8hfqhrf4-m0kxqgr55iezw7y4zeyanhmx...@mail.gmail.com
