kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: rpjday@crashcourse.ca (Robert P. J. Day)
To: kernelnewbies@lists.kernelnewbies.org
Subject: want to clarify a couple things about initramfs
Date: Sun, 19 Jun 2016 09:55:11 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.20.1606190943310.7465@localhost.localdomain> (raw)


  for the first time, i'm going to dive into the kernel support for
initramfs, so i'll start with a couple questions.

  first, i note that the Doc file ramfs-rootfs-initramfs.txt seems(?)
a bit dated, in that it refers to the 2.6 kernel, but it may just mean
that it's relevant for 2.6 and everything newer, so it may be just
fine, i guess i'll find out eventually.

  next (and possibly a silly question), i know that the primary(?)
purpose of an initramfs is to load an early rootfs to get access to
kernel modules, after which one tosses away the initramfs and mounts
the "real" rootfs. but i'm pretty sure i have the right to build a
kernel with enough of an initramfs that i can run off that embedded
initramfs entirely out of RAM if all i want to do is, say, basic
diagnostics.

  next, from the Doc file, i see the possibility of a second
(external) initramfs:


External initramfs images:
--------------------------

If the kernel has initrd support enabled, an external cpio.gz archive can also
be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
will autodetect the type (initramfs, not initrd) and extract the external cpio
archive into rootfs before trying to run /init.

This has the memory efficiency advantages of initramfs (no ramdisk block
device) but the separate packaging of initrd (which is nice if you have
non-GPL code you'd like to run from initramfs, without conflating it with
the GPL licensed Linux kernel binary).

It can also be used to supplement the kernel's built-in initramfs image.  The
files in the external archive will overwrite any conflicting files in
the built-in initramfs archive.  Some distributors also prefer to customize
a single kernel image with task-specific initramfs images, without
recompiling."


  is all that still accurate? again, i'm sure i can confirm that once
i start digging through the code. in my case, i don't think i'll need
an external initramfs if i can cram everything i need into the one
embedded in the kernel.

  thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

             reply	other threads:[~2016-06-19 13:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-19 13:55 Robert P. J. Day [this message]
2016-06-20  1:05 ` want to clarify a couple things about initramfs Nathan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.20.1606190943310.7465@localhost.localdomain \
    --to=rpjday@crashcourse.ca \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).