* Juergen Daubert (jue@jue.li) wrote:
On Wed, Aug 05, 2009 at 12:43:15AM +0200, Thomas Penteker wrote: (...) First thanks for you work, but again you are very late with it, because we released an official 2.6-test1 already. Adding new features after that is something we should avoid.
You are right, of course. My current working situation did not permit me to get this done earlier.
Cryptsetup and dependencies should be added to packages.opt if we need them as packages on the ISO. Adding opt/popt to the ISO might create hidden problems, because other (core)ports will link against popt if installed. Currently our ISO bootstrap process can not prevent that, so we have to carefully check all packages after the bootstrap.
That's true. Let me know if I can help out.
I guess your final idea is to have a versioned tarball somewhere for download and not to provide the two binaries within the port?
It'd save the user from going through (some) hassle, see below.
Do we really need a binary port at all? It should be possible to create cryptsetup-static in opt/cryptsetup? Is the busybox binary in any kind special for cryptsetup or can we use a new busybox port for that purpose?
It's not that easy to build it statically linked; libdevmapper needs to be linked statically for this, too, that's why I provided cryptsetup as a binary.
TBH I'm not convinced yet. I'd like to see a more general way/recipe for CRUX to switch to an initrd based startup as an alternative. This might be necessary for other things as well, e.g. I've heard that the kernel md-autodetect feature will be removed sometimes so you have to configure your raid with mdadmin at boot-time.
The initrd-generating process is straight forward. Coming up with a script to automate this should be quite easy, e.g.: gen-initrd mdadm cryptsetup would include the mdadmin binary (with the needed calls to it taken from /etc/initrd/mdadm.conf or similar) + the cryptsetup binary with the necessary calls. The details for the different modules could be included a) in the script b) in a directory /etc/ge-initrd/$MODULE possibility a) is not as flexible as b) but easier to implement. But I do see a certain complexity in b) because one would have to include some information about the order in which the commands would have to be executed (just like udev does). ps: what about the suggested check for /etc/.dev_populated in /sbin/start_udev? kind regards, Thomas Penteker --