Bug 139981 - initrd created with ext2 fails
Summary: initrd created with ext2 fails
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd   
(Show other bugs)
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-19 00:57 UTC by rich turner
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 18:18:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description rich turner 2004-11-19 00:57:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114

Description of problem:
i dont use mkinitrd to create an initrd. apparently it is using
initramfs and cpio now. the initird that i have created is on an ext2
filesystem and has always worked in the past with previous versions of
fedora core, as well as all other distributions.

now, when i create an initrd it is failing. here are the boot-up messages:

kernel is executed ...
RAMDISK: uncompressed image found at block0
VFS: Mounted root (ext2 filesystem)
Freeing unused kernel memory. 144k freed
Kernel panic - not syncing: No init found.

From these messages, it looks like it found an initrd and actually
mounted it. But it doesnt look like it was able to execute it.

Why dont old-school initrd's work with fedora core 3 anymore?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create an ext2 filesystem with all files needed to run linuxrc on a
loop device
2. unmount the loop device 
3. gzip the loop device to a file
4. change lilo to use that initrd


Actual Results:  booted the system using new initrd and got a kernel panic

Expected Results:  expected to see the linuxrc executed, loading
modules, and so forth

Additional info:

Although I must say that the real process is handled from with Storix,
and the stmakeboot process.

Comment 1 rich turner 2004-11-19 01:00:19 UTC
i guess i should have put it in a nutshell.

it looks like fc3 will only use initrd's created with initramfs/cpio.

Comment 2 Jeremy Katz 2004-11-22 16:02:11 UTC
Old-style initrds should still work.  What exactly is this "real
process" doing?  If you're invoking mkinitrd but putting it on an ext2
image, then no, it's not going to work.  mkinitrd creates an initramfs
now (if you're running on a 2.6 kernel) which changes some of the bits
required for booting.

Comment 3 rich turner 2004-11-22 19:12:54 UTC
we are not using mkinitrd at all. our process is to create an ext2
filesystem on a RAM or loop device. move the files we want in the
initrd to the ram filesystem, unmount it and dd it off to a compressed
file. we then use that file as our initrd. this process has worked in
the past with all distributions (2.2 thru 2.6 kernels) but is now failing.

i did notice in the mkinitrd script provided with fc3 that cpio is now
the format of the initrd. will this kernel only support cpio/initramfs
initrd's? how do i change the bits as mkinitrd does, to support my initrd?

the problem appears to be that the kernel cannot execute the linuxrc.
during boot up, the kernel actually sees the compressed initrd and
successfully mounts it. but it immediately exits from the initrd and
attempts to mount the root filesystem without executing the linuxrc.
hence the kernel-panic.

Comment 4 Jeremy Katz 2004-11-22 21:25:13 UTC
Your methodology won't work as of FC3 or later (including RHEL4).

An initramfs is handled differently by the kernel on boot-up than an
initrd and thus things have to be constructed differently.  If you're
going to create an initrd (a filesystem), then you'll have to make the
appropriate changes to go from initramfs style to initrd style.  These
include, but aren't necessarily limited to as this is just my own memory:
1) initrds are compressed filesystems, initramfs is a compressed cpio
archive.  You found this one.
2) initrds exec /linuxrc, initramfs execs /init.  You're currently
hitting this problem in that init doesn't get found and so can't be
3) initrds  pivot to their final root, initramfs uses a move mount to
change the view of filesystem namespaces.  If you do mv /path/to/init
/path/to/linuxrc, you'll start hitting this.

So, in short, you're going to have to change your process in some way

Comment 5 rich turner 2004-11-22 21:40:19 UTC
do you know of any documentation for initramfs? i would like to
research on how i can make these two co-exist.

thanks for your help.

Comment 6 Jeremy Katz 2004-11-22 21:43:50 UTC
Unfortunately, not really other than reading the kernel source.  Most
of the relevant code is under the init/ directory.

Comment 7 rich turner 2004-11-23 18:12:00 UTC
is there a way to determine whether the kernel boot process supports 
initrd or initramfs?

Comment 8 Jeremy Katz 2004-11-23 18:22:42 UTC
All 2.6 kernels should support initramfs

Comment 9 rich turner 2004-11-23 18:30:10 UTC
is there anyway to know if the kernel supports an initrd in the way it
worked before and the way i am trying to use it?

Comment 10 rich turner 2004-12-03 18:05:02 UTC
i still think this is a bug.

according to the documentation provided with the kernel that fedora is
using, a normal initrd should still be supported.

i took the following snippet from

The kernel has currently 3 ways to mount the root filesystem:

a) all required device and filesystem drivers compiled into the
kernel, no initrd.  init/main.c:init() will call prepare_namespace()
to mount the final root filesystem, based on the root= option and
optional init= to run some other init binary than listed at the end of

b) some device and filesystem drivers built as modules and stored in
an initrd.  The initrd must contain a binary '/linuxrc' which is
supposed to load these driver modules.  It is also possible to mount
the final root filesystem via linuxrc and use the pivot_root syscall.
 The initrd is mounted and executed via prepare_namespace().

c) using initramfs.  The call to prepare_namespace() must be skipped.
  This means that a binary must do all the work.  Said binary can be
stored into initramfs either via modifying usr/gen_init_cpio.c or via
the new initrd format, an cpio archive.  It must be called "/init". 
This binary is responsible to do all the things prepare_namespace()
would do.

To remain backwards compatibility, the /init binary will only run if
it comes via an initramfs cpio archive.  If this is not the case,
init/main.c:init() will run prepare_namespace() to mount the final
root and exec one of the predefined init binaries.

Comment 11 Jeremy Katz 2004-12-03 18:18:14 UTC
Yes, but what is in the initramfs you're copying from is *NOT* content
that will work with an initrd.  The mechanics of how the two work is
not the same (what gets exec'd, how you get to the real root fs.  

eg, read b) and c) in what you provided.  An initrd must contain a
binary /linuxrc that does a pivot_root.  An initramfs must contain a
binary /init that does all of the prepare_namespace() bits.  So just
copying the initramfs contents into an initrd _will not work_.

If you use an initrd that conforms to the requirements for an initrd,
then it will work just fine.

Comment 12 rich turner 2004-12-03 18:38:43 UTC
i understand that the two are very different.

i am not copying the content from an initramfs to be used with my
initrd. i am creating my initrd from scratch, with /linuxrc, and it is
not working. you will see from my notes above that the kernel finds
the initrd, mounts it, but cannot execute the /linuxrc for some
reason. the same initrd creation process that i am using works on
EVERY other distribution (2.2, 2.4, 2.6, including FC2) but fails on FC3.

Comment 13 rich turner 2004-12-10 17:49:15 UTC
i just created an old-style initrd using fc3 distributed mkinitrd
script and it too is unable to boot the system. i tried this with both
the fc3 kernel and the vanilla 2.6.9 kernel. this sure seems like a
bug. i just dont know yet if it is a bug within the kernel, fc3, or
perhaps udev or selinux related. any hints will be helpful.

Note You need to log in before you can comment on or make changes to this bug.