Hi,
Here is a patch that ignores zfs filesystems as you recommended by
returning an empty devno for such devices and then skipping the warning
and error messages when there is no major/minor number.
--
Jean-Baptiste Lallement
irc: jibel
diff -Nru cryptsetup-2.3.3/debian/changelog
Hi,
with current 2.1.0-5 in buster, dist-upgrade of encrypted zfs root
installations fails to boot. took me some while to find this hintwith
the initramfs in crypttab (my original solution was to bring cryptsetup
packages form stretch, noticed this randomly later)
signature.asc
Description:
Hi,
On Sat, 21 Jul 2018 at 19:27:54 +0200, Michal Humpula wrote:
> Since the ZFS is not strictly speaking alien in Debian (it's in
> contrib, though), it would be nice if cryptsetup-initramfs would
> support it.
Just to be clear, it's only *auto-detection* that's not supported. It's
still
Hi Guilhem,
I may have found the answer to the question, why there is still no sysfs
interface for the ZFS. Kernel object representing the `/sys/fs` directory is
exported as GPL only, so it's not possible to use it in non GPL module, which
unfortunately ZFS is (CDDL).
Since the ZFS is not
On Thu, 05 Jul 2018 at 11:05:08 +0200, Michal Humpula wrote:
>> Since ZFS doesn't expose a block device one would need another
>> documented way to resolve /sys/fs/zfs/$FS. Hopefully ‘tank/my/fs’ is
>> unique and can't be aliased to something else, can it?
>
>> Do the slash characters in
> Since ZFS doesn't expose a block device one would need another
> documented way to resolve /sys/fs/zfs/$FS. Hopefully ‘tank/my/fs’ is
> unique and can't be aliased to something else, can it?
> Do the slash characters in ‘tank/my/fs’ hint at a hierarchy, or is it a
> flat string?
It's unique
Hi Michal,
On Tue, 03 Jul 2018 at 18:23:12 +0200, Michal Humpula wrote:
> Entry in /proc/mounts for ZFS is different as it refers to the actual ZFS
> filesystem not to the devices of the underlying zpool. Which, from my point
> of
> view, makes more sense. Do you see a way to export all the
Hi Guilhem,
I can see the point against implementing the specific FS quirks. I'm might be
able to send some patches upstream to make the ZFS more discoverable, but I
need some more input from you.
On my machine I see that Btrfs propagates one of the devices to the /proc/
mounts, even if the
On Wed, 27 Jun 2018 at 13:44:23 +0200, Fabian Grünbichler wrote:
> On Wed, Jun 27, 2018 at 12:56:04PM +0200, Guilhem Moulin wrote:
>> On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote:
>>> cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian
>>> cryptsetup: ERROR: Couldn't
On Wed, Jun 27, 2018 at 12:56:04PM +0200, Guilhem Moulin wrote:
> Control: severity -1 wishlist
>
> Hi,
>
> On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote:
> > cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian
> > cryptsetup: ERROR: Couldn't find sysfs directory
Control: severity -1 wishlist
Hi,
On Tue, 26 Jun 2018 at 23:34:20 +0200, Fabian Grünbichler wrote:
> cryptsetup: ERROR: Couldn't normalise device rpool/ROOT/debian
> cryptsetup: ERROR: Couldn't find sysfs directory corresponding to
> rpool/ROOT/debian
I guess you had a fake line for that
Package: cryptsetup-initramfs
Version: 2:2.0.3-4
hello again!
still running the same setup with a fully encrypted single vdev used as
rpool. since the recent refactoring and split into
cryptsetup-{run,initramfs}, I now get the following messages on every
initramfs generation:
cryptsetup: ERROR:
12 matches
Mail list logo
