Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Apr 2022 02:02:57 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 263407] RC3 Guided ZFS on root with encryption unmountable
Message-ID:  <bug-263407-227-V3LkV4GMZR@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-263407-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-263407-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263407

Kyle Evans <kevans@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allanjude@FreeBSD.org,
                   |                            |freqlabs@FreeBSD.org,
                   |                            |kevans@freebsd.org,
                   |                            |mav@FreeBSD.org

--- Comment #10 from Kyle Evans <kevans@freebsd.org> ---
(In reply to Martin Matuska from comment #7)

To summarize some of what I've discovered:

loader fails to read it because we process the first datablk and then still
have 8 bytes left to read.  Note the zdb output:

obj=3D14 dataset=3Dzroot/ROOT/default path=3D/boot type=3D20 bonustype=3D44
obj=3D77 dataset=3Dzroot/ROOT/default path=3D/boot/kernel type=3D20 bonusty=
pe=3D44
obj=3D16532 dataset=3Dzroot/ROOT/default path=3D/boot/kernel/geom_eli.ko ty=
pe=3D19
bonustype=3D44

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
     16532    1   128K   128K    72K     512   128K  100.00  ZFS plain file
(K=3Dinherit) (Z=3Dinherit=3Dlz4)
                                               168   bonus  System attribut=
es
        dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED=20
        dnode maxblkid: 0
        uid     0
        gid     0
        atime   Wed Apr 20 16:36:09 2022
        mtime   Thu Apr 14 05:24:57 2022
        ctime   Wed Apr 20 16:36:13 2022
        crtime  Thu Apr 14 05:24:57 2022
        gen     105
        mode    100555
        size    131080
        parent  77
        links   1
        pflags  40800000104
Indirect blocks:
               0 L0 0:12eb72000:12000 20000L/12000P F=3D1 B=3D105/105
cksum=3D16fe63abceef:30eb7f3af17191f:2407cd8cfd04b694:d5743be33ba51582

                segment [0000000000000000, 0000000000020000) size  128K

There's one indirect block that consists of 128k data, but the file size is
128k + 8 bytes. zdb doesn't indicate any embedded data, so it's not clear w=
here
this remaining 8 bytes comes from but it seems likely that we're just
mishandling this situation. When you copy the file away, you get this inste=
ad,
which loader *can* grok:

obj=3D14 dataset=3Dzroot/ROOT/default path=3D/boot type=3D20 bonustype=3D44
obj=3D115 dataset=3Dzroot/ROOT/default path=3D/boot/modules type=3D20 bonus=
type=3D44
obj=3D65597 dataset=3Dzroot/ROOT/default path=3D/boot/modules/geom_eli.ko t=
ype=3D19
bonustype=3D44

    Object  lvl   iblk   dblk  dsize  dnsize  lsize   %full  type
     65597    2   128K   128K    80K     512   256K   50.00  ZFS plain file
(K=3Dinherit) (Z=3Dinherit=3Dlz4)
                                               168   bonus  System attribut=
es
        dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED=20
        dnode maxblkid: 1
        uid     0
        gid     0
        atime   Wed Apr 20 17:37:15 2022
        mtime   Wed Apr 20 17:37:15 2022
        ctime   Wed Apr 20 17:37:15 2022
        crtime  Wed Apr 20 17:37:15 2022
        gen     887
        mode    100555
        size    131080
        parent  115
        links   1
        pflags  40800000104
Indirect blocks:
               0 L1  0:20481000:1000 20000L/1000P F=3D1 B=3D887/887
cksum=3D874e89542b:1f3270c7c16ce:39b480e80eca90d:75b552339f0fcd1b
               0  L0 0:a0143000:12000 20000L/12000P F=3D1 B=3D887/887
cksum=3D16fe63abceef:30eb7f3af17191f:2407cd8cfd04b694:d5743be33ba51582

                segment [0000000000000000, 0000000000020000) size  128K

I don't understand how everything's stored in the first scenario, but I'm
adding some more zfs people that can maybe elucidate.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263407-227-V3LkV4GMZR>