The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <>
To: Warner Losh <>
Subject: [TUHS] Re: Unix install & "standalone" package
Date: Thu, 07 Sep 2023 02:11:57 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


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

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.


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


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?

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

  reply	other threads:[~2023-09-07  0:12 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 [this message]
2023-09-07 16:05         ` Warner Losh
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).