Re: [gentoo-user] Re: Full disk encryption
On Sat, 3 Dec 2011 00:44:18 +, David W Noon wrote: The reason for that working is that the fsck command loads fsck.ext2, not e2fsck. That used to be a symlink to e2fsck, but these days it is a separate copy (byte-for-byte identical). Doh! -- Neil Bothwick Does fuzzy logic tickle? signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Thu, 1 Dec 2011 14:03:18 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: On Thu, 1 Dec 2011 13:43:01 +, David W Noon wrote: [snip] I need to fsck / before I mount /usr, /var and everything else. Now it makes sense, but can't you use busybox fsck? AFAIAA, busybox does not have an fsck command. If it did, it would only be a transparent loader for filesystem-specific programs, such as e2fsck or reiserfsck; this is how the standard fsck program works too. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Fri, 2 Dec 2011 22:00:18 +, David W Noon wrote: Now it makes sense, but can't you use busybox fsck? AFAIAA, busybox does not have an fsck command. If it did, it would only be a transparent loader for filesystem-specific programs, such as e2fsck or reiserfsck; this is how the standard fsck program works too. Busybox does have an fsck, it doesn't recognise the filesystem type, you have to give it as an argument. A quick Google suggest that it does indeed pass the work on to e2fsck, however, I tried renaming /sbin/e2fsck and then running busybox fsck -t ext2 /dev/summat and it worked. -- Neil Bothwick Copy from another: plagiarism. Copy from many: research. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Fri, 2 Dec 2011 23:24:29 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: [snip] Busybox does have an fsck, it doesn't recognise the filesystem type, you have to give it as an argument. A quick Google suggest that it does indeed pass the work on to e2fsck, however, I tried renaming /sbin/e2fsck and then running busybox fsck -t ext2 /dev/summat and it worked. The reason for that working is that the fsck command loads fsck.ext2, not e2fsck. That used to be a symlink to e2fsck, but these days it is a separate copy (byte-for-byte identical). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Thu, 1 Dec 2011 00:27:06 +, David W Noon wrote: Why not mount root read-only, just like in a non-initramfs system? Any e2fsck commands will be run during the boot runlevel, before remounting root rw. Unfortunately, the system does not work that way. When running inside an initramfs, one cannot load executable content from mount points -- only from within the initramfs. So, while it is perfectly possible to do ls /mnt/root/sbin/e2fsck (assuming the root partition has been mounted ro as /mnt/root), it is not possible to load and execute that program. [And, yes, I have adjusted the PATH and LD_LIBRARY_PATH shell variables to address the program and library directories on the mounted root partition.] After performing a switch_root to the actual root partition, this restriction is lifted. I understand that, but not why you need to run e2fsck before the switch_root. Is this to do with the way your system is set up? The object of the initramfs is only to get the system into a state where / can be mounted and switch_root run, I assume you are trying to do more than that with it. -- Neil Bothwick WORM: (n.) acronym for Write Once, Read Mangled. Used to describe a normally-functioning computer disk of the very latest design. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Thu, 1 Dec 2011 08:47:27 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: On Thu, 1 Dec 2011 00:27:06 +, David W Noon wrote: [snip] Unfortunately, the system does not work that way. When running inside an initramfs, one cannot load executable content from mount points -- only from within the initramfs. So, while it is perfectly possible to do ls /mnt/root/sbin/e2fsck (assuming the root partition has been mounted ro as /mnt/root), it is not possible to load and execute that program. [And, yes, I have adjusted the PATH and LD_LIBRARY_PATH shell variables to address the program and library directories on the mounted root partition.] After performing a switch_root to the actual root partition, this restriction is lifted. I understand that, but not why you need to run e2fsck before the switch_root. Is this to do with the way your system is set up? The object of the initramfs is only to get the system into a state where / can be mounted and switch_root run, I assume you are trying to do more than that with it. The objective is to get /, /usr, /var and any other directory path the user feels is needed mounted before udev starts. This is a continuation of the udev now sucks thread from a few months ago. I need to fsck / before I mount /usr, /var and everything else. This is because the mount point directories could be zombies that would be removed by fsck, thus invalidating the mount. We all hope that /usr and /var are not zombies, but fsck won't take my word for it. -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Thu, 1 Dec 2011 13:43:01 +, David W Noon wrote: I understand that, but not why you need to run e2fsck before the switch_root. Is this to do with the way your system is set up? The object of the initramfs is only to get the system into a state where / can be mounted and switch_root run, I assume you are trying to do more than that with it. The objective is to get /, /usr, /var and any other directory path the user feels is needed mounted before udev starts. This is a continuation of the udev now sucks thread from a few months ago. I need to fsck / before I mount /usr, /var and everything else. Now it makes sense, but can't you use busybox fsck? -- Neil Bothwick An expert is nothing more than an ordinary person away from home. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
Neil Bothwick wrote: On Thu, 1 Dec 2011 13:43:01 +, David W Noon wrote: I understand that, but not why you need to run e2fsck before the switch_root. Is this to do with the way your system is set up? The object of the initramfs is only to get the system into a state where / can be mounted and switch_root run, I assume you are trying to do more than that with it. The objective is to get /, /usr, /var and any other directory path the user feels is needed mounted before udev starts. This is a continuation of the udev now sucks thread from a few months ago. I need to fsck / before I mount /usr, /var and everything else. Now it makes sense, but can't you use busybox fsck? I thought the file system was mounted ro, then the file system checks done, then remounted rw and boot continues on? I see mine do this without the init thingy and from what I see as things zoom by, that is what it does. What am I missing here? Just curious. No flaming please. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Full disk encryption
On Thu, 01 Dec 2011 08:13:24 -0600, Dale wrote: I need to fsck / before I mount /usr, /var and everything else. Now it makes sense, but can't you use busybox fsck? I thought the file system was mounted ro, then the file system checks done, then remounted rw and boot continues on? I see mine do this without the init thingy and from what I see as things zoom by, that is what it does. What am I missing here? That's how it normally happens, with or without an initramfs, but mounting /usr on / without checking / first could possibly be problematic if / turns out to be corrupt. That is the situation David is trying to guard against. I'm not sure it's a big deal, because if / is badly corrupt, the main init will bail out soon enough anyway. -- Neil Bothwick Love is grand. Divorce is a few grand more. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, Nov 30, 2011 at 8:23 PM, David W Noon dwn...@ntlworld.com wrote: On Wed, 30 Nov 2011 19:39:11 -0500, Michael Mol wrote about Re: [gentoo-user] Re: Full disk encryption: [snip] Stupid question...Would using LZMA and a tarball reduce the size of your initeamfs? Not really. I am already using gzip -9, and binaries don't compress especially well. Moreover, the archiver *must* be cpio, not tar. I don't understand initrd that well, but I understand you run an init-type script inside it. My thought was: 1) Include enough in your cpio blob to extract a .tar.xz file. Even better if you can use a self-extracting, statically-linked LZMAball. 2) launch a second-stage init sequence from the subsequently-extracted data. Large groups of binaries can compress pretty well, but, obviously, it depends greatly on the data in question. Also, wasn't there an ELF-specific compressor making the rounds a few months ago? And I take it there are no existing tools to take a dynamically-linked binary, pack in all the pulled-in files, rewrite symbol tables to include only the symbols used, pull the thing all into a single now-statically-linked binary, and perform something like COMDAT folding to remove duplicate functions? It would seem possible, at least. -- :wq
Re: [gentoo-user] Re: Full disk encryption
On Thu, 1 Dec 2011 11:41:50 -0500, Michael Mol wrote about Re: [gentoo-user] Re: Full disk encryption: On Wed, Nov 30, 2011 at 8:23 PM, David W Noon dwn...@ntlworld.com wrote: On Wed, 30 Nov 2011 19:39:11 -0500, Michael Mol wrote about Re: [gentoo-user] Re: Full disk encryption: [snip] Stupid question...Would using LZMA and a tarball reduce the size of your initeamfs? Not really. I am already using gzip -9, and binaries don't compress especially well. Moreover, the archiver *must* be cpio, not tar. I don't understand initrd that well, but I understand you run an init-type script inside it. My thought was: 1) Include enough in your cpio blob to extract a .tar.xz file. Even better if you can use a self-extracting, statically-linked LZMAball. 2) launch a second-stage init sequence from the subsequently-extracted data. Large groups of binaries can compress pretty well, but, obviously, it depends greatly on the data in question. The initramfs is already a compressed archive. It can be compressed using gzip, bzip2 or lzma/xz. All of these give only modest reduction in size. Also, wasn't there an ELF-specific compressor making the rounds a few months ago? And I take it there are no existing tools to take a dynamically-linked binary, pack in all the pulled-in files, rewrite symbol tables to include only the symbols used, pull the thing all into a single now-statically-linked binary, and perform something like COMDAT folding to remove duplicate functions? It would seem possible, at least. The problem with that is that internal references within a .so library are somewhat ambiguous, because the address constants have already been partially relocated, eliminating symbol dictionary lookups (i.e. references that were originally external have been made internal by symbol dictionary lookup and then the symbol converted into an offset within the load library). In contrast, an ar-format library is simply a collection of object decks (old mainframe term) indexed by their external symbols. Thus the linker is forced to keep doing symbol dictionary lookups and object code extraction from libraries until all the external references have been resolved. There are no unresolved external references left in a correctly linked .so library, so this process cannot be repeated. The only feasible option I can think of is to use a full delinker on the main program. [I wrote one of these delinkers for the IBM mainframe back in the 1980s, so it's a technology I understand fairly well.] This would reverse all the partially relocated addresses back to external references by a reverse lookup in the symbol dictionary and relocation dictionary. This could restore the original object deck(s) of the main program and it/they could be relinked using the static libraries (if they exist). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Dec 1, 2011 3:32 AM, David W Noon dwn...@ntlworld.com wrote: - 8 snip I have a working initramfs layout, but currently it is too large (32MiB) for my /boot partition. The problem package is e2fsprogs, as it requires dynamic linkage and, consequently, a full-sized glibc. This sucks, so I need to patch the Makefile(s) to build a more sensible set of executables for an initramfs. All of the code I have written myself compiles and links statically, typically using klibc, so my finished code is tiny. I haven't been working on this for a couple of months now, because the need for it is not really pressing. The assertion that udev would require /usr and /var (plus the kitchen sink) really soon is unfounded, at least for those of us who run more elderly hardware. Anyhow, when I'm finished there will be a zsh script that will build an initramfs image, and even install it to /boot, with a single command. You know, Debian has an e2fsck-static package. Why don't Gentoo, I wonder... That said, you *can* have an almost-static e2fsck if you compile it yourself. Rgds,
[gentoo-user] Re: Full disk encryption
czernitko wrote: I would like to have only one partition with all home directories on it, and I would like to avoid usage of initrd as I don't use it now and I would like to keep it that way if possible. You don't need an initramfs but you might want to reconsider not using one at some point. I avoided them for a long time but when I wanted to do whole disk encrypted I learned how to make my own (not particularly difficult) and later started using dracut which basically just works.
Re: [gentoo-user] Re: Full disk encryption
Jack Byer wrote: czernitko wrote: I would like to have only one partition with all home directories on it, and I would like to avoid usage of initrd as I don't use it now and I would like to keep it that way if possible. You don't need an initramfs but you might want to reconsider not using one at some point. I avoided them for a long time but when I wanted to do whole disk encrypted I learned how to make my own (not particularly difficult) and later started using dracut which basically just works. Did you use a howto for Dracut? If so, have a link you could post? I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. The unofficial wiki. Thanks. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Full disk encryption
Yup, establishing encrypted partition for /home was easy as a pie using cryptsetup. I was considering using truecrypt as it offers multiplatform support, so I could access encrypted partition even from my dualbooted windoze, but I didn't want to put effort into something not as well documented (how-toed) as dmcrypt. As for initrd, I believe it has a lot of advantages, but as long as I can avoid it, I don't see any reason why to spend time learning that stuff and making my kernel deployment more complicated. I know that one day I will have to learn that stuff. But as far as it is not today, it makes my day even better :) Thanks for all your responses! Peter
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 12:31:00 -0600, Dale wrote: Did you use a howto for Dracut? If so, have a link you could post? I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. That worked for me (dracut didn't). If it fails, make sure you have set ity to drop you into a rescue shell as described on the wiki. Adding a few echo and ls commands to the init script helps too. -- Neil Bothwick Blessed be the pessimist for he hath made backups. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
Am Mittwoch, den 30.11.2011, 19:32 +0100 schrieb czernitko: Yup, establishing encrypted partition for /home was easy as a pie using cryptsetup. I was considering using truecrypt as it offers multiplatform support, so I could access encrypted partition even from my dualbooted windoze, but I didn't want to put effort into something not as well documented (how-toed) as dmcrypt. You can use FreeOTFE[0] for that. I don't use Windows, so I can't tell whether you need to install the filesystem driver for Windows. [0] http://www.freeotfe.org/
Re: [gentoo-user] Re: Full disk encryption
Neil Bothwick wrote: On Wed, 30 Nov 2011 12:31:00 -0600, Dale wrote: Did you use a howto for Dracut? If so, have a link you could post? I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. That worked for me (dracut didn't). If it fails, make sure you have set ity to drop you into a rescue shell as described on the wiki. Adding a few echo and ls commands to the init script helps too. I did. It failed so badly even the rescue didn't work. I did get some flashing lights and introduced to the reset button tho. We all know what happened the last time I had to hit the reset button. :/ Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Full disk encryption
I wonder whether it is posible to simply resize the dm-crypt encrypted partition? Or do I have to create new, bigger partition with required size and move the data? Peter
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 12:31:00 -0600, Dale wrote about Re: [gentoo-user] Re: Full disk encryption: [snip] I tried making a init thingy and after about 20 failed reboots, I scraped the idea. I was trying to follow the howto on the Gentoo wiki I think. The unofficial wiki. I posted a couple of months ago that you should watch this space for a small and simple initramfs solution. That still applies. I have a working initramfs layout, but currently it is too large (32MiB) for my /boot partition. The problem package is e2fsprogs, as it requires dynamic linkage and, consequently, a full-sized glibc. This sucks, so I need to patch the Makefile(s) to build a more sensible set of executables for an initramfs. All of the code I have written myself compiles and links statically, typically using klibc, so my finished code is tiny. I haven't been working on this for a couple of months now, because the need for it is not really pressing. The assertion that udev would require /usr and /var (plus the kitchen sink) really soon is unfounded, at least for those of us who run more elderly hardware. Anyhow, when I'm finished there will be a zsh script that will build an initramfs image, and even install it to /boot, with a single command. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 21:19:51 +0100, czernitko wrote: I wonder whether it is posible to simply resize the dm-crypt encrypted partition? Or do I have to create new, bigger partition with required size and move the data? Enlarge the partition then use cryptsetup resize to enlarge the encrypted device (man cryptsetup has the details). Then resize the filesystem to fit. -- Neil Bothwick Keyboard: (n.) a device used by programmers to write software for a mouse or joystick and by operators for playing games such as 'word processing.' signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 20:28:28 +, David W Noon wrote: I have a working initramfs layout, but currently it is too large (32MiB) for my /boot partition. The problem package is e2fsprogs, as it requires dynamic linkage and, consequently, a full-sized glibc. Why do you need e2fsprogs on an initramfs? -- Neil Bothwick mpeg@11.. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 21:47:33 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: On Wed, 30 Nov 2011 20:28:28 +, David W Noon wrote: I have a working initramfs layout, but currently it is too large (32MiB) for my /boot partition. The problem package is e2fsprogs, as it requires dynamic linkage and, consequently, a full-sized glibc. Why do you need e2fsprogs on an initramfs? One needs e2fsck to do a preen prior to mounting the required volume(s). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 22:07:35 +, David W Noon wrote: Why do you need e2fsprogs on an initramfs? One needs e2fsck to do a preen prior to mounting the required volume(s). Why not mount root read-only, just like in a non-initramfs system? Any e2fsck commands will be run during the boot runlevel, before remounting root rw. -- Neil Bothwick Top Oxymorons Number 21: Now, then ... signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 23:26:56 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: On Wed, 30 Nov 2011 22:07:35 +, David W Noon wrote: Why do you need e2fsprogs on an initramfs? One needs e2fsck to do a preen prior to mounting the required volume(s). Why not mount root read-only, just like in a non-initramfs system? Any e2fsck commands will be run during the boot runlevel, before remounting root rw. Unfortunately, the system does not work that way. When running inside an initramfs, one cannot load executable content from mount points -- only from within the initramfs. So, while it is perfectly possible to do ls /mnt/root/sbin/e2fsck (assuming the root partition has been mounted ro as /mnt/root), it is not possible to load and execute that program. [And, yes, I have adjusted the PATH and LD_LIBRARY_PATH shell variables to address the program and library directories on the mounted root partition.] After performing a switch_root to the actual root partition, this restriction is lifted. When running without (or with the default) initramfs, the root partition itself becomes the active filesystem, so loading programs from /sbin or /bin and libraries from /lib works as expected. This might be one of Dale's problems, if he was trying to use commands from the root filesystem within the initramfs. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* signature.asc Description: PGP signature
Re: [gentoo-user] Re: Full disk encryption
David W Noon wrote: This might be one of Dale's problems, if he was trying to use commands from the root filesystem within the initramfs. I don't think that was the issue. I had nano, busybox and that was it. Basically, I just wanted it to be able to load enough that it could boot even if /usr and /var was on a separate partition. Nothing real fancy, just the basics. I was going to save the fancy stuff for later. Still, it didn't work. I fixed one error only to have another. The last error, I couldn't find a fix for. I don't even recall what it was now. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Full disk encryption
Stupid question...Would using LZMA and a tarball reduce the size of your initeamfs? ZZ On Nov 30, 2011 7:30 PM, David W Noon dwn...@ntlworld.com wrote: On Wed, 30 Nov 2011 23:26:56 +, Neil Bothwick wrote about Re: [gentoo-user] Re: Full disk encryption: On Wed, 30 Nov 2011 22:07:35 +, David W Noon wrote: Why do you need e2fsprogs on an initramfs? One needs e2fsck to do a preen prior to mounting the required volume(s). Why not mount root read-only, just like in a non-initramfs system? Any e2fsck commands will be run during the boot runlevel, before remounting root rw. Unfortunately, the system does not work that way. When running inside an initramfs, one cannot load executable content from mount points -- only from within the initramfs. So, while it is perfectly possible to do ls /mnt/root/sbin/e2fsck (assuming the root partition has been mounted ro as /mnt/root), it is not possible to load and execute that program. [And, yes, I have adjusted the PATH and LD_LIBRARY_PATH shell variables to address the program and library directories on the mounted root partition.] After performing a switch_root to the actual root partition, this restriction is lifted. When running without (or with the default) initramfs, the root partition itself becomes the active filesystem, so loading programs from /sbin or /bin and libraries from /lib works as expected. This might be one of Dale's problems, if he was trying to use commands from the root filesystem within the initramfs. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: [gentoo-user] Re: Full disk encryption
On Wed, 30 Nov 2011 19:39:11 -0500, Michael Mol wrote about Re: [gentoo-user] Re: Full disk encryption: [snip] Stupid question...Would using LZMA and a tarball reduce the size of your initeamfs? Not really. I am already using gzip -9, and binaries don't compress especially well. Moreover, the archiver *must* be cpio, not tar. -- Regards, Dave [RLU #314465] == dwn...@ntlworld.com (David W Noon) == signature.asc Description: PGP signature
