1.1 --- a/README.txt Fri Nov 25 00:33:08 2016 +0100
1.2 +++ b/README.txt Sat Nov 26 16:01:53 2016 +0100
1.3 @@ -1,8 +1,8 @@
1.4 {{infobox|This is currently a work in progress. The objective is to make a reliable set of instructions that can be used to provide a directly bootable Emdebian system. See the [[#Further Work|"Further Work"]] section for areas of improvement.}}
1.5
1.6 -[http://www.emdebian.org/ Emdebian] is a project that provides cross-compilation toolchains, tools for cross-building packages, and tools for making root filesystems for deployment on devices, particularly embedded devices with "foreign" architectures. Such tools permit the time-consuming and resource-intensive work of preparing a system image to be done on "normal" personal computers and workstations, with the finished result then being deployed on the target device.
1.7 +[http://www.emdebian.org/ Emdebian] is a project that traditionally provided cross-compilation toolchains, tools for cross-building packages, and tools for making root filesystems for deployment on devices, particularly embedded devices with "foreign" architectures. Such tools permit the time-consuming and resource-intensive work of preparing a system image to be done on "normal" personal computers and workstations, with the finished result then being deployed on the target device. Many of the things developed under the Emdebian umbrella are now provided in Debian itself, and thus Emdebian is no longer really distinct from Debian and is certainly not a separate distribution (as it once was).
1.8
1.9 -Where Emdebian differs from other projects and toolchains is in its relationship to Debian. It is able to draw upon the extensive selection of Debian packages that are already available, up-to-date, and maintained for a selection of architectures. This means that it should be possible to benefit from the considerable effort invested in Debian packaging by the community and be able to obtain usable packages for specific technologies without being obliged to take on the work of tracking upstream development, dependency relationships, fixing portability issues, and performing packaging work just to be able to use some particular piece of software.
1.10 +The approach cultivated by Emdebian is to draw upon the extensive selection of Debian packages that are already available, up-to-date, and maintained for a selection of architectures, rather than to cross-build an entire distribution from scratch and either offer a monolithic result or one which offers less sophisticated methods for managing the deployed software. By building on Debian, it should be possible to benefit from the considerable effort invested in Debian packaging by the community and be able to obtain usable packages for specific technologies without being obliged to take on the work of tracking upstream development, dependency relationships, fixing portability issues, and performing packaging work just to be able to use some particular piece of software.
1.11
1.12 == The Workflow ==
1.13
1.14 @@ -56,6 +56,7 @@
1.15 aptsources=Debian
1.16
1.17 [Debian]
1.18 +packages=sysvinit-core
1.19 packages=udev busybox-static
1.20 source=http://ftp.debian.org/debian
1.21 keyring=debian-archive-keyring
1.22 @@ -64,6 +65,8 @@
1.23
1.24 This minimal configuration installs a base system from Debian packages. (Previously, qi-emdebian used special Emdebian Grip packages which were meant to be smaller than conventional Debian packages, but the Emdebian project considered the effort of producing such packages for an arguably marginal benefit to be a costly distraction from other work.) In addition, the <code>udev</code> and <code>busybox-static</code> packages are added; this latter package is essential for the initial configuration of the system. Various other packages may be needed in practice, and so example files for various distributions are provided in the [http://hgweb.boddie.org.uk/qi-emdebian/file/tip/conf qi-emdebian distribution] for guidance.
1.25
1.26 +{{infobox|It is important to note that for Debian Jessie, systemd provides the init system. Where older kernels are used on the NanoNote, such as the default OpenWrt kernels, this will most likely cause the system to hang when booting because systemd requires kernel features that were not previously enabled. One solution is to specify <code>sysvinit-core</code> in the package list, thus continuing the use of the init system previously enabled by default in Debian.}}
1.27 +
1.28 === Preparing a Root Filesystem ===
1.29
1.30 With a suitable configuration file called, for example, <code>multistrap-jessie-mipsel.conf</code> a root filesystem can be constructed in a location such as <code>rootfs</code> as follows. Note that you must be <code>root</code> or use <code>sudo</code> for this to work properly. Multistrap may ask for elevated privileges.
1.31 @@ -91,6 +94,8 @@
1.32
1.33 Two additional files called <code>preinit</code> and <code>preinit-config</code> are required that "glue" the kernel to the Debian system on the first boot of the system. These files must reside in the current directory when running the script below. The <code>preinit</code> file is a convention apparently employed by the OpenWrt distribution used on the NanoNote, and where kernels from other origins are to be used, it is important that the appropriate conventions for invoking the system <code>init</code> program are followed. Thus, if you switch to a different kernel from another project, you may need to change the <code>qi-emdebian-postsetup</code> script to install these files into other locations, potentially giving them different names.
1.34
1.35 +{{infobox|It is important to realise that due to the state of various essential packages as deployed by multistrap, the init system cannot be run immediately: not even the default shell is configured at initial boot. Consequently, a means of running a shell is required for the package configuration process, and only then may the init process be started. The solution to this configuration problem is provided by installing the <code>busybox</code> package and having the shell it provides be the one to run the pre-initialisation scripts.}}
1.36 +
1.37 ==== Running the Script ====
1.38
1.39 With the missing files now defined, a script written to automate the remaining configuration activity can be run as follows. Again, it may help to be <code>root</code> or to use <code>sudo</code> to be able to copy the necessary files into the root filesystem: