Dev/Embedded/Rootfs/BusyBox/Example1 - Revision history

Drizzt at 18:48, 3 February 2025

2025-02-03T18:48:43Z

← Older revision		Revision as of 20:48, 3 February 2025
Line 1:		Line 1:
	{{DISPLAYTITLE:Example 1 : Simple system}}		{{DISPLAYTITLE:BusyBox Example 1 : Simple system}}

	Most of the time when you start with BusyBox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.		Most of the time when you start with BusyBox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.

Drizzt: /* Bootup script(s) */

2025-01-18T02:28:22Z

Bootup script(s)

← Older revision		Revision as of 04:28, 18 January 2025
Line 58:		Line 58:
	* Other service or configuration script(s)		* Other service or configuration script(s)

	What you put in each file depends on your application and your needs.		What you put in each file depends on your application and your needs, even if some parts are hard to avoid and thus common to every system, like the initial mounts of /dev and /proc at least.

	In SysVinit the rcS script (called by init according to inittab content) calls "/etc/init.d/rc" for the runlevel S, which will start all scripts from "/etc/rcS.d", and after this, init will change to the default runlevel configured in inittab, which will call "/etc/init.d/rc" for the default runlevel (usually 2) which in turn will start all scripts from the corresponding "/etc/rcN.d" directory.		In SysVinit the rcS script (called by init according to inittab content) calls "/etc/init.d/rc" for the runlevel S, which will start all scripts from "/etc/rcS.d", and after this, init will change to the default runlevel configured in inittab, which will call "/etc/init.d/rc" for the default runlevel (usually 2) which in turn will start all scripts from the corresponding "/etc/rcN.d" directory.

Drizzt: /* Libraries */

2025-01-18T02:24:23Z

Libraries

← Older revision		Revision as of 04:24, 18 January 2025
Line 37:		Line 37:
	As this is a very simple system the set of libraries should be very limited. You may need additional ones for your application binaries so I cannot give you a full list, but if you chose to have dynamically linked binaries (which is usually a good idea if your system has more than one or two binaries) you will always need these two :		As this is a very simple system the set of libraries should be very limited. You may need additional ones for your application binaries so I cannot give you a full list, but if you chose to have dynamically linked binaries (which is usually a good idea if your system has more than one or two binaries) you will always need these two :
	* The dynamic linker/loader (name depending on the target architecture/triplet) : ld-linux-.so.		* The dynamic linker/loader (name depending on the target architecture/triplet) : ld-linux-.so.
	* the libc		* the libc : libc.so.6
	In order to check for additional library requirements, have a look at this part in the second example ~~below~~.		In order to check for additional library requirements, have a look at this part in the second example.

	Once you know which libraries you need, you'll need to figure which files to put in which directory for each library.		Once you know which libraries you need, you'll need to figure which files to put in which directory for each library.

	Unless you specified an absolute or relative pathname during the linking stage of the compilation of your binaries, there is no "fixed" location for each library file, save maybe the dynamic linker/loader (ld-linux-.so.), which usually goes under "/lib", and the dynamic linker will end up looking for libraries in some "default" path which usually includes "/lib".		Unless you specified an absolute or relative pathname during the linking stage of the compilation of your binaries, there is no "fixed" location for each library file, save maybe the dynamic linker/loader (ld-linux-.so.), which usually goes under "/lib", and the dynamic linker will end up looking for libraries in some "default" path which usually includes "/lib".<br />
			So the easy way is to create a single "/lib" directory (remember that we chose to desactivate the use of "/usr" in BusyBox configuration).

	So the ~~easy way is to create a single~~ "/lib" ~~directory~~ (~~remember that we chose to desactivate~~ the ~~use of~~ "~~/usr~~" in BusyBox ~~configuration~~).		As for the files, for the dynamic linker/loader and the libc, the files should be shipped with your cross-compilation toolchain. If you're using the toolchain packaged by Debian, then you will find them under "/usr/${triplet}/lib/" if you installed "libc6--cross" package, or under "/usr/lib/${triplet}/" if you installed "libc6:" package (* is for the Debian architecture name, while you should [[Dev/Embedded/Rootfs/BusyBox/Example2#First,_the_answer_about_the_"triplet"\|read the bits I collected about the ${triplet} in the second BusyBox example page]]).

	== Bootup script(s) ==		== Bootup script(s) ==

Drizzt: /* Application binaries and related files */

2025-01-18T02:09:25Z

Application binaries and related files

← Older revision		Revision as of 04:09, 18 January 2025
Line 89:		Line 89:

	As this simple BusyBox example does not include any kind of "application packaging" support there's not need (save for your mental health) to stick to any particular organisation for your files.		As this simple BusyBox example does not include any kind of "application packaging" support there's not need (save for your mental health) to stick to any particular organisation for your files.

			Remember that if your binaries rely on some more libs than those you already put under "/lib" (or any other place you chose for them), then you'll need to add them to your base file system too.

Drizzt at 18:28, 15 January 2025

2025-01-15T18:28:07Z

← Older revision		Revision as of 20:28, 15 January 2025
Line 1:		Line 1:
			{{DISPLAYTITLE:Example 1 : Simple system}}

	Most of the time when you start with BusyBox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.		Most of the time when you start with BusyBox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.

Drizzt at 17:19, 15 January 2025

2025-01-15T17:19:37Z

← Older revision		Revision as of 19:19, 15 January 2025
Line 83:		Line 83:
	* ''' TO BE COMPLETED '''		* ''' TO BE COMPLETED '''

	== Application binaries ==		== Application binaries and related files ==
	~~''' TO BE COMPLETED '''~~		This part is really only up to you and your application.
	~~== Application related files ==~~
	'~~'' TO BE COMPLETED '''~~		As this simple BusyBox example does not include any kind of "application packaging" support there's not need (save for your mental health) to stick to any particular organisation for your files.

Drizzt: /* Configuration files */

2025-01-15T17:16:03Z

Configuration files

← Older revision		Revision as of 19:16, 15 January 2025
Line 70:		Line 70:

	== Configuration files ==		== Configuration files ==
	'~~'' TO BE COMPLETED '''~~		The list of configuration files depend on what you have selected in you BusyBox configuration and on what you write in your scripts.<br />
			And their content depends on your needs, of course.<br />
			In order to know which ones you'll need, there is no easy way (as far as I know).<br />
			* Some of them are listed within BusyBox configuration menu and help for each entry, so you can start there, reading the help for each entry you have activated (save thoses you think would not need a configuration file, like archiving related utilities).
			* You can also look at the content of "/etc" on your development host
			* Another solution is to try running the system, try to start the services you want, and check the messages on the console.
			Here is a short list of those I have listed/created for this simple example :
	* /etc/nologin		* /etc/nologin
	* /etc/securetty		* /etc/securetty
	* /etc/shells		* /etc/shells
	* /etc/{passwd,shadow,groups}		* /etc/{passwd,shadow,groups}
			* ''' TO BE COMPLETED '''

	== Application binaries ==		== Application binaries ==

Drizzt: /* Bootup script(s) */

2025-01-15T16:10:36Z

Bootup script(s)

← Older revision		Revision as of 18:10, 15 January 2025
Line 60:		Line 60:

	In busybox there are no runlevels, and usually much less configuration to perform, with this configuration being more "static".<br />		In busybox there are no runlevels, and usually much less configuration to perform, with this configuration being more "static".<br />
	As such, I usually create a single "startup" script (the "/etc/init.d/rcS" one) which does all the usual system configuration and setup (hostname, mounts, hwclock, modules, sysctl, random init, ...) then the network configuration (static IP or DHCP, firewall, ...)~~, and then starts the services (sshd, inetd, ...), and starts the main application(s).~~<br />		As such, I usually create a single "startup" script (the "/etc/init.d/rcS" one) which does all the usual system configuration and setup (hostname, mounts, hwclock, modules, sysctl, random init, ...) then the network configuration (static IP or DHCP, firewall, ...)<br />
	Having everything started sequentially by a single script which does not try to read a hundred configuration files is not that much slower than using a heavy, complicated system which tries to run everything in parallel but needs to be heavily configured to avoid race conditions and handle dependencies.		Having everything started sequentially by a single script which does not try to read a hundred configuration files is not that much slower than using a heavy, complicated system which tries to run everything in parallel but needs to be heavily configured to avoid race conditions and handle dependencies.

			In order to start the services (sshd, inetd, ...) and the main application(s) you have some options :
			* add them at the end of the rcS script (using start-stop-daemon if need be for respawn)
			* create a separate script for them (or one for each) and call them at the end of the rcS one (still using start-stop-daemon if need be)
			* use the "wait", "once" or "respawn" actions in inittab
			I usually use the inittab solution, sometimes with a wrapper script.

	== Configuration files ==		== Configuration files ==

Drizzt: /* Bootup script(s) */

2025-01-15T12:55:03Z

Bootup script(s)

← Older revision		Revision as of 14:55, 15 January 2025
Line 48:		Line 48:
	I choose to disable runnit support in this minimal configuration, so the "init" applet will look for the "/etc/inittab" configuration file.<br />		I choose to disable runnit support in this minimal configuration, so the "init" applet will look for the "/etc/inittab" configuration file.<br />
	There is an example one under "examples/" in BusyBox source tree.<br />		There is an example one under "examples/" in BusyBox source tree.<br />
	Anyway, even without this file the applet will look for a script called "/etc/init.d/rcS" and, even if it found none, start an "askfirst" shell (display the message "Please press Enter to activate this console." which would then give you a prompt).		Anyway, even without this file the applet will look for a script called "/etc/init.d/rcS" and, even if it found none, start an "askfirst" shell (display the message "Please press Enter to activate this console." which would then give you a prompt). All the details are explained in the example inittab file in BusyBox sources.

	So here is a short list of files for the init part of the base system :		So here is a short list of files for the init part of the base system :
	* /etc/inittab		* /etc/inittab
	* /etc/init.d/rcS and rc script(s)		* /etc/init.d/rcS
			* Other service or configuration script(s)

			What you put in each file depends on your application and your needs.

			In SysVinit the rcS script (called by init according to inittab content) calls "/etc/init.d/rc" for the runlevel S, which will start all scripts from "/etc/rcS.d", and after this, init will change to the default runlevel configured in inittab, which will call "/etc/init.d/rc" for the default runlevel (usually 2) which in turn will start all scripts from the corresponding "/etc/rcN.d" directory.

			In busybox there are no runlevels, and usually much less configuration to perform, with this configuration being more "static".<br />
			As such, I usually create a single "startup" script (the "/etc/init.d/rcS" one) which does all the usual system configuration and setup (hostname, mounts, hwclock, modules, sysctl, random init, ...) then the network configuration (static IP or DHCP, firewall, ...), and then starts the services (sshd, inetd, ...), and starts the main application(s).<br />
			Having everything started sequentially by a single script which does not try to read a hundred configuration files is not that much slower than using a heavy, complicated system which tries to run everything in parallel but needs to be heavily configured to avoid race conditions and handle dependencies.

	== Configuration files ==		== Configuration files ==

Drizzt at 13:37, 14 January 2025

2025-01-14T13:37:34Z

← Older revision		Revision as of 15:37, 14 January 2025
Line 1:		Line 1:
	Most of the time when you start with ~~busybox~~ as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.		Most of the time when you start with BusyBox as the heart of your system you do not plan for a multi-user desktop box, but rather aim for a small, single purpose embedded system, so you won't need too many stuff to get it running.

	This example explains how to create a minimal Linux based base system using BusyBox as a base for the userland part of the system.		This example explains how to create a minimal Linux based base system using BusyBox as a base for the userland part of the system.