1 |
On Wed, Nov 30, 2011 at 8:23 PM, David W Noon <dwnoon@××××××××.com> wrote: |
2 |
> On Wed, 30 Nov 2011 19:39:11 -0500, Michael Mol wrote about "Re: |
3 |
> [gentoo-user] Re: Full disk encryption": |
4 |
> |
5 |
> [snip] |
6 |
>>Stupid question...Would using LZMA and a tarball reduce the size of |
7 |
>>your initeamfs? |
8 |
> |
9 |
> Not really. I am already using gzip -9, and binaries don't compress |
10 |
> especially well. Moreover, the archiver *must* be cpio, not tar. |
11 |
|
12 |
I don't understand initrd that well, but I understand you run an |
13 |
init-type script inside it. |
14 |
|
15 |
My thought was: |
16 |
1) Include enough in your cpio blob to extract a .tar.xz file. Even |
17 |
better if you can use a self-extracting, statically-linked LZMAball. |
18 |
2) launch a second-stage init sequence from the subsequently-extracted data. |
19 |
|
20 |
Large groups of binaries can compress pretty well, but, obviously, it |
21 |
depends greatly on the data in question. |
22 |
|
23 |
Also, wasn't there an ELF-specific compressor making the rounds a few |
24 |
months ago? And I take it there are no existing tools to take a |
25 |
dynamically-linked binary, pack in all the pulled-in files, rewrite |
26 |
symbol tables to include only the symbols used, pull the thing all |
27 |
into a single now-statically-linked binary, and perform something like |
28 |
COMDAT folding to remove duplicate functions? It would seem possible, |
29 |
at least. |
30 |
|
31 |
-- |
32 |
:wq |