* Juergen Daubert ([email protected]) 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 --
pgpIJHNGo4Ntb.pgp
Description: PGP signature
_______________________________________________ crux-devel mailing list [email protected] http://lists.crux.nu/mailman/listinfo/crux-devel
