Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 May 2023 04:08:26 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 271385] Improve usability of geli + gpt
Message-ID:  <bug-271385-227@https.bugs.freebsd.org/bugzilla/>

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

            Bug ID: 271385
           Summary: Improve usability of geli + gpt
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: phryk-ports@wzff.de

Okay, hear me out =E2=80=93 this is something that has been bugging me for =
at
least a decade. GPT labels are great. Refer to your devices by constant
names, no matter what order you plugged them in. Very nice if you do
hotplugging or otherwise switch disks around a lot.

GEOM_ELI is also great. Encrypt all the things everywhere all
the time.

Combine both things and you get=E2=80=A6 a godawful mess.

Allow my to illustrate:

One of my system has 4 disks.

Each disk has 5 partitions =E2=80=93 2 unencryped (UEFI + /boot), 3 encrypt=
ed.
That's 12 geli devices. All flagged for boot and having keyfiles
associated to their respective `gpt/<label>` in `loader.conf`.

Now when I boot, geli will start asking for passphrases, starting at ada0p3=
=E2=80=A6
and fail all three tries because it doesn't have an associated key for that
device.
Then it will do the same for ada0p4 and ada0p5 before going on to the gpt
labels
for ada0, where I can finally punch in my passphrase and at least have my
devices
for ada0 attached.

Then it will go through 3 tries for each of ada0p3 through ada3p5 (so 9*3
tries)
without looking at any of the gpt labels to then do all remaining gpt label=
s at
once.

This has me uselessly bashing enter for a total of 36 tries =E2=80=93 and t=
hat's
*after*
disabling `kern.geom.label.disk_ident.enable` and
`kern.geom.label.gptid.enable`,
otherwise it'd literally be over a hundred. For *four disks*.=20

This is clearly ridiculous. All my gmirrors always start
in degraded configuration because this takes so long.

I see two ways of fixing this:

1) Adding a loader.conf option to tell geli to only try to
attach devices it actually has keyfiles associated to.

2) Add some kind of white- or blacklist option for devices.
Either a glob thing (`gpt/*`) or a list of label types.

--=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-271385-227>