Red Hat Bugzilla – Bug 139981
initrd created with ext2 fails
Last modified: 2007-11-30 17:10:55 EST
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):
Steps to Reproduce:
1. create an ext2 filesystem with all files needed to run linuxrc on a
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
Although I must say that the real process is handled from with Storix,
and the stmakeboot process.
i guess i should have put it in a nutshell.
it looks like fc3 will only use initrd's created with initramfs/cpio.
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.
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.
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
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.
Unfortunately, not really other than reading the kernel source. Most
of the relevant code is under the init/ directory.
is there a way to determine whether the kernel boot process supports
initrd or initramfs?
All 2.6 kernels should support initramfs
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?
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()
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.
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.
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.
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.