From: Steffen Nurpmeso <email@example.com>
To: Warner Losh <firstname.lastname@example.org>
Subject: [TUHS] Re: Unix install & "standalone" package
Date: Thu, 07 Sep 2023 02:11:57 +0200 [thread overview]
Message-ID: <20230907001157.Qld6Bemail@example.com> (raw)
Warner Losh wrote in
|On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <firstname.lastname@example.org> 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
|> 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  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
|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)
next prev parent 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
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).