On Mon, 2 Nov 2009 11:46:06 +0000 Wookey <woo...@wookware.org> wrote:
> > Worth adding a note to the Wiki that at least /proc and /sysfs (and > > probably /dev/pts) need to be mounted before doing anything sensible > > with dpkg. > > > > > I guess it's a dpkg issue rather than a multistrap issue, but one would > > > have hoped for a more informative error message rather than a segfault. > > > > True. :-) > > I would be good for someone to work out what the actual bug is. A > bugrep pointing out that there is an issue would be a helpful place to > hang such info. As it's a seg fault in dpkg, I'm assuming it is that dpkg is trying to start "Reading database" which principally involves reading files from /var/lib/dpkg/ and allocating a lot of RAM to the meta data generated. It's hard to debug. I can successfully run lots of dpkg commands inside a pbuilder chroot *after* unmounting the /proc used by the chroot from outside the chroot. This results in: r...@holly:/# mount warning: can't open /etc/mtab: No such file or directory However, dpkg -P, dpkg --unpack and dpkg --configure all work as expected, probably because it's a chroot and the "real" things are still mounted and the kernel is doing clever things behind the scenes. This will tend to make it hard for dpkg maintainers to test and therefore fix. > > > Would it be good idea for multistrap to provide some basic default > > > config files. eg. /etc/fstab, /etc/mtab, ... ?? > > > > But what are sensible defaults? > > This is a tricky area. It would generally be good to make it easy to > create a bootable rootfs. The packages provide 'sensible defaults' of > some sort but those are never installed if you supply your own. Whilst > emdebian cannot supply sensible default files for everyone it can > supply mechanism for getting them installed in the rootfs easily. > > So making it easy to use something like the 'emsandbox' > machines/config stuff with multistrap to get those vital things > populated is probably helpful, to save everyone individually writing a > hacky script like the one I posted, and whatever Brendan has done to > make his stuff work. machine:variant is essentially a hook system. The question is whether we want those hooks in multistrap (i.e. whether multistrap is the top-end control program) or whether multistrap is expected to be called by something else (like make) and therefore can leave the task to the next process. I've so far kept multistrap as a component, not the complete tool. This is closer to debootstrap which doesn't attempt any of these stages - pbuilder etc. have to do a lot of setup work after debootstrap claims to have finished. A plain debootstrap directory isn't much use for anything without some kind of follow up configuration. debootstrap itself has actually moved further and further away from the post-creation configuration stage as it is inherently difficult - a constantly moving target. > The problem with this is that you rapidly get into writing > mini-buildroot if you are not careful... How does buildroot do it and can it be co-opted into helping once multistrap has finished? > I don't know what the right answer is but I do think it is good for > multistrap to include a mechanism for minimal pre-configuration, > perhaps simply done by optionally calling another tool (so as not to > complicate multistrap itself unduly). Keeping rootfs-creation-from > packages and rootfs configuration separated to some degree is good. I think it's good to keep multistrap in the rootfs-creation-from-packages role and investigate how to join on other tools that are good at the rootfs-configuration step. Yes, it could be trivial to add a hook at the end of multistrap that calls a script declared in the config_file - the question is more how we devise a standard or default type script, what it should do and where it should live. I've no problems putting such a script into the multistrap package as an example but I'm not sure one script will ever be sufficiently general to be useful for everyone. Some stages just seem to need user intervention. Even machine:variant support in emsandbox has limitations, it's one reason why Crush uses multiple functions in a shell library - it makes it easier to mix and match the components. In particular, I think we need more data on just how to solve this "configure-on-first-boot-without-rescue-chroot" issue. That shifts the focus from the machine running multistrap to the machine running the rootfs itself. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpIZwLwUUuoa.pgp
Description: PGP signature
