Re: multistrap rootfs with initramfs
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.
Reply to: