Re: "Could not stat resume device file"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Djingo Cacadril wrote:
> Ken Heard <ken@heard.name> wrote on Saturday, September 20, 2008 4:14:59 PM
>>> Ken Heard skrev:
>>>> When I boot up any box with encryption activated for a partition in
>>>> it, the following message is received at the beginning of the boot
>>>> process, or soon thereafter:
>>>>
>>>> Begin: Running /scripts//local-premount ...
>>>> resume: libgcrypt Version 1.2.3
>>>> resume: Could not stat the resume device file
> [snip]
>> This device file in fact does exist. I am able as route to stat it
>> successfully; consequently I cannot understand why the start-up process
>> cannot stat it.
>
> During boot, at first /dev does not exist and is created empty, then populated.
> It appears something goes wrong here.
>
> The following is taken from memory, from working with Fedora systems some
> time ago. I now run Debian, so I may be mixing things up a bit.
>
> Most systems load an "initrd", an initial ram disk, imediately after loading the kernel.
> This initial ram disk contains a script (iirc, "/linuxrc") which controls the actions until
> the actual hard disks have been mounted. The file system that will become the root
> file system is first mounted in a subdirectory of the ram disk. a second ram disk is created
> and mounted as /dev, and populated with device files as devices are discovered.
> Then the mount points are "rotated", the real root becomes "/", and the initrd becomes
> a subdirectory. Then the 'init' program (/sbin/init in the real root) is started, and runs
> according to /etc/inittab in the real root. This file contains the command labeled
> "sysinit". On my debian system the inittab line is
>
> si::sysinit:/etc/init.d/rcS
>
> but other distributions use other file names. The command, /etc/init.d/rcS in my case,
> is responsible for continued setup. The <initrd>/dev mount point is moved onto the
> new root and at some point the initrd is unmounted and the ram reclaimed.
>
> Let that be enough to tip you off. Find out what applies to your system.
> Unpack the initrd somewhere and look at the /linuxrc script. (The files /boot/initrd*
> are cpio archives, and you may need to install cpio to unpack them.)
> Be aware that on Fedora, linuxrc is not a bash script, but "nash", so watch
> out for differences. Since you did not know the meaning of "stat", I fear
> that you will find this journey quite long and ardous. However, unless somebody
> shows up with specific knowledge about your encrypted file system solution,
> I do not know anything better.
First, as far as "stat" goes, up to this point I had no need to know
what it means; as I never had any occasion to use the "stat" command. I
now know that "stat" is geekspeak for status, and the command first
determines whether a file exists. If it does not, the command says so.
If the file does exist, the command give information about it.
Also, in geekspeak "stat" has become a verb, meaning provide the status
of a file. Used negatively, as in "cannot stat" it means that the file
searched for does not exist.
Second, I appreciate Djingo Cacadril's explanation of how the boot
process creates mount points and mounts partitions.
Finally, it strikes me that the process of establishing encryption for
some partitions -- in my case /home -- should not be asking the sort of
question at such an early stage in the partition set-up process. I
consequently think that I am dealing with something that should be a bug
rather than a fault in my computer boot process. If so, a bug report
should be filed, if not already done so. Do others have any contrary
opinions?
Regards, Ken Heard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjgihwACgkQlNlJzOkJmTfnDACZAYo0UxtcEHTCgdCLWp7NCVio
SckAn2ku48TtdmJK0hvZKirP3qmcMS8O
=dZds
-----END PGP SIGNATURE-----
Reply to: