4 Sep
2023
4 Sep
'23
8:44 p.m.
I don't remember any special many-programs-in-one binary
like busybox in any Unix from the days when Unix was simple
enough for me to understand. That covers the entire lifetime
of the Research systems, but also System V and the BSDs and
their sundry offspring up into at least the 1990s.
I'm pretty sure OpenBSD at least still has nothing like
busybox. The nearest thing was to make sure certain programs
were linked statically (or existed in alternate statically-
linked versions) so they would work before shared libraries
were available. (It seems to be common wisdom that `sbin'
means `system bin' these days, but I remember once, long ago,
being told it stood for `static bin'.)
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?
Older UNIXes, even on the VAX, didn't use an initramfs.
the boot code had just enough understanding of devices and
file systems to load the kernel and to point it at the
real root file system. The VAX hardware designers had
a clever scheme on many (but, strangely, not all) VAX
variants by which the hardware had several little boot
ROMs, each containing a bare-bones read-only device
driver for a particular device along with a few
instructions to read the first sector into memory
and start it, with pointers to the boot-rom driver
and device ID in specified registers. That was enough
to support a device-independent Unix boot block that
could read unix (or another file name typed on the
console) from the root of the file system at the start
of the disk. I know it was because I wrote such a
boot block, though I don't know whether anyone else
did. (Other systems, I think, just used it to load
/boot, a larger and more-capable program.)
Maybe it was just that the boot environment was simpler
in older systems, without the need to load kernel modules
or support multiple locations and means of access for
the root?
Norman Wilson
Toronto ON
4 Sep
4 Sep
8:55 p.m.
rather, back then you didn't need the same kernel to run on a wide
variety of hardware, with all the possible different combinations of
peripherals, requiring all sorts of different drivers.
I think that's the only real reason why initramfs came to existence:
allowing a selection of kernel modules to be loaded at init time,
depending on the hardware at disposal on that machine. Then things went
south, and more recent initramfs have everything and the kitchen sink.
But that's another story.
HND
Enzo Nicosia
--
11:20 p.m.
On Mon, Sep 4, 2023 at 8:56 AM Vincenzo Nicosia <katolaz(a)freaknet.org>
wrote:
rather, back then you didn't need the same kernel
to run on a wide
variety of hardware, with all the possible different combinations of
peripherals, requiring all sorts of different drivers.
I think that's the only real reason why initramfs came to existence:
allowing a selection of kernel modules to be loaded at init time,
depending on the hardware at disposal on that machine. Then things went
south, and more recent initramfs have everything and the kitchen sink.
But that's another story.
Yea, it was an effort to move mounting of root out of the kernel. The
earliest
scripts just mounted the right disk and moved on, and didn't load any new
drivers: they just had the logic to pick the desired root. But at the same
time,
there were a lot of people that were running on 4MB and 8MB systems that
noticed they could put all the router software in the initramfs and never
pivot
to something else and they could have quite the product with that. And those
were the first few bricks that paved the road to hell :)
Warner
5 Sep
5 Sep
1:05 a.m.
I can not add too much to what happened later, but I think modern users
don't get it why the things like the standalone system were needed back in
the day. There were a few simple differences thanks to Moore's law, modern
folks really may not grok:
1. The number of peripherals that needed to be supported was small [each
firm made only a few for each target system]
2. The capacity/capabilities of those peripherals are minimal compared
to today's world
3. Cheap ROMs, as we know it, were coming on the scene [the EPROM is
only invented in 1971] One-time programmable and Mask ROMs were around but
they were expensive and small.
I hope Warren's emailer lets this pass through.
Here is a picture of the original root 'ROM' for the PDP-11 M792-xx board,
which gives you 32 words (64 bytes) of memory. It used individual diodes
in or out arranged an array to represent individual bits with a diode
present being a '1' and '0' if missing. As the Gunkies web page
suggests,
the board came in two versions - customer programmable which was fully
populated with diodes, and the user removed unneeded diodes to program it.
The other variants were programmed with the designed boot functions -
designated M792-Yx (where 'x' is a capital letter, starting with 'A')
[image: Read_Only_Memory_DEC_M792_Diode_Matrix_ROM_Aceware_Attribution.jpg]
Also, remember that a $3-5k/drive RK05 is only 2.5Mbytes [4872 512 byte
'sectors' *a.k.a*. disk blocks -- 2 hd/disk * 15 sec/cyl * 203 cyl/disk],
which is why we had separated /bin and /usr/bin and /lib and /usr/lib.
Plus, as Norman points our dynamic linking only comes later, so all of
these are static bound programs (*i.e.,* Sun create /bin and /sbin to
separate those programs). The whole idea was what was in root was enough
to get the system running in /bin, /lib and /etc and everything else was
one the mounted file system, which often was another RK05. Many of our V6
and V7 systems ran with 3 RK05 /, /usr /home, and we might have an extra
RK05 for /mnt. Tape was the standard thing. DEC tape was cheaper than
9-track, although in my history, we all went for 9-track because it was
more portable to other systems, but often used after-market 9-track
transports that emulated the DEC ones.
Even with the VAX, the front-end runs on an LSI-11 with floppies, so things
like microcode were loaded into the VAX and stored in ROM. By then, the
RP and RM series had become more normal, and eventually, the RK07 and RL02
replaced the RK05. But we are not talking about substantial capacity in
the storage systems. Only ten years later, in the early 1980s, a
Fujisu 'Eagle' is just 470Mbytes and costs 12-15K per drive, plus another
$6-8K for the controller for your Vax [also often after-market from SI or
Emulex].
Sun and Apollo build 'diskless' systems because a 100MB ST-506 style disk
was considered too expensive, and was worried about the entry-level price
of their systems (I famously made a typo describing how those systems
performed BTW with a dyslexic change of the s to c on a whole company email
at Masscomp in the mid-1980s - to Sun's credit, it was the best marketing
ploy ever - people bought diskless and discovered they sucked and then all
added a disk - which cost more $s than the original Masscomp system which
was had one built-in). But I digress...
Those new workstations did have real ROM chips, unlike the original
PDP-11s, but they were small, maybe 8Kbytes of NS2764, so the ROMs were
tight and only had enough in them to recognize a couple of peripherals.
So to answer more of your question, you build the tools you need that make
sense at the time. /stand was a simple solution and was small. For V7
and the original BSD 3 and 4 released, the user needed to read a
distribution media, traditionally a 9-track tape, and set up a local disk.
The number of peripherals was small.
One other thought ... in the case of the PDP-11 and Vaxen, the disks were
often dismountable, like the different RK, RL, RP, and RM series drives.
We often had more than one system. So once the system was up and running,
it was not usual to use a different system with better tools to help repair
things if bad stuff occurred. That is also why we often used 9-track tape,
just because that was even easier to move back and forth. With the
Wokstrations, the disks were generally sealed.
Clem
A small PS on another note -- I have memories of taking an ST-506 disk
with me to France to work with some engineers in Grenoble and explaining to
the French authorities that they could not open it up to look inside.
BTW: this pre-internet - imagine what we had to do if we flew to Canada,
which was taxing SW. Even bringing tapes in and out of Toronto airport
could be treacherous.
ᐧ
11:03 p.m.
On 9/4/23, Clem Cole <clemc(a)ccc.com> wrote:
Even with the VAX, the front-end runs on an LSI-11 with floppies, so things
like microcode were loaded into the VAX and stored in ROM.
I think you meant either "stored in RAM" or "not stored in ROM". The
LSI-11 front end for the VAX-11/780 (and other early VAXen?) was
connected to the SBI (Synchronous Backplane Interconnect--the system
bus) and performed three main functions: microcode load and system
bootstrap initiation, interface for the system console (originally a
LA-36 dot matrix terminal), and some system diagnostics. CPU
microcode was stored on a 5" floppy disk connected to the LSI-11 and
was loaded into RAM at system power-up.
-Paul W.
6 Sep
6 Sep
12:02 a.m.
On Tue, Sep 5, 2023 at 1:03 PM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On 9/4/23, Clem Cole <clemc(a)ccc.com> wrote:
Yep -- thanks - dyslexia-r-me.
ᐧ
Even with the VAX, the front-end runs on an LSI-11 with floppies, so
things
like microcode were loaded into the VAX and
stored in ROM.
I think you meant either "stored in RAM" or "not stored in ROM".
5 Sep
5 Sep
1:59 a.m.
On Mon, Sep 04, 2023 at 11:20:31AM -0600, Warner Losh wrote:
Yea, it was an effort to move mounting of root out of the
kernel. The earliest scripts just mounted the right disk and moved
on, and didn't load any new drivers: they just had the logic to pick
the desired root. But at the same time, there were a lot of people
that were running on 4MB and 8MB systems that noticed they could put
all the router software in the initramfs and never pivot to
something else and they could have quite the product with that. And
those were the first few bricks that paved the road to hell :)
The other reason why you might need something like an initial ramdisk
is if you don't yet *have* a root file system on the hardware, and you
are trying to install a system using TFTP boot. At that point, you
have three choices:
(a) Use a NFS root
(b) Use a read-only network block device (for example, MIT Project
Athena had a read-only Remote Virtual Disk which was a network block
device that was used to provide a read-only system image used for
installation and update, as well as a read-only /usr image).
(c) Use a built-in ramdisk. (And here's not just Linus which has
adopted this strategy; OpenBSD's installer does this as well.)
The other dynamic at play was that ramdisks were needed when you were
installing on a 386 PC with, say, 16 megs of memory, a 320 megabyte
hard disk, and a *single* 1.44MB floppy --- and no ethernet, because
this was for the home PC user, so the best that you had might be a
38kbps dialup link with PPP --- if you were lucky.
So putting the kernel on the first floppy disk, and putting a ramdisk
image on the second floppy disk, so you could then eject the floppy
disk and insert subsequent floppy disks so you could install rest of
the installation binaries (including the shell utilities, the C
compiler, X windows systems, etc.) and then reboot onto the HDD with a
fully set up system, was a pretty natural evolution.
And since we had the ramdisk infrastructure, and most users didn't
want to configure their own kernel as part of the installation
process, that begat kernel modules and the initial ramdisk being used
to store the kernel modules. In the very early days, this made Linux
*far* more user friendly for non-system programmers to install,
compared to say, FreeBSD during that era, which was still stuck in the
BSD 4.x days of a generic kernel, followed by a kernel configuration
step, etc.
These days, given that some enterprise setups what their servers to be
installed from a Fibre Channel Storage Area Network, or iSCSI, perhaps
using Kerberos to authenticate to the iSCSI target, it makes
absolutely a huge amount of sense to have an initial ramdisk as an
option. That being said, for a long time, the initial ramdisk was an
*option*. You didn't have to use it, if you were willing to have a
custom kernel and you are using a device which has a fixed and stable
boot-time enumeration.
This tended to only be used by people who knew what they were doing,
but for example, my file system test appliance VM system doesn't use
an initial ramdisk at all. It uses qemu, and has a built-in kernel
configuration and build system, and this works perfectly fine booting
into the latest Debian stable distribution, with no initial ramdisk
used at all:
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickst…
- Ted
the root filesystem on the second floppy disk (the first
floppy disk contained the kernel), which was then copied into a
ramdisk, so you could
Trying to fit the kernel and the root file system on a single 1.44MB
floppy, was (barely) doable, but you certainly wouldn't have space for
a C compiler so you build or link your own custom kernel. So one of
the first things that we did was to put the kernel on a single floppy
disk, and then but the root on a single floppy disk, and then copy the
root to the HDD, and then reboot onto the HDD, and then take the
installation procedure from there. But that was awkward and
5:51 a.m.
On Mon, Sep 4, 2023 at 1:59 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Mon, Sep 04, 2023 at 11:20:31AM -0600, Warner Losh
wrote:
Yes. FreeBSD did this originally, and some installers still do that.
Yea, it was an effort to move mounting of root out of the
kernel. The earliest scripts just mounted the right disk and moved
on, and didn't load any new drivers: they just had the logic to pick
the desired root. But at the same time, there were a lot of people
that were running on 4MB and 8MB systems that noticed they could put
all the router software in the initramfs and never pivot to
something else and they could have quite the product with that. And
those were the first few bricks that paved the road to hell :)
The other reason why you might need something like an initial ramdisk
is if you don't yet *have* a root file system on the hardware, and you
are trying to install a system using TFTP boot. At that point, you
have three choices:
(a) Use a NFS root
(b) Use a read-only network block device (for example, MIT Project
Athena had a read-only Remote Virtual Disk which was a network block
device that was used to provide a read-only system image used for
installation and update, as well as a read-only /usr image).
(c) Use a built-in ramdisk. (And here's not just Linus which has
adopted this strategy; OpenBSD's installer does this as well.)
The other dynamic at play was that ramdisks were
needed when you were
installing on a 386 PC with, say, 16 megs of memory, a 320 megabyte
hard disk, and a *single* 1.44MB floppy --- and no ethernet, because
this was for the home PC user, so the best that you had might be a
38kbps dialup link with PPP --- if you were lucky.
So putting the kernel on the first floppy disk, and putting a ramdisk
image on the second floppy disk, so you could then eject the floppy
disk and insert subsequent floppy disks so you could install rest of
the installation binaries (including the shell utilities, the C
compiler, X windows systems, etc.) and then reboot onto the HDD with a
fully set up system, was a pretty natural evolution.
Yes. FreeBSD 2.0 definitely did that, and I think FreeBSD 1.0 as well.
And since we had the ramdisk infrastructure, and most
users didn't
want to configure their own kernel as part of the installation
process, that begat kernel modules and the initial ramdisk being used
to store the kernel modules. In the very early days, this made Linux
*far* more user friendly for non-system programmers to install,
compared to say, FreeBSD during that era, which was still stuck in the
BSD 4.x days of a generic kernel, followed by a kernel configuration
step, etc.
GENERIC worked fine in the early days: it was small enough that the savings
from removing all the extra devices was small... but that's because the
number
of devices supported was also relatively small. By the time it became an
issue
FreeBSD did have dynamic loading of drivers, but retained the GENERIC
kernel for install (it should have gone to a minimal kernel, but hasn't yet
completed the migration: the savings wasn't big enough due to Moore's
Law growing machine memories faster than the kernel grew: FreeBSD's kernel
only doubled every 2 years...).
But yea, it was a bit of a kludge. And FreeBSD grew the ability to configure
the morass of ISA devices in the boot loader early on so you could at least
boot the generic kernel, and have the loader remember your choices.
These days, given that some enterprise setups what
their servers to be
installed from a Fibre Channel Storage Area Network, or iSCSI, perhaps
using Kerberos to authenticate to the iSCSI target, it makes
absolutely a huge amount of sense to have an initial ramdisk as an
option. That being said, for a long time, the initial ramdisk was an
*option*. You didn't have to use it, if you were willing to have a
custom kernel and you are using a device which has a fixed and stable
boot-time enumeration.
Yea. FreeBSD can use it to this day (and many interesting use cases
use it), but generally the loader tells the kernel what root filesystem to
use. These smarts in the boot loader have also kept the pressure of the
vast majority of cases where initramfs makes sense in Linux land.
This tended to only be used by people who knew what
they were doing,
but for example, my file system test appliance VM system doesn't use
an initial ramdisk at all. It uses qemu, and has a built-in kernel
configuration and build system, and this works perfectly fine booting
into the latest Debian stable distribution, with no initial ramdisk
used at all:
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickst…
Ah, cool. Every single distro I've run in the past has had an initramfs. I
thought
it had become no longer an option...
I do similar things for my VM setup with FreeBSD :)
Warner
4 Sep
4 Sep
11:18 p.m.
On Mon, Sep 4, 2023 at 8:44 AM Norman Wilson <norman(a)oclsc.org> wrote:
Maybe it was just that the boot environment was
simpler
in older systems, without the need to load kernel modules
or support multiple locations and means of access for
the root?
Older systems had fewer choices. On the PDP-11 you had Q-Bus or Unibus.
You booted off a small selection of disks that converged to MSCP(?), so
there was THE boot environment and THE driver and THE filesystem. And
the kernels were often tuned to be exactly what the machine needed.
The VAX, Sun, hp, ibm, etc continued this early trend. Though the boot
process
was still fairly narrow, with a limited list of supported boot devices.
In large part this was because the machine was exactly the same every
time you booted.
But with USB, PC Card, CardBus, ExpressCard, SCSI, Thunderbolt,
and a host of other removable technologies with a dizzying array of
cards, like PCI, ISA, etc, the game changed.
Also, the number of environments that a FreeBSD GENERIC[*] kernel
can boot in is huge due to combinatoric explosion due to three or
four boot environments, vm alternate startup paths, several supported
root file system, BIOS, UEFI, OpenFirmware, u-boot, coreboot, etc
as well as several thousand supported boot controller devices, things
got complex, despite there being several common interfaces that made
things simpler. I'm running a summer of code project this year to help
tame the combinatoric explosion to provide better test coverage because
though attempts were made to make things the same, variations exist that
can cause unexpected breakage in different environments.
Warner
[*] I use GENERIC here as a catch all, including the more recent MINIMAL
kernels that try to include just the core functionality, and omit the vast
majority of drivers. Linux has similar issues, but more, and also solves
them in many interesting ways... But I'm the FreeBSD boot loader guy
in large part (though there's others that work on it), not a Linux person.
5 Sep
5 Sep
4:10 a.m.
Norman Wilson wrote in
<9A989054DE79CE5059CBA74797391E39.for-standards-violators(a)oclsc.org>rg>:
|I don't remember any special many-programs-in-one binary
|like busybox in any Unix from the days when Unix was simple
|enough for me to understand. That covers the entire lifetime
|of the Research systems, but also System V and the BSDs and
|their sundry offspring up into at least the 1990s.
...
|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?
AlpineLinux as used on my vserver has busybox by default and can
cover most utitilities like that. The lead developer Copa once
said something like "The idea is you install explicitly [if you
want something better]". (It is a symlink farm that is
selectively replaced by installing "real" packages iirc.)
For my laptop it allows me easy boot management.
To save you the chatter ("Chatten" is the name of my tribe .. most
likely; could be Franken, Sueben .. and you know how it is): this
approach is much easier and smaller than having lots of static
binaries to copy around etc.
I do not use secure boot, i have on EFI only a kernel, busybox and
cryptsetup, and scripts (the laptop is named "kent")::
...
drwxr-xr-x 4 root root 4096 Jul 15 2021 EFI/
...
-rwxr-xr-x 1 root root 272 Feb 1 2022 kent.sh*
-rwxr-xr-x 1 root root 313 Feb 1 2022 kent-direct.sh*
drwxr-xr-x 1 root root 252 Oct 9 2022 ../
-rwxr-xr-x 1 root root 4596 Feb 4 2023 linux-init-s1.sh*
-rwxr-xr-x 1 root root 3646 Feb 4 2023 linux-init-lib.sh*
-rwxr-xr-x 1 root root 5480120 Feb 11 2023 cryptsetup.static*
-rwxr-xr-x 1 root root 1978368 Aug 15 18:51 busybox.static*
-rwxr-xr-x 1 root root 10112672 Aug 26 18:44 ideapad-stage1.efi*
So kent.sh can be init(8) for the ideapad-stage1.efi Linux kernel
started via EFI as setup via efibootmgr(8)
Boot0001* kent
HD(1,GPT,5d6d756b-5de2-4e5d-b043-8d4ae1bb6eb0,0x800,0x82000)/File(\ideapad-stage1.efi)root=/dev/nvme0n1p1
rootfstype=vfat init=/kent.sh
#!/busybox.static sh
#@ kent, step 1., via EFI.
PART_ROOT=/dev/nvme0n1p8
ROOT_DECRYPT='-t btrfs -o defaults,subvol=/crux/kent/root'
PART_ROOT1=/dev/nvme0n1p8
ROOT_DECRYPT1='-t btrfs -o defaults,subvol=/crux/kent/root.old'
INIT_S2=/boot/kent-2.sh
. /linux-init-s1.sh
and that allows me to unlock the harddisk.
We then boot via $INIT_S2 and kexec(8) a kernel from the encrypted
harddisk, so no code from EFI partition keeps on running. (We
byte-compare the data from EFI with equal /boot/ files after
booting the real system.)
This allows nice and easy properties: only three files to track
(cryptsetup, busybox, kernel), almost same set of files in /boot/
and /media/efi aka EFI. And ideapad-stage1.efi is the same kernel
that later runs, but later we have also additional dynamic modules
available. Ie, every few weeks i copy /boot/ideapad-6_1.efi over
to be the new -stage1.efi.
--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)
9:53 p.m.
Steffen Nurpmeso wrote in
<20230904221059.sF2G0%steffen(a)sdaoden.eu>eu>:
|Norman Wilson wrote in
| <9A989054DE79CE5059CBA74797391E39.for-standards-violators(a)oclsc.org>rg>:
...
||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.
...
| -rwxr-xr-x 1 root root 4596 Feb 4 2023 linux-init-s1.sh*
| -rwxr-xr-x 1 root root 3646 Feb 4 2023 linux-init-lib.sh*
| -rwxr-xr-x 1 root root 5480120 Feb 11 2023 cryptsetup.static*
| -rwxr-xr-x 1 root root 1978368 Aug 15 18:51 busybox.static*
| -rwxr-xr-x 1 root root 10112672 Aug 26 18:44 ideapad-stage1.efi*
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...)
I know GRUB (and maybe other) Linux bootloaders can do all that,
but they are huge, are badly maintained, or under-documented, let
alone with local manuals, and i am too stupid to configure them
(due to all that). refind is ok, however. But.. be aware of
typos in the configuration..
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
-rw------- 1 root root 4495987 May 29 16:29 .kent.initrd.0
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.
busybox allows me to manage this easily, to answer your question.
--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)
6 Sep
6 Sep
11:50 p.m.
On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
Steffen Nurpmeso wrote in
<20230904221059.sF2G0%steffen(a)sdaoden.eu>eu>:
|Norman Wilson wrote in
| <9A989054DE79CE5059CBA74797391E39.for-standards-violators(a)oclsc.org>rg>:
...
||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.
...
| -rwxr-xr-x 1 root root 4596 Feb 4 2023 linux-init-s1.sh*
| -rwxr-xr-x 1 root root 3646 Feb 4 2023 linux-init-lib.sh*
| -rwxr-xr-x 1 root root 5480120 Feb 11 2023 cryptsetup.static*
| -rwxr-xr-x 1 root root 1978368 Aug 15 18:51 busybox.static*
| -rwxr-xr-x 1 root root 10112672 Aug 26 18:44 ideapad-stage1.efi*
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.
Also, you can use boot1.efi to load loader.efi from the root filesystem to
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.
I know GRUB (and maybe other) Linux bootloaders can do
all that,
but they are huge, are badly maintained, or under-documented, let
alone with local manuals, and i am too stupid to configure them
(due to all that). refind is ok, however. But.. be aware of
typos in the configuration..
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
-rw------- 1 root root 4495987 May 29 16:29 .kent.initrd.0
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.
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...
Warner
7 Sep
7 Sep
6:11 a.m.
Hello!
Warner Losh wrote in
<CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg(a)mail.gmail.com>om>:
|On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
|> Steffen Nurpmeso wrote in
|> <20230904221059.sF2G0%steffen(a)sdaoden.eu>eu>:
|>|Norman Wilson wrote in
|>| <9A989054DE79CE5059CBA74797391E39.for-standards-violators(a)oclsc.org>rg>:
|> ...
|>||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&…
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)
10:05 p.m.
On Wed, Sep 6, 2023 at 6:12 PM Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote:
Hello!
Warner Losh wrote in
<CANCZdfoy0UJyFdvJ_fO4FDks_dfEOhsJo+7p2RORdk6gQWf7qg(a)mail.gmail.com>om>:
|On Tue, Sep 5, 2023 at 9:53 AM Steffen Nurpmeso <steffen(a)sdaoden.eu>
wrote:
|> Steffen Nurpmeso wrote in
|> <20230904221059.sF2G0%steffen(a)sdaoden.eu>eu>:
|>|Norman Wilson wrote in
|>| <9A989054DE79CE5059CBA74797391E39.for-standards-violators(a)oclsc.org>rg>:
|> ...
|>||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&…
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
8 Sep
8 Sep
8:58 p.m.
On Thu, Sep 07, 2023 at 10:05:37AM -0600, Warner Losh wrote:
Yea. I find it easier :). But there's some better automation available in
Linux for the 'complicated' situations.
Yeah, this is why most of the Linux distributions always use an
initramfs, at least by default, because it handles all (or at least
most) of these complicated sitautions automatically. So this leads to
people assuming that Linux "requires" using a initramfs, when it would
be more accurate to say that most Linux distributions makes it super
easy to use an initramfs, and much more difficult (because the
documentation is a bit scattered, and many may be somewhat out of
date) to do things without an Linux distribution-engineered initramfs.
And the other clear difference between Linux and FreeBSD is that
things like initramfs tends to be distribution-specific, so there is
competition between distributions to see who can make a simpler/easier
installer and boot sequnce, and so market forces tends to strongly
encourage developers (who after all, tend to be experts and who don't
need the installer and boot up automation), to improve things much
more aggressively. (And since there are product managers involved,
often features and time to market often trump issues like technical
debt.)
The downside with this approach, though, is that distributions tend to
reinvent the wheel multiple times, and the initramfs infrastructures
are different. So learning how things work in say, Debian, isn't
going to help you understand the fine details of how Fedora or Red Hat
Enterprise Linux works except at a very basic, high level. And the
same is most definitely true if you compare the installers between
Debian, Ubuntu, Fedora, etc.
FreeBSD has the advantage that it has a much more centralized
development model, especially as it relates to kernel/libc
integration, the installer, and the boot loader path. But while there
is a certain amount of competitive forces of FreeBSD, NetBSD, OpenBSD,
et. al., improving and simplifying the boot loader, from an outsider
looking in, it would appear that those forces aren't quite as strong,
and the level of convergence beween the *BSD seems to be at least as
strong, if not stronger, in some areas, than between Linux
distributions.
Cheers,
- Ted
7:56 p.m.
On 5 Sep 2023 17:53 +0200, from steffen(a)sdaoden.eu (Steffen Nurpmeso):
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.
If your need is restricted to a highly specific use case and you are
trying to keep it as small as possible, then it should be possible to
write a custom wrapper around whatever libcryptsetup functionality you
need and avoid the extra code that you get with cryptsetup proper.
--
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
9 Sep
9 Sep
5:38 a.m.
Michael Kjörling wrote in
<f948d06c-14f4-40bd-8e32-4db1c5b1dd21(a)home.arpa>pa>:
|On 5 Sep 2023 17:53 +0200, from steffen(a)sdaoden.eu (Steffen Nurpmeso):
|> 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.
|
|If your need is restricted to a highly specific use case and you are
|trying to keep it as small as possible, then it should be possible to
|write a custom wrapper around whatever libcryptsetup functionality you
|need and avoid the extra code that you get with cryptsetup proper.
It is nicely documented, and my Linux distribution ships the
static library anyhow. But i am a lazy sort regarding such,
i just take the thing of my distribution and copy it over (they do
build it statically also by default).
You know, things change, and if you do not follow closely, you
stand in the rain. I am not a paid Linux engineer that follows
this rapidly moving target in the end.
For example the (no longer) new random developer chose to disable
feeding entropy via /dev/urandom, here (distribution) still is
# Load random seed
/bin/cat /var/lib/urandom/seed > /dev/urandom
for almost two decades (it is a rather young one), but the code
path was mutilated (i read the kernel source once he had rewritten
that to be blake2/some 32-byte block thing based), now one needs
to use some ioctl interface fwiw.
Or once here cryptsetup was updated to use OpenSSL 3.0 suddenly
ripemd160 was no longer available on EFI (aka purely static,
without the filesystem avaialable), even though its release notes
explicitly mentioned the problem as solved, and OpenSSL 3's
libcrypto.a _had_ ripemd160... I had to switch to sha512 .. then
to sha256 once cryptsetup started warning args had to be explicit
in the future. Mind you, i in fact use it twice, also for
encrypted swap, i only wrongly searched for $cs
$2 open --type plain --cipher aes --key-size 256 \
--hash sha256 $PART_SWAP p_swap --key-file - &&
i said on IRC
cryptsetup does EVP_DigestInit_ex(h->md, h->hash_id, NULL),
i presume that does load additional things.
That surely is it, i did not track it further.
So no, to answer you, i have no highly specific use case at all.
This is only an encrypted volume with my own boot-style that
requires no boot loader but Linux itself.
Maybe i should really look deeply in how cryptsetup then attaches
a LUKS2 volume to the kernel, maybe it actually _would_ be
possible to do this simply in some other way.
But truly writing a program? I feel much saver in the horde, with
so many people, specialists even, working on Linux, LUKS2,
cryptsetup, OpenSSL, .. these are all moving targets.
(I mean, i am lucky if i _can_ do a bit of programming on at least
the MUA i maintain; so much to do! And roff hopefully somewhere
on the horizon, somewhen; today it was zero minutes.)
--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)
10 Sep
10 Sep
4:43 a.m.
Steffen Nurpmeso wrote in
<20230908233854.Xni_j%steffen(a)sdaoden.eu>eu>:
|Michael Kjörling wrote in
| <f948d06c-14f4-40bd-8e32-4db1c5b1dd21(a)home.arpa>pa>:
||On 5 Sep 2023 17:53 +0200, from steffen(a)sdaoden.eu (Steffen Nurpmeso):
...
||> Of course i am no real Linux expert but only a do-it-yourself guy.
||
||If your need is restricted to a highly specific use case and you are
||trying to keep it as small as possible, then it should be possible to
...
Actually maybe someone may find it funny, even though it is
neither historic nor very sophisticated. Let me post it.
In the end it takes some time to get there.
I would expect almost all of you will not be interested in the
lengthy rest of this mail.
Ciao, and a nice Sunday i wish from Germany!
All you need are statically linked busybox (and cryptsetup with
encryption), and a kernel with EFI_STUB on the EFI partition, so
it can be booted directly. The distribution kernels i have
(ArchLinux, AlpineLinux) have it enabled; if your EFI is large
enough you could simply copy it and all its masses of modules to
EFI.
Otherwise the kernel needs all the firmware and modules to boot
and to access all filesystems where the real stuff is. My own
kernel has a lot of things statically built-in, but it can load
more via modules (stage2 uses "the same" kernel later, and does).
Kernels on stage2 need kexec, i have
CONFIG_KEXEC=y
CONFIG_KEXEC_FILE=y
CONFIG_ARCH_HAS_KEXEC_PURGATORY=y
# CONFIG_KEXEC_SIG is not set
CONFIG_KEXEC_CORE=y
-s1.sh and -s2.sh are docu-commented at the top; they can also be
used to create the necessary environment. If i recall correctly
cd /boot
sh linit-init-s2.sh PATH-TO-BUSYBOX PATH-TO-CRYPTSETUP
mount EFI-PARTITION
cd EFI-PARTITION
sh linit-init-s1.sh PATH-TO-BUSYBOX PATH-TO-CRYPTSETUP
This only creates files and directories etc, and beat me if it
does any harm otherwise.
I use a specific naming scheme, the script reacts in particular
on -old and -new to select sensible defaults.
#?0|kent:/boot# ll ideapad*.efi
-rwxr-xr-x 1 root root 10112672 Aug 26 18:44 ideapad-stage1.efi*
-rw-r--r-- 1 root root 10120512 Sep 2 19:52 ideapad-6_1.efi
-rw-r--r-- 1 root root 10120512 Sep 9 18:18 ideapad-6_1-old.efi
-rw-r--r-- 1 root root 10121376 Sep 9 18:18 ideapad-6_1-new.efi
That very kernel (series) is in fact shared in between several
computers of a similar series, kent is the one i write this on:
#?1|kent:/boot# v kent.sh
#!/busybox.static sh
#@ kent, step 1., via EFI.
PART_ROOT=/dev/nvme0n1p?
ROOT_DECRYPT='-t btrfs -o defaults,subvol=/crux/kent/root'
PART_ROOT1=/dev/nvme0n1p8
ROOT_DECRYPT1='-t btrfs -o defaults,subvol=/crux/kent/root.old'
INIT_S2=/boot/kent-2.sh
. /linux-init-s1.sh
#?0|kent:/boot# v kent-2.sh
#@ kent, stage 2
KERNEL_ID=ideapad
^ restrict kernel selection for kexec:
^ [ "${k##*$KERNEL_ID-*.efi}" != "$k" ] || continue
PART_SWAP=/dev/nvme0n1p6
SWAP_INPUT=y
^ you can have additional interactive random for swap encryption
^ (it is a lie i use that in practice)
INITRD_PATH=/boot/.kent.initrd
KEXEC_ARGS="--append=\"rtw88_pci.disable_aspm=1 rc.hostname=kent\""
FILE_CHECK='kent-direct.sh kent.sh ideapad-stage1.efi'
SWITCH_ROOT=media/initrd
Stage 2 config file is sourced automatically, so no need to source
linux-init-s2.sh yourself (stage 2 uses switch_root).
I also have a direct boot, but have not used it for long:
#?0|kent:~# v /boot/kent-direct.sh
#!/busybox.static sh
#@ kent-direct, sole step 1., via EFI.
PART_ROOT=/dev/nvme0n1p8
ROOT_DECRYPT='-t btrfs -o defaults,subvol=/crux/kent/root'
PART_ROOT1=/dev/nvme0n1p8
ROOT_DECRYPT1='-t btrfs -o defaults,subvol=/crux/kent/root.old'
PART_SWAP=/dev/nvme0n1p6
PIVOT_OLDROOT=media/initrd
. /linux-init-s1.sh
This does not use kexec, but only pivot_root's to the decrypted
filesystem, starting sbin/init there. The kernel from EFI
continues to run.
It is pretty cool how i now can drive several computers easily
simply by creating a shell script with some variable assignments.
In fact the filesystem is shared in between multiple computers
(with only selective partitions being truly unique, but still
backed up everywhere), and all those text configs are in /boot.
Only the VFAT EFI partition is truly system-specific (ie, in that
it only holds the stage1 config file for $HOSTNAME).
I like that very much, and hope Linux continues to be so flexible.
(Not that one day you need systemd-early to get into Linux to get
to systemd-later, or something.)
The EFI boot is driven via efibootmgr(8) and has config like
#@ /root/hosts/self/efiboot
d=/dev/nvme0n1p1
maxno=1
b1=0x01 L1=kent l1=ideapad-stage1
u1='root='${d}' rootfstype=vfat init=/kent.sh'
driven by /root/bin/efiboot.sh (shortened):
#!/bin/sh
: ${HOSTNAME:=$(uname -n)}
: ${DBG:=}
if [ -f /root/hosts/${HOSTNAME}/efiboot ]; then
. /root/hosts/${HOSTNAME}/efiboot
else
echo >&2 "MISS /root/hosts/${HOSTNAME}/efiboot"
exit 1
fi
if [ "$1" = create ]; then
obo=$(efibootmgr | grep -E ^BootOrder: | sed -E
's/^BootOrder:[[:space:]]*//')
if [ -z "$obo" ]; then
echo >&2 'Cannot determine previous boot order'
exit 1
fi
nbo= i=1
while [ $i -le $maxno ]; do
eval ${DBG} efibootmgr -c -b \$b$i -L \\\"\$L$i\\\" -d \$d$i
-l \\\"\$l$i.efi\\\" -u \\\"\$u$i\\\" #>/dev/null
[ -n "$nbo" ] && nbo=$nbo,
eval nbo=\$nbo\$b$i
i=$((i + 1))
done
${DBG} efibootmgr -o $nbo,$obo #> /dev/null
elif [ "$1" = delete ]; then
i=1
while [ $i -le $maxno ]; do
eval ${DBG} efibootmgr -B -b \$b$i #>/dev/null
i=$((i + 1))
done
else
echo >&2 'Synsopsis: efiboot.sh create|delete'
exit 1
fi
${DBG} efibootmgr -v -u
This is of course git managed, so i can distribute it easily.
(Further even, the entire ideapad series configurations differ in
only 193 lines, and most of those are the different SSH keys.
The rest are different device names, ie network, display, volume
etc, disk partitions, host names.)
I am pretty lucky i found a way to manage my systems like this.
I have several git branches in root.git, linux.kconfig, bin,
iwd.network, and one for each computer. I can then "git merge"
selectively together what is necessary. For example my web
vserver only needs bin and its own configuration, whereas the
laptops also need iwd.network. Etc etc. Like this every computer
only knows the selective minimum. The full git repo is on an
encrypted volume stored away.
And it is not Puppet or Ansible or any of those programs, it is
nothing but git and its branches.
But now i really left manually driven cryptsetup by far.
Ciao!
--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)
11 Sep
11 Sep
10:10 a.m.
On Sat, Sep 09, 2023 at 01:38:54AM +0200, Steffen Nurpmeso wrote:
You know, things change, and if you do not follow
closely, you
stand in the rain. I am not a paid Linux engineer that follows
this rapidly moving target in the end.
For example the (no longer) new random developer chose to disable
feeding entropy via /dev/urandom, here (distribution) still is
# Load random seed
/bin/cat /var/lib/urandom/seed > /dev/urandom
for almost two decades (it is a rather young one), but the code
path was mutilated (i read the kernel source once he had rewritten
that to be blake2/some 32-byte block thing based), now one needs
to use some ioctl interface fwiw.
Huh? That's not correct. You can still introduce entropy into the
random pool by writing to /dev/urandom or /dev/random. It is true
that there has been some changes to the design of /dev/random, but I
assure you as the original /dev/random developer, was consulted and
involved in the design discussions.
Anyway, this is off-topic for TUHS, but if you have specific
questions/complaints, feel free to address them to me and Jason. Your
comments do make me suspect that there are some fundamental
misunderstandings at work.
Cheers,
- Ted
12 Sep
12 Sep
4:05 a.m.
Theodore Ts'o wrote in
<20230911041059.GH701295(a)mit.edu>du>:
|On Sat, Sep 09, 2023 at 01:38:54AM +0200, Steffen Nurpmeso wrote:
|> You know, things change, and if you do not follow closely, you
|> stand in the rain. I am not a paid Linux engineer that follows
|> this rapidly moving target in the end.
|> For example the (no longer) new random developer chose to disable
|> feeding entropy via /dev/urandom, here (distribution) still is
|>
|> # Load random seed
|> /bin/cat /var/lib/urandom/seed > /dev/urandom
|>
|> for almost two decades (it is a rather young one), but the code
|> path was mutilated (i read the kernel source once he had rewritten
|> that to be blake2/some 32-byte block thing based), now one needs
|> to use some ioctl interface fwiw.
|
|Huh? That's not correct. You can still introduce entropy into the
|random pool by writing to /dev/urandom or /dev/random. It is true
|that there has been some changes to the design of /dev/random, but I
|assure you as the original /dev/random developer, was consulted and
|involved in the design discussions.
Ah, lesser and lesser freedom for man! That is the truth!
Neither was (last i looked) that counted no more to unlock man
from the chokehold of missing entropy, nor do newer kernels then
decrement entropy when you read random.
|Anyway, this is off-topic for TUHS, but if you have specific
|questions/complaints, feel free to address them to me and Jason. Your
|comments do make me suspect that there are some fundamental
|misunderstandings at work.
Surely for the latter. So much i give in on this song line.
Greetings.
--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)
5 Sep
5 Sep
7:07 a.m.
On Mon, Sep 04, 2023 at 10:44:21AM -0400, Norman Wilson wrote:
I don't remember any special many-programs-in-one
binary
like busybox in any Unix from the days when Unix was simple
enough for me to understand. That covers the entire lifetime
of the Research systems, but also System V and the BSDs and
their sundry offspring up into at least the 1990s.
I'm pretty sure OpenBSD at least still has nothing like
busybox. The nearest thing was to make sure certain programs
look at ls -i output on the install media/bsd.rd
https://man.openbsd.org/crunchgen.8
Added to FreeBSD and NetBSD in 1994.
252
days inactive
259
days old
20 comments
9 participants
participants (9)
-
Clem Cole -
Jonathan Gray -
Michael Kjörling -
norman＠oclsc.org -
Paul Winalski -
Steffen Nurpmeso -
Theodore Ts'o -
Vincenzo Nicosia -
Warner Losh