[TUHS] Unix install & "standalone" package

[Steffen Nurpmeso]

Hello!

Warner Losh wrote in
 <CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg at mail.gmail.com>:
 |On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |> Steffen Nurpmeso wrote in
 |>  <20230904221059.sF2G0%steffen at sdaoden.eu>:
 |>|Norman Wilson wrote in
 |>| <9A989054DE79CE5059CBA74797391E39.for-standards-violators at oclsc.org>:
 |>  ...
 |>||Perhaps the question to ask is why such a magic program is
 |>||needed at all.  Is it just because programs like the shell
 |>||have become so large and unwieldy that they won't fit in
 |>||a small environment suitable for loading into an initramfs?
 |>  ...
 |>|For my laptop it allows me easy boot management.
 ...
 |> Only to add that this is because of Linux and the way it is doing
 |> things.  If i would use FreeBSD on bare metal, then i would have
 |> an EFI boot loader on EFI that knows (only) enough to ask for
 |> passphrase (correct me if i am wrong), and can then boot the
 |> kernel from FFS or ZFS.  (You have to choose dedicated ZFS boot
 |> loader iirc, but despite that...)
 |
 |No, you don't have to choose the dedicated ZFS boot loader, at least not
 |anymore.

Ah!  It seems regarding FreeBSD i am stuck in BIOS world, then.
(zfsboot and gptzfsboot.)

 |Also, you can use boot1.efi to load loader.efi from the root filesystem to

The former deprecated i see.

 |load the kernel, or you could use loader.efi directly on the ESP to load
 |the kernel. boot1 barely knows anything (and has only one choice of
 |what to boot). loader.efi is the full deal, and can do rather a lot of
 |sophisticated things.

Great.

  ...
 |> But anyhow.  With an EFI_STUB Linux kernel i can save me all that,
 |> with busybox i get a complete environment (i then even create an
 |> initrd in /boot/ on the fly so i do not have to type the password
 |> a second time, that can (optionally) be cached, and is, actually
 ...
 |> Unfortunately cryptsetup is needed even though, i think, the
 |> kernel has anything needed; you just cannot access it.  cryptsetup
 |> is only needed for "$cs open $PART_ROOT p_root --key-file -".
 |> Of course i am no real Linux expert but only a do-it-yourself guy.

Well, and user space only, and never having read BIOS or UEFI
standards / implementations.
I have reread (almost) all of FreeBSDs documentation (loader, uefi
etc) today, and it is always great to see such good documentation!
Of course some things are beyond what a "normal" user would
understand, but at least there is documentation available.
That is really great.

 |> busybox allows me to manage this easily, to answer your question.
 |
 |You could do that on FreeBSD with a loader.efi that has a ram disk
 |built into it as well, including a 'beastie box' thing that's akin to
 |busybox.
 |It will boot in one step and no no further I/O to get a running system.
 |Others have used this for secure boot and to boot a small ram disk that's
 |later discarded as userland decides what root should be. But it's much less
 |automated than in Linux...

Hm, but wait.  Isn't it easier for FreeBSD?  I must admit i never
used FreeBSD/geli on bare metal, i started using fully encrypted
hard disks in mid 2021, no sooner.  So when i read [1] it seems
FreeBSD's boot procedure is so nicely linked with geli that the
boot loader asks itself for the password of the encrypted
partition, simply by setting some variables in loader.conf?
I mean, the /boot/ must be available?

  [1] https://man.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+13.2-RELEASE+and+Ports&arch=default&format=html

These simple scripts i use for Linux also do not support true
suspend, only suspend-to-ram.  Ie, i have no idea how i could
"suspend" the encrypted device and then "resume" it again;
The "warm" security is only (initiated via ACPI event from root
account) auto-unload of SSH and PGP keys etc, unload of encfs fuse
volumes, and then slock of all X displays etc.  Ie, all programs
which run live on the encrypted volume.  When the laptop wakes up,
X is running etc.
One would need the possibility to wake up to "a password prompt".
Well, likely it would work to mount EFI vfat before the suspend,
create a console and auto-switch to it, and then sit there, ready
for reading in the password once the system resumes.  That is to
say: i always believed in FreeBSD this works just as easy as the
boot procedure?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)