buildroot.git/fs/initramfs, branch master

fs/initramfs: refactor with fs/cpio

2011-09-27T20:46:00Z

An initramfs is in fact the same as a cpio archive, but embedded in the kernel. So instead of duplicating the cpio infrastructure, we can simply build images/rootfs.cpio and link that into the kernel. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

initramfs/init: make sure that 0, 1, 2 fds are available

2011-08-04T19:52:21Z

As the kernel doesn't automatically mount devtmpfs when an initramfs is used, commit 424888e47431db738f5f9b3c6392435bfce7a842 has introduced a small wrapper script that mounts devtmpfs before starting the real init. Unfortunately, the problem is that in this case, the init process runs without any 0, 1 and 2 file descriptors, so none of the messages/errors printed by the various initialization scripts can be seen. This is due to the fact the init process relies on 0, 1 and 2 being opened by the kernel before init is started. However, as /dev/console isn't present on the filesystem at the time the kernel tries to open the console to create the 0, 1 and 2 file descriptors, the kernel fails on this and prints the famous "Warning: unable to open an initial console". The proposed workaround is to actually open 0, 1 and 2 to /dev/console in the wrapper script, right after mounting the devtmpfs filesystem, and before starting the real init. The "Warning" from the kernel is still shown, but at least the messages from the init scripts are visible. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

initramfs: fix boot with dynamic /dev

2011-07-20T14:30:14Z

Devtmpfs (which is used by devtmpfs/mdev/udev options) doesn't get automounted by the kernel when an initramfs is used, causing boot failures when a dynamic /dev is used. Fix it by adding a pre-init script to mount devtmpfs before running init. Reported-by: Arnout Vandecappelle Signed-off-by: Peter Korsgaard

initramfs: fix init symlink creation

2010-11-17T20:20:45Z

The -e test will dereference the symlink, so if there is no /bin/init, we will constantly try to create the symlink. So rather than error on subsequent runs when the link exists, use the force flag to ln. Signed-off-by: Mike Frysinger Acked-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

Remove INITRAMFS_TARGET variable

2010-11-04T18:26:27Z

This used to be needed when the filesystem code was rewritten, but not the Linux compilation code. Now that the Linux compilation code has been rewritten, the mechanism to ensure that initramfs gets built *before* the kernel so that it can be integrated is different, and this INITRAMFS_TARGET variable is no longer used. See f507921d391bb2578261a9e45c003e72302dc67a for details. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

initramfs: Don't overwrite $(TARGET_DIR)/init if it exists

2010-08-29T21:34:03Z

Closes #2443 Allow use of custom init scripts. Signed-off-by: Simon Pasch Signed-off-by: Peter Korsgaard

initramfs: update help text

2010-06-26T05:44:16Z

Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

initramfs: only show the option when a Linux kernel is being built

2010-06-26T05:43:20Z

Closes #2119 Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

linux: add support for initramfs

2010-06-22T19:20:28Z

In Buildroot, the kernel is built and installed *before* the root filesystems are built. This allows the root filesystem to correctly contain the kernel modules that have been installed. However, in the initramfs case, the root filesystem is part of the kernel. Therefore, the kernel should be built *after* the root filesystem (which, in the initramfs case simply builds a text file listing all files/directories/devices/symlinks that should be part of the initramfs). However, this isn't possible as the initramfs text file would lack all kernel modules. So, the solution choosen here is to keep the normal order: kernel is built before the root filesystem is generated, and to add a little quirk to retrigger a kernel compilation after the root filesystem generation. To do so, we add a ROOTFS_$(FSTYPE)_POST_TARGETS variable to the fs/common.mk infrastructure. This allows individual filesystems to set a target name that we should depend on *after* generating the root filesystem itself (contrary to normal ROOTFS_$(FSTYPE)_DEPENDENCIES, on which we depend *before* generating the root filesystem). The initramfs code in fs/initramfs/initramfs.mk uses this to add a dependency on 'linux26-rebuild-with-initramfs'. In linux/linux.mk, we do various things : * If BR2_TARGET_ROOTFS_INITRAMFS is enabled (i.e if initramfs is enabled as a root filesystem type), then we create an empty rootfs.initramfs file (remember that at this point, the root filesystem hasn't been generated) and we adjust the kernel configuration to include an initramfs. Of course, in the initial kernel build, this initramfs will be empty. * In the linux26-rebuild-with-initramfs target, we retrigger a compilation of the kernel image, after removing the initramfs in the kernel sources to make sure it gets properly rebuilt (we've experienced cases were modifying the rootfs.initramfs file wouldn't retrigger the generation of the initramfs at the kernel level). This is fairly quirky, but initramfs really is a special case, so in one way or another, we need a little quirk to solve its specialness. Signed-off-by: Thomas Petazzoni

initramfs: fix init symlink

2010-04-20T14:54:50Z

When initramfs was ported to the new fs structure the init symlink macro was defined, but forgot to add it to PRE_GEN_HOOKS Signed-off-by: Will Wagner Signed-off-by: Peter Korsgaard