~alpine/devel

1

Re: [alpine-devel] [PATCH] Main/mkinitfs - small Patch for LUKS / Cryptsetup

Timo Teras <timo.teras@iki.fi>
Details
Message ID
<20140213105406.0b0c9eb6@vostro>
Sender timestamp
1392281646
DKIM signature
missing
Download raw message
On Wed, 12 Feb 2014 19:26:10 +0000
IT Developer <developer@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
mkinitfs fixed.

> 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
trigger mkinitfs.

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.

- Timo




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] [PATCH] Main/mkinitfs - small Patch for LUKS / Cryptsetup

Details
Message ID
<52FD5043.30509@it-offshore.co.uk>
In-Reply-To
<20140213105406.0b0c9eb6@vostro> (view parent)
Sender timestamp
1392332867
DKIM signature
missing
Download raw message
I did a LUKS + LVM install today in a virtual machine & the "apk fix
--root /mnt linux-grsec" still works on a CHROOT. EXTLINUX correctly
finds the boot partition & writes the needed files to /boot (for some
reason EXTLINUX exits with "cannot open /dev/sda1 - exit error 1" - but
the system boots ok. It's only on kernel upgrades that mkinitfs is not
being triggered to rebuild with cryptsetup included which causes a problem.

I would be happy to do a page for the wiki on LUKS + LVM installations.

Stuart.

On 02/13/2014 08:54 AM, Timo Teras wrote:
> On Wed, 12 Feb 2014 19:26:10 +0000
> IT Developer <developer@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
> mkinitfs fixed.
>
>> 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
> trigger mkinitfs.
>
> 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.
>
> - Timo
>
>
Reply to thread Export thread (mbox)