On Mon, 19 Sep 2016 at 06:39:35 -0500, Richard Laager wrote:
> On 09/19/2016 04:48 AM, Guilhem Moulin wrote:
>> On Mon, 19 Sep 2016 at 00:51:45 -0500, Richard Laager wrote:
>>> On 09/18/2016 02:13 PM, Guilhem Moulin wrote:
>> Alright, thanks!  I think a more robust AWK or sed script is desired to
>> strip out the header, though.  Perhaps this AWK script
> That awk script doesn't output anything for me.

Interesting, worksforme™ both with gawk(1) and mawk(1).  Perhaps an
issue with TAB vs spaces?  Could you redirect the output of `zfs status
-P $pool` to a file and attach that file instead of copy-paste the

> How about this, which I used in the attached updated patch:
> awk 'NR == 1, /^[\t ]*config:/ { next } { if ($1 ~ /^\//) { print $1 } }'
> Or if you want to match the logic of GRUB2 (which I think is messier):
> awk 'NR == 1, /^[\t ]*NAME[\t ]+STATE[\t ]+READ[\t ]+WRITE[\t ]+CKSUM/ { next 
> } { if ($1 ~ /^\//) { print $1 } }'

Well sorry for the nitpick, but both are broken if the command happens
to produce an output for which triggering line matches the wrapped value
of another header.  For instance consider

    note: blah blah see under
          config: for details.
          This is the remaining "note:", not "config:"

That being said, if as you said GRUB would choke on such corner cases
maybe it's not high priority in cryptsetup.  But it doesn't hurt to try
to get parsing right either ;-)
>>>> But I still think we can find a solution that's not FS-specific.  For
>>>> instance, to ensure that an arbitrary device is unlocked at initramfs
>>>> stage, you can add ‘initramfs’ to the 4th column of its crypttab(5)
>>>> entry.  In your case, that should be enough to copy the key files of
>>>> the underlying devices to the initramfs image.
> Yes, that works. The "WARNING: could not determine root device" message
> is still printed.

That's just a warning :-)  But maybe it should go away when “root=” is
found in /proc/cmdline.

>> Again, I'm not fond of your `zfs list` command because it's an
>> FS-specific alternative for two FS-agnostic and de facto standard
>> solutions, namely fstab(5) and kernel parameters.
> I've attached another version of this patch. It first swaps from
> /etc/fstab to /proc/self/mounts. Then adding ZFS support is trivial and
> integrates in the same way as btrfs support.

Hmm, swapping /etc/fstab for /proc/self/mounts seems like a major
change, with potential undesired consequences.  Up to now the device
associated to a given mountpoint was the one found in fstab(5), which is
not necessarily the one currently mounted.


Attachment: signature.asc
Description: PGP signature

Reply via email to