Wookey wrote: >>> 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. > I could have a go at a bug report for dpkg. Do I need to register as a Debian developer or have a Debian account ??
>>> Would it be good idea for multistrap to provide some basic default >>> config files. eg. /etc/fstab, /etc/mtab, ... ?? >>> >> But what are sensible defaults? >> For /etc/fstab I have the following (from a vendor SDK). They all seem pretty standard -- not sure about the /dev/nfs line though. # UNCONFIGURED FSTAB FOR BASE SYSTEM none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/nfs / nfs defaults 0 0 none /tmp tmpfs defaults 0 0 none /var/run tmpfs defaults 0 0 none /var/lock tmpfs defaults 0 0 none /var/tmp tmpfs defaults 0 0 none /media tmpfs defaults 0 0 >> multistrap unpacks the downloaded packages but other stages of >> system configuration are not attempted. Examples include: >> >> /etc/inittab >> /etc/fstab >> /etc/hosts >> /etc/securetty >> /etc/modules >> /etc/hostname >> /etc/network/interfaces >> /etc/init.d >> /etc/dhcp3 >> >> Any device-specific device nodes will also need to be created >> using MAKEDEV. >> For /dev, I used a control file in the linux config -- as this was already available as part of the vendor SDK. CONFIG_INITRAMFS_SOURCE="usr/dev_file_list usr/multistrap" # cat usr/dev_file_list ##################### # ramfs # Last modified: 1223703312 dir /dev 777 0 0 nod /dev/ptyxf 777 0 0 c 2 143 nod /dev/ttyy9 777 0 0 c 3 153 nod /dev/mtdblock0 777 0 0 b 31 0 ... <snip> -- lots and lots of device nodes ... nod /dev/ttyy3 777 0 0 c 3 147 nod /dev/ptyqc 777 0 0 c 2 28 nod /dev/ptyq6 777 0 0 c 2 22 > 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. > > The problem with this is that you rapidly get into writing > mini-buildroot if you are not careful... > > The other approach is to work on mechanisms for cross-running of the > proper install scripts (which is a much more complete but also _much_ > harder problem). Currently only scratchbox and qemu provide working > solutions. Other solutions are very intrusive into dbeian packaging > _and_ can probably never be made to work in all cases (although they'd > work fine in these basic system-config cases). > > 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. > How about having some options in the multistrap config file ?? examples: [/etc/fstab] or [fstab] <add entries here> or something more generic like: [file /etc/fstab uid gid perm] <some content> or include an external file. [file /etc/fstab uid gid perm = /my/local/fs/home/brendan/emdebian/config/etc/fstab] Same for other config files that are needed. Maybe this is too much the multistrap config file, and another config/control (or tool) is a better option. If you like an "em_ms_secondstage" or "em_ms_setup" An "em_ms_secondstage" or "em_ms_config" script could be part of the rootfs, that ran 'dpkg --configure -a', but after it did some sanity checks for various filesystems such as /proc, /sys, ... It could even mount them if they are not already mounted :) Brendan. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
