On Wed, 12 Feb 2014 19:26:10 +0000
IT Developer <developer_at_it-offshore.co.uk> wrote:
> When mkinitfs is run on it's own for example (as shown on the wiki):
> /*mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT*/
The differences are that when apk runs the trigger, it's executed in
chroot. And command is like 'mkinitfs -o /boot/$initfs $abi_release'
This sounds like mkinitfs bug, or mismatch with running kernel and
installed kernel versions. The wiki should likely be updated or
> The initramfs does not contain cryptsetup
> Cryptsetup is included when apk is run with:
> /*apk fix --root $MNT linux-grsec*/ (or just /*apk fix linux-grsec*/
> on a running system)
So the problem occurs only when doing chroot installs?
> I don't know what extra "apk fix" does - but it does call mkinitfs
> correctly & generates an initramfs with cryptsetup included. At the
> moment upgrading a kernel on an encrypted system does not generate a
> new initramfs with cryptsetup included.
> I am using a system with LVM on top of LUKS - when I upgraded to the
> edge kernel a few days ago I did not see any initramfs regeneration -
> even for LVM.
Mkinitfs trigger is "$pkgname.trigger=/usr/share/kernel/*" and I
believe only kernel images touch those files. Sounds like kernel module
packages as well as userland packages that go to initramfs should also
ncopa, any idea how to do that properly? Perhaps we should have
some /usr/share/mkinitfs/components/ directory where each of these
package can install a file - and mkinitfs trigger monitors that
directory and in case something changes there it regens initfs for
all kernel flavors installed.
Received on Thu Feb 13 2014 - 10:54:06 UTC