[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

mount says an existing file system does not exist (was Re: strange booting behavior)



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 <aelschuring@hotmail.com> wrote:
> Hi,
>
>
>> On 5/19/15, Arno Schuring <aelschuring@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.


Reply to: