Bug 8361

Summary:	Buildroot 2015.08.1 skeleton inittab overwritten by busybox's version
Product:	buildroot	Reporter:	Tom Elliott <tommygunsster>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED WONTFIX
Severity:	minor	CC:	buildroot, tommygunsster
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Host:		Target:
Build:

Description Tom Elliott 2015-09-21 00:11:36 UTC

When compiling, the rsync operation that copies the skeleton directory operates before all other packages that might alter some of the files in the skeleton directory.  This can cause problems if your build has custom skeleton files that get overwritten.

In my example, I am using the default system/skeleton folder to contain any custom files I may need as appropriate.  Specifically, I have an inittab file that should be used over others.

I did notice that system/skeleton/etc/inittab and init.d are not stored in wait which is to be expected, particularly for specific files.

I realize this is likely because configuration of things may require alternative methods to startup, but in this particular case it is not an issue as the only file that I see being altered that's affecting the init's ability is that the tty0 parameter I need does not exist.

I am also aware that I can script a custom package to correct this for me as well.

The specific git revision that adds this issue from what I can tell is: http://git.buildroot.net/buildroot/commit/?id=89d39fc7a392530be043bac541ade0bef746edb6

I imagine the intent of this addition is to ensure an inittab file exists.  I would imagine the overwriting of the skeleton files was unintentional?

Comment 1 Thomas Petazzoni 2015-09-21 07:09:51 UTC

Using a custom skeleton is pretty much a deprecated method of customizing your root filesystem. You should instead be using a rootfs overlay or a post-build script (see the Buildroot manual for details).

Specifically regarding inittab, this file is no longer part of the skeleton. It is now installed either by Busybox, or by sysvinit, depending on which init system you have chosen.

The previous way of doing things, with a Busybox-style inittab in the skeleton, which was used when Busybox was the init system, caused some inconsistencies:

 - It was still on the filesystem when systemd was used as the init system, which is not needed
 - It was overwritten by the sysvinit package when it was chosen as the init system, which isn't nice

So the inittab file was moved from the skeleton package to the Busybox and sysvinit packages (which require different inittab syntax).

Generally speaking, we do not ensure that files in the skeleton will not be overwritten. Then can be overwritten by any package in Buildroot.

However, we do guarantee that the rootfs overlay and post-build script are handled *after* all packages have been installed, so you are sure that what you have in the rootfs overlay or what you do in the post-build scripts "wins" over what packages are doing.

So the behavior you are observing is intentional.