Rudolf Deilmann <rudolf.deilmann@xxxxxxxxx> wrote:
> my initrd is several megabytes long - and it includes nearly all
> modules (for example ext3). But this is "default behaviour" under
> Ubuntu. Even, if you don't use root encryption, it uses the initial
> ramdisk for system startup. Just the loop modules, gpg, losetup, and
> the startup scripts need to be added.
Ok, this size issue is something I derive from loop-aes README where it says in "7.5. Example 5 - Encrypting root partition":
12) Build a new /boot/initrd.gz
./build-initrd.sh
--> Note: /boot/initrd.gz is supposed to be small (2 KB to 3 KB).<----
All other
utilities (loop.o module, insmod, losetup, loadkeys, gpg and possibly
libraries) are copied to /boot directory. Libraries are not copied if
programs are statically linked.
A further link is her:
http://mail.nl.linux.org/linux-crypto/2001-12/msg00072.html
where Jari himself states the initrd.gz shall be around 1.6 kb. I´m not keen enough on this to deem the disadvantages of 7-10 mb large init-ramdisks right. At present my box has 1.25 gb of RAM and still lacks memory. I easily recall ugly glitches when recompiling SuSE kernel-sources to make it work. Right now, I followed the same pattern on Kubuntu and ended up with a .deb package of my new kernel & modules. Size is about 180 mb.
> However, apt sometimes destroys your hand-made changes, so your
> system won't boot any longer,...
> And of course, you have to build new loop-aes modules after a kernel
> update.
> Another problem are the loop-aes-utils. Sometimes, there are updates for
> the util-linux (mount,...) packages, but unlike debian, they don't
> provide updates for the loop-aes-utils in all cases.
That´s why I followed the README and built all the stuff from source. Of course at the expense of losing the comfort to update packages with a click.
> "Most" modules are included in your initial ramdisk at
> default.
> You can influence this by changing /etc/initramfs-tools/initramfs.conf
> see 'man initramfs.conf':
> --
> MODULES
> Specifies the modules for the initramfs image. The default setting is
> most.
> most adds all the framebuffer, acpi, file system, ide, sata, scsi and
> usb drivers.
So this section would replace the kernel-recompile..... Guessing which modules are needed or simply including "most" ;-)
> I've got this hint from here:
> http://d-i.pascal.at/:
> ---
> Partitionless installation: Instead of /dev/sda1 you may also
> use /dev/sda as your target. This leaves your stick without a partition
> table so that it will contain only the file system. The advantage of
> this method is that you don't have to rely on the existing (and
> possibly buggy) master boot record (MBR) of your USB stick. But be
> aware that you won't be able to access your stick using some
> third-party operating systems.
Interesting page. I use /dev/sda1 and can still use the stick for other things as well. With my board it works quite well. Memory sticks work better than memory cards in certain card readers...
> I've test it with three different motherboards.
> One usb-stick works with two motherboards without any
> problems, but it don't work on the other one. Another usb-stick don't
> work with any motherboard. After I've removed the partition tables, all
> problems are gone. Also, syslinux seems to be better than grub for such
> purpose. But, three different motherboards aren't enough to make
> general claims ...
Well here the disadvantage of syslinux is its dependence on FAT. I never used grub for this, simply because syslinux prepares the stick with one command. Hopefully support from motherboards for booting from usb will grow! A new board without this feature would be a nightmare.
Kind regards,
Peter
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
