[TUHS] Unix install & "standalone" package

[Warner Losh]

On Wed, Sep 6, 2023 at 6:12 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> 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.)
>

Yes, for MBR, things are necessarily more complicated because the ZFS
boot loader is too big. The first few sectors live in the 8k space that the
traditional boot loader lives, and the rest is DD'd to a special area of
the ZFS
uberblock reserved for boot blocks. For gptboot vs gptzfsboot, they were
written to be either or and combining them presented challenges, not least
was
the partition size that gptboot lives in was created for many releases too
small
to hold gptzfsboot and making it tricky to upgrade...


>  |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?
>

Yea. I find it easier :). But there's some better automation available in
Linux for the 'complicated' situations. I was also trying to be generous
to Linux because I know the passion of its supporters in the face of
even mild criticism.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230907/ba4bb5da/attachment.htm>