Bug 139981
| Summary: | initrd created with ext2 fails | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | rich turner <rturner> |
| Component: | mkinitrd | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | rturner |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-03 18:18:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 exec'd. 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 /usr/src/linux/Documentation/early-userspace. 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 init/main.c:init(). 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. 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. |
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: Always 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.