On Thu, 26 Mar 2009 20:03:52 +1100 Brendan Simon <Brendan@BrendanSimon.com> wrote: > Below are my requirements and thoughts for creating a rootfs, _without_ > having to execute anything on the target embedded system. multistrap - but there will always be the maintainer scripts that must be run on the target system. It is possible that some kind of first-boot config could be devised. > Do they make sense? Not completely. > Am I reinventing the wheel? i.e. are there existing tools that do a > similar thing (eg. emsandbox). Yes, you are reinventing the wheel. However, not by much. multistrap was written less than three weeks ago and is still in final testing. The current version is 1.6.2 in Emdebian. (separate package, it was in emdebian-rootfs in 1.6.1). > Any thoughts or suggestions are welcome :) > > NOTE: I am coming from the perspective of using a configuration > management system to control and build my target application/rootfs, and > that it should be repeatable and reliable, even if going back to an old > revision and be able to produce the exact same application/rootfs :) Already supported, due to a request to do things this way from Wookey. > I want to be able to create a root for an embedded system _without_ > having to execute anything on the embedded system. There will always be the postinst scripts - there is no getting away from those. The scripts must be run on the same architecture (in a chroot) or on the target device. Some postinst scripts could well end up with the wrong configuration if done on a machine of the same architecture but a radically different configuration. > The rootfs should be NFS mountable/executable. NFS apparently has problems with this because you need to replace the nfs package whilst the nfs is still mounted (and probably again when the network packages are upgraded). Not sure how or whether d-i has a solution for this problem or whether d-i just avoids all talk of NFS for these reasons. How does NFS behave in Debian if one end of the NFS has the NFS packages upgraded? > I want to be able to specify all packages and versions to install. multistrap - the versions will be whichever is the most recent version of that particular package in the repositories (note: plural) configured for each multistrap. The repositories you use are entirely under your own control and you can easily use reprepro to pull particular suites from Emdebian grip and mix and match with your own or create a second repository that is local and contains the extra packages you need (or more recent versions if you want to do it that way). It is apt that decides which version you get, so any rule that apt can use, multistrap will respect. I'm not sure about pinning though - theoretically it could work but I'm not sure whether the preferences file needs to be on the host system or on the target. I think it's host. > I do _not_ want the debian database files, etc, in the rootfs - only the > files required to execute on the embedded system. multistrap with the tidy-up option or cleanup config option. You will need to retain /var/lib/dpkg/ which can be quite large, but without it, you won't be able to use dpkg or apt to update or upgrade the installed rootfs. /var/lib/apt and /var/cache/apt are cleaned out thoroughly by multistrap (when configured to do so). > I want an ordinary user to be able to generate the rootfs. i.e. not > have to be root. If root privileges are required, then it should be > done in a chroot (so as to protect the host os). multistrap works under fakeroot. > I was thinking about using dpkg directly (rather than apt-get or > aptitude), primarily because it supports switches to specify various > directories (--admindir=dir, --instdir=dir, --root=dir). Already done. > Another alternative would be to use apt-get/aptitude in a chroot, but > the install would be 'polluted' with debian database files, but I guess > they could be removed at the end. Specifying specific package versions > would require specifying _all_ packages on the command line, or > generating specific distributions (packages file ?) with the desired > version combination. Reinventing the wheel. > Each _build_ of _my_ application, shall create the rootfs with the > specified packages and _my_ applications, libraries, etc. > Changes to the 'makefiles' may include the version of one/some/all of > the debian packages, therefore this implies that a new/fresh install is > required for _each_ build to ensure the rootfs is not tainted with old > builds. Configurable via Makefile targets and multistrap. > Not sure what the speed would be of doing a dpkg --install on all > packages for each build, but I suspect it would be slowish ??? It's not dpkg --install, it is dpkg -x and dpkg -e with various fettling to sort out the dpkg status files. All done (shell version in emsandbox, perl version in multistrap). > Would that work ??? No - the problem of the postinst scripts remains. However, multistrap gets you 90% of the way. All that is needed is to be able to run dpkg --configure -a on the target. > The other thing is to specify various configuration files. That can be > done manually, or possibly with some kind of pre-seeding info to > dpkg/apt-get/aptitude ??? pre-seeding applies to debconf and can be done although it's best done on the target device immediately before running 'dpkg --configure -a' -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpkxAMHcWwMQ.pgp
Description: PGP signature