Recent mails on the list show that it is not very clear how to create
an initial RAM fs with buildroot. So make this more explicit in the
cpio and initramfs help texts. Hopefully this will reduce the /init
debugging we have to do.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As the kernel doesn't automatically mount devtmpfs when an initramfs
is used, commit 424888e474 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 <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <vapier@gentoo.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 f507921d39 for details.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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 <thomas.petazzoni@free-electrons.com>
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 <will_wagner@carallon.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The restructure for building root filesystems changed the target name
for the initramfs file, to build the file the trget is now
initramfs-root but the generated file is rootfs.initramfs
Signed-off-by: Will Wagner <will_wagner@carallon.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
