-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Djingo Cacadril wrote: > Ken Heard <[EMAIL PROTECTED]> 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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
