I earlier wrote:
>
> I'm interested to use an encrypted root filesystem, by using cryptsetup in
> initramfs.
>
> I'm finding that adding cryptsetup to an initramfs image increases its size by
> about 4 MB. It seems that cryptsetup depends on openssl and lvm2, and
> lvm2 depends on bash, and the result of that is that a lot of extra files get
> dragged in.
>
> Is this all strictly necessary? Perhaps cryptsetup really only needs
> libraries,
> not all of openssl and lvm2.
>
> What would be a good way to go about reducing the dependencies that get
> pulled in for cryptsetup?
>
> I also noticed that libgcrypt could possibly be used instead of openssl (by
> putting in bbappend, PACKAGECONFIG = ""), saving about 0.5 MB. However
> libgcrypt isn't used, according to the cryptsetup bb file, because it drops
> root
> privileges if it is linked with libcap support. That gives the obscure
> cryptsetup
> error "Cannot initialize device-mapper. Is dm_mod kernel module loaded?"
> when trying to use cryptsetup with libgcrypt. Is there any reasonable work-
> around for this?
I found that I can cut it down significantly, using the following
lvm2_2.%.bbappend:
-----------------------------------------------------------
PACKAGES =+ "lvm2-libdevmapper"
# ${base_libdir}/udev ${sbindir}/dmsetup are to get device mapper udev rules,
# to avoid cryptsetup luksOpen hanging.
FILES_lvm2-libdevmapper = "${libdir}/libdevmapper.so.* ${base_libdir}/udev
${sbindir}/dmsetup"
RDEPENDS_lvm2-libdevmapper = "bash"
RDEPENDS_${PN} += " lvm2-libdevmapper"
RPROVIDES_${PN}-dev = "lvm2-libdevmapper-dev"
-----------------------------------------------------------
That cuts out a bunch of unneeded lvm files.
I'm not sure why there needs to be a bash dependency, but it didn't work
without it. I'd like to get rid of bash if it's possible.
(After reading more about libgcrypt, I think I'll just stick with openssl. It
seems questionable design for the library, to drop an application's
capabilities.)
--
Craig McQueen
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
