> David Witbrodt <email@example.com> writes:
> >(My goal was to
> >produce a kernel that boots without an initrd; most people will not
> >share that goal.)
> I would have thought that most people would share that goal, since
> building an initrd is useful for only two reasons I can think of:
> 2) You have a complex method of getting the root filesystem mounted -
> perhaps encrypted LVM on top of a network block device, etc, etc, etc.
I use a simple (relative to your example, at least) setup, with an
unencrypted boot and everything else on top of LVM on top of an
encrypted PV. Is there some way to do this without an initrd? The docs,
such as they are, generally recommend using an initrd for booting from
encrypted storage, even when not dealing with the sort of complexity
you describe, e.g.:
> Since most people who are building their own kernels probably do not
> have either of these requirements, building without an initrd would
> make things a lot simpler.
> I looked into building an initrd with my kernel builds, but it just made
> things more complicated and I could not see the point.
> Is there some other reason to use an initrd when building your own
> customized kernels?
suspend / resume from disk should really be done via an initrd; from
(c) The kernel should be configured with CONFIG_BLK_DEV_INITRD=y, which
will allow you to run the resume binary out of an iniramfs/initrd image.
[It is possible to use the suspend tools without any initramfs/initrd
images, but it's dangerous and will not be documented here.]
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Archive: email@example.com" >http://firstname.lastname@example.org