Message-ID: <52FD5043.30509@it-offshore.co.uk>
Date: Thu, 13 Feb 2014 23:07:47 +0000
From: IT Developer <developer@it-offshore.co.uk>
Reply-To: developer@it-offshore.co.uk
Organization: IT Offshore
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
Precedence: list
MIME-Version: 1.0
To: Timo Teras <timo.teras@iki.fi>
CC: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] [PATCH] Main/mkinitfs - small Patch for LUKS /
 Cryptsetup
References: <1392158622-21396-1-git-send-email-developer@it-offshore.co.uk>	<20140212081021.24b9d693@vostro>	<52FBCAD2.5070606@it-offshore.co.uk> <20140213105406.0b0c9eb6@vostro>
In-Reply-To: <20140213105406.0b0c9eb6@vostro>
Content-Type: multipart/alternative;
 boundary="------------070100010400060109070509"

This is a multi-part message in MIME format.
--------------070100010400060109070509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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
>
>


--------------070100010400060109070509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000099">
    <div align="justify"><font face="Helvetica, Arial, sans-serif">I did
        a LUKS + LVM install today in a virtual machine &amp; the "apk
        fix --root /mnt linux-grsec" still works on a CHROOT. EXTLINUX
        correctly finds the boot partition &amp; 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.</font><br>
      <br>
      <font face="Helvetica, Arial, sans-serif">I would be happy to do a
        page for the wiki on LUKS + LVM installations.</font><br>
    </div>
    <font face="Helvetica, Arial, sans-serif"><br>
      Stuart.<br>
      <br>
    </font>
    <div class="moz-cite-prefix">On 02/13/2014 08:54 AM, Timo Teras
      wrote:<br>
    </div>
    <blockquote cite="mid:20140213105406.0b0c9eb6@vostro" type="cite">
      <pre wrap="">On Wed, 12 Feb 2014 19:26:10 +0000
IT Developer <a class="moz-txt-link-rfc2396E" href="mailto:developer@it-offshore.co.uk">&lt;developer@it-offshore.co.uk&gt;</a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">When mkinitfs is run on it's own for example (as shown on the wiki):

/*mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT*/
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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)
</pre>
      </blockquote>
      <pre wrap="">
So the problem occurs only when doing chroot installs?

</pre>
      <blockquote type="cite">
        <pre wrap="">I don't know what extra "apk fix" does - but it does call mkinitfs
correctly &amp; 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.
</pre>
      </blockquote>
      <pre wrap="">
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


</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070100010400060109070509--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---