The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Warner Losh <>
To: Warner Losh <>, Norman Wilson <>,
Subject: [TUHS] Re: Unix install & "standalone" package
Date: Thu, 7 Sep 2023 10:05:37 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 5531 bytes --]

On Wed, Sep 6, 2023 at 6:12 PM Steffen Nurpmeso <> wrote:

> Hello!
> Warner Losh wrote in
>  <>:
>  |On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <>
> wrote:
>  |> Steffen Nurpmeso wrote in
>  |>  <>:
>  |>|Norman Wilson wrote in
>  |>| <>:
>  |>  ...
>  |>||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
the partition size that gptboot lives in was created for many releases too
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]
> 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.


[-- Attachment #2: Type: text/html, Size: 7144 bytes --]

  reply	other threads:[~2023-09-07 16:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04 14:44 [TUHS] " Norman Wilson
2023-09-04 14:55 ` [TUHS] " Vincenzo Nicosia
2023-09-04 17:20   ` Warner Losh
2023-09-04 19:05     ` Clem Cole
2023-09-05 17:03       ` Paul Winalski
2023-09-05 18:02         ` Clem Cole
2023-09-04 19:59     ` Theodore Ts'o
2023-09-04 23:51       ` Warner Losh
2023-09-04 17:18 ` Warner Losh
2023-09-04 22:10 ` Steffen Nurpmeso
2023-09-05 15:53   ` Steffen Nurpmeso
2023-09-06 17:50     ` Warner Losh
2023-09-07  0:11       ` Steffen Nurpmeso
2023-09-07 16:05         ` Warner Losh [this message]
2023-09-08 14:58           ` Theodore Ts'o
2023-09-08 13:56     ` Michael Kjörling
2023-09-08 23:38       ` Steffen Nurpmeso
2023-09-09 22:43         ` Steffen Nurpmeso
2023-09-11  4:10         ` Theodore Ts'o
2023-09-11 22:05           ` Steffen Nurpmeso
2023-09-05  1:07 ` Jonathan Gray
  -- strict thread matches above, loose matches on Subject: below --
2023-09-04  9:57 [TUHS] " Paul Ruizendaal via TUHS
2023-09-04 14:53 ` [TUHS] " emanuel stiebler
2023-09-04 17:07 ` Warner Losh
2023-09-04 18:21   ` Dan Cross
2023-09-05 11:15   ` Paul Ruizendaal via TUHS
2023-09-05 14:15     ` Clem Cole
2023-09-05 17:03     ` Warner Losh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).