[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Configuring foreign packages without qemu in order to boot a system

On Sun, 2 Sep 2012 21:26:09 +0200
Paul Boddie <paul@boddie.org.uk> wrote:

> On Sunday 02 September 2012 11:05:54 Neil Williams wrote:
> > On Sun, 2 Sep 2012 01:40:45 +0100
> >
> > http://wiki.debian.org/Multistrap#Steps_for_Squeeze_and_later
> Right, I can see straight away that /sbin/init might have a hard time doing 
> anything useful because the symbolic links within /etc/rcS.d don't exist. The 
> problem I've been experiencing is getting a shell to run at all, I think, 
> making it difficult to run a configscript like the one described.

That's the role of the setupscript - to put files into the rootfs which
are not package-based. Many files on a typical Debian system were put
there only by Debian Installer, not by packages. You have to decide
which of those you want, what goes into each and make that happen via

> The latter part of this paragraph was particularly helpful in pushing me 
> towards trying busybox as a helper in getting configuration to occur.

You may well find it more useful to create a full initrd image which
has a kernel and a proper environment. i.e. make the step up from
busybox to buildroot.
> > Multistrap can easily take a rootfs all the way up to a full package
> > set with a UI and customisations and give you a tarball with absolutely
> > everything setup and ready to run. The cost of that is that the rather
> > arbitrary division line with which people have become familiar from the
> > debootstrap model simply doesn't exist. This has advantages in package
> > selection but also has requirements about package configuration.
> I'm not quite sure I follow this last paragraph. I've tried to use multistrap 
> to deploy a rootfs that I want to be able to boot into, but it isn't ready to 
> run, even with a minimal configuration.

It is ready to run, it just needs you to sort out enough of the init
that the kernel can make the jump from itself to the init and on to the
rootfs. You're missing a stage. A rootfs is just that - a root
filesystem. It is not what the kernel boots into directly - that's init.
Depending on the system, init can be fully prepared within the rootfs
but that involves using setupscript to put the init inside the rootfs
and probably some work by the init process to finalise the rootfs
itself the first time it runs.

With a buildroot rescue environment, multistrap can and does do just
what I described in that paragraph. We rely on it at work for all our
boards and use buildroot as the rescue shell, scripted via the
bootloader and configscript.

> It's a shame that there aren't any prominent recipes out there for this.

www.balloonboard.org but I wouldn't class that as prominent or
particularly easy to follow.

> What 
> you're suggesting (uClibc and busybox) is what the OpenWrt distribution on my 
> NanoNote provides, and that's how I managed to get Emdebian bootable 
> initially, but it would be preferable to be able to drop the requirement on 
> OpenWrt, buildroot or other systems.

Once the system is configured, you can drop that stage but keep it as
a fallback. It will still prove immensely useful to have that rescue
environment accessible (maybe via a keypress during boot) for those
times when something screws up your rootfs.

> > "just enough of a system to run init (and chroot)" sounds a lot like
> > a description of buildroot.
> Yes, but it would be great to drop the need for buildroot. I think deploying 
> busybox-static might be sufficient for that, at least when deploying a 
> system. I also want to look into building Debian kernel packages.

Build your own kernel package, not the Debian kernel package - that
includes a complete initramfs and is an order of magnitude larger than
a simple kernel, even with modules. And remember that the default
in-kernel Debian packaging is *native-only* and will not cross-build
without patching.

Why drop buildroot? You know you'll need a rescue shell when something
goes wrong later and it's only a few Mb. Our buildroot + kernel
zImageInitrd is only 3Mb all-in - it has to be, it goes onto a 4Mb
NOR chip.

> > Getting the kernel to boot is the first barrier. Once that is done,
> > getting the kernel to use the init available and successfully hand-off
> > to it is the next barrier. Once you're at that point, the configscript
> > can be executed by that init process and that process could be
> > buildroot.
> I like the idea of setupscript and configscript: if you're going to end up 
> copying things into a rootfs, you might as well make it easy to automate and 
> manage. I did try using configscript but multistrap didn't seem to copy the 
> script into the rootfs, and I'm not sure where it would put it or how it 
> would make it run on the target system, anyway.

As always with multistrap, check the --simulate output. If multistrap
cannot find the specified file using realpath, it will ignore it. It is
copied into / so that it can be easily removed once done.

> Well, I'd like to be able to write something up that neither involves tens of 
> manually invoked steps nor something that just points to a rootfs that has 
> been magically constructed according to a set of forgotten instructions (or 
> worse, trial and error), that also helps people troubleshoot if the 
> infrastructure changes or if they're trying to do something similar but not 
> identical.

The entire process, from bare metal to running UI, can be scripted - we
do it using a custom bootloader, a custom kernel Debian package,
buildroot, multistrap and configscript. No commands are even necessary,
if the rootfs is sufficiently damaged, the buildroot kernel gets called
instead of the broken/missing rootfs kernel and it downloads a new
rootfs from the network and then just sorts itself out. Yes, it takes
an amount of time but it's better than leaving the device bricked.

Depends how much time it is worth investing in sorting out all the
possible wrinkles.

> I think I've found some kind of solution for package configuration, though, so 
> I'll attempt to write this up and let you take a look. There will surely be a 
> lot of room for improvement in what I'm doing.

Just don't reinvent the buildroot wheel.


Neil Williams

Attachment: pgpbx8Mwek8IF.pgp
Description: PGP signature

Reply to: