Am Fri, 18 Jan 2008 15:07:36 +0100
schrieb Peter_22@xxxxxx:
> True, to some extend. I prepared a usb-stick the way you told me. So
> far the standard Kubuntu kernel and its initrd can boot the
> (unencrypted) machine from that usb-stick. It took a while until I
> remembered your explainations when I addressed this keymap issue in
> connection with Kubuntu 7.04 ... However, there is one thing popping
> up: size of the initrd! How large is the initrd you built?
> the hard way as I did, I got a tiny 2.6 kb initrd - just as it is
> supposed to be. Consider, I rebuilt the kernel to include ext3,
> usb{core,storage},sata and the like. Isn´t it true that your initrd
> has to include all these modules and so will end up being several
> mega bytes large?
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.
> disadvantages in connection with proprietary drivers (nvidia) and of
> course I can´t update my kernel with the SuSE updater / ubuntu´s
> adept.
you have to be careful with adept, especially if you use an
boot-partition instead of an usb-stick.
Root encryption works will with an unencrypted boot partition and grub,
too. You just need to change the /boot/menu.lst :
at default it looks like this:
----
default 0
timeout 3
hiddenmenu
title Ubuntu gutsy (development branch), kernel
2.6.22-12-generic root (hd0,0)
kernel /vmlinuz-2.6.22-12-generic
root=UUID=590af9e0-9a80-407b-8112-57083ee40a64 ro quiet splash
locale=de_DE initrd /initrd.img-2.6.22-12-generic quiet
...
----
you have remove the splash and replace the UUID:
----
default 0
timeout 3
hiddenmenu
title Ubuntu gutsy (development branch), kernel
2.6.22-12-generic
root (hd0,0)
kernel /vmlinuz-2.6.22-12-generic root=/dev/loop6 ro
quiet locale=de_DE
initrd /initrd.img-2.6.22-12-generic
quiet
----
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.
> This means I have to list all modules here which I would otherwise
> build into the kernel to make it work? I remember there was an issue
> with the initrd to be small in size as its space in memory cannot be
> freed.
"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.
....
--
Of course, if you change it to 'list', you need to add them manually.
But default is: MODULES=most
I don't know, if there are any problems with large initial
ramdisks. If there are such problems, you will have them in any case -
because the initial ramdisk is that large, even if you don't use root
encryption.
(I've added fbcon and vesafb, because there are some problems with them
under Ubuntu. I don't rember exactly, but I think, Ubuntu put them on
some blacklist file, because they are very buggy. If you want to use
them nevertheless, you have to remove them from this blacklist file and
add them to /etc/initramfs-tools/modules )
And as said before, you can
simply unpack your initial ramdisk. If there are some modules missing,
you think you need during system startup, you can add them
to /etc/initramfs-tools/modules .
> > USB-Sticks without partition table works best at most
> > motherboards,...
> From what do you know this? Do you have experience with a large
> number of motherboards or is there some kind of documentation for
> this?
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.
---
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 ...
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
