[Toybox] Toybox / mkroot init

[enh]

On Thu, Feb 19, 2026 at 4:40 PM Rob Landley <rob at landley.net> wrote:
>
> On 2/17/26 05:21, Roberto A. Foglietta wrote:
> >>> I wish to know which was the license in original, BSD (as toybox), MIT? etc.
> >>
> >> 0BSD like the rest of toybox.
> >
> > Thanks for the kind answer.
>
> Conceptually this initramfs is just
> https://linuxfromscratch.org/hints/downloads/files/OLD/bsd-init.txt
> taken to its logical conclusion. (Over the course of 20+ years. And I'm
> pretty sure I started with an earlier, simpler version of that before it
> got "updated" to be more complex, but am not fishing for it...)
>
> >>> - why 6.17 instead of 6.12 which is a Long Term Support ?
> >>
> >> Toybox releases generally use the kernel that was current at the time of
> >> the toybox release: toybox 0.8.13 came out October 14 and linux 6.18
> >> came out december 1, a month and a half later.
> >
> > Obviously, the same concept can apply when sticking to a LTS branch
> > but the micro version would be taken instead.
>
> No, the point is to catch upstream regressions in the kernel. I have a
> patch stack I apply
> (https://landley.net/bin/mkroot/0.8.13/linux-patches/) to beat basic
> functionality out of it for that set of architectures. (The README in
> the same directory as the tarballs mentions this, as do the release notes.)
>
> At some point, the kernel will make a Career Limiting Move like refusing
> to build basic services without rust or something. I maintained a perl
> removal patch stack for many years (it finally went upstream in 2013,
> about the same time an employer poked me to fix the initramfs
> documention I'd written back in 2005 that said you could also use tmpfs,
> by making the vanilla kernel actually do that)
>
> This is why mkroot builds under a toybox airlock: when they break stuff,
> I like to notice before institutional memory of what they DID fades.
> (Not that they've answered my questions in a while now. Development is
> going down such a rathole these days I've got "migrate to netbsd" on my
> long-term todo list because this ain't gettin' fixed. The cultural
> recto-cranial inversion that's blocked things like
> https://landley.net/bin/mkroot/0.8.13/linux-patches/0003-Wire-up-CONFIG_DEVTMPFS_MOUNT-to-initramfs.patch
> from going upstream since 2017 is a progressive condition.)
>
> > Useless that I explain to you the advantages of a LTS branch, for the
> > others: more continuity in personalising the mkroot.
>
> I'm aware of the concept of "Long Term Support" (since Ubuntu started
> using the name), and get cc'd on Greg KH's LTS branches for a year after
> any patch I've got an acked-by on goes in.
>
> You're welcome to use other kernels. The LINUX=/path/to/source argument
> is theoretically kernel agnostic, or you could build it yourself using
> the docs/linux-fullconfig file in each tarball. These are just the
> releases _I_ do.
>
> (Somebody rewrote mkroot in rust for no apparent reason. That "one true
> language" cult has advanced to the point they feel the need to rewrite
> bash scripts in their fixation now. Am I the only one who thinks
> clawdbot and moltbook and stuff having obviously rust-derived crustacean
> logos is... indicative of a mindset? No, just me? Ok...)
>
> >>> Finally, one more question because I saw musl in a toybox:
> >>>
> >>> - What's about https://github.com/jart/cosmopolitan ?
> >>
> >> Are you trolling, or are you serious?
> >
> > I am serious, I did not have the time yet to investigate it.
>
> If you're not skeptical of a "one true standard" that hasn't been
> touched in 6 years...
>
> https://xkcd.com/927/
>
> It thinks "universal" means Linux plus mac and 3 bsd versions. It's
> x86-64 specific despite mac having gone arm ~6 years ago (before x86 it
> was ppc, and before that it was m68k, so if you think that's the last
> stop...) and Android having been arm all along. It seems to add /bin/sh
> (and thus sourcing various profile scripts) into the invocation of every
> binary. (Presumably meaning your shell still has to be an actual binary
> and libc your kernel has a loader for?) If they really did write their
> own libc (I didn't dig that far) then lib/porability.{h,c} would
> probably double in size trying to make that work. The author does not
> even seem to be aware of issues like
> https://devblogs.microsoft.com/oldnewthing/20050131-00/?p=36563 (unless
> they're applying Linux binary semantics to windows binaries in which
> case your syscall translation layer's gonna be HUGE, or maybe they're
> running under WSL there in which case why not just ELF?)
>
> I wrote a noticeably longer list of gripes the first time (and am not
> going through the page and enumerating issues or looking up rebuttal
> links again), then deleted it to first ask whether or not you were
> serious because I could no longer tell.
>
> One of the big problems with https://pubmed.ncbi.nlm.nih.gov/41656802/
> is how its users make piles of work for other people. "You did not think
> of this because you did not think at all. You deployed something a
> vending machine glued together out of recycled parts which worked for
> you once, in a problem space you did not even attempt to understand, and
> the inevitable side effects are "externalities" which other people
> clearly should clean up for you because said vending machine tells you
> that you are a special person whose time is more valuable than theirs.
> (And that's not ME saying it,
> https://openai.com/index/sycophancy-in-gpt-4o/ was about doing a whole
> revision to try to make the "sycophancy" (their word!) less obvious
> and/or legally actionable.)
>
> "Explain to me why this is wrong" is making a request for my time and
> energy, to perform an analysis for someone who admits they haven't
> looked into it at all yet.
>
> > My fault
> > for having not done my homework before asking and just hoping for a
> > brief answer by a supposedly well-known human instead of querying an
> > AI chatbot. Sorry, for asking OT.
>
> It's not the off topic (if you'd asked about shipping bionic binaries or
> mac binaries or bsd binaries that would be relevant), it's that you
> didn't think through it yourself and wanted me to think for you.
>
> I remember you from the busybox mailing list 20 years ago. The first
> commit in the busybox repo mentioning you (7b4aa6ffc6a4) is from 2006.
> You've got at least as much experience here as I do. You're asking me
> about a project you could have poked at yourself to see if it was load
> bearing.
>
> Yes, that project is vaguely familiar at first glance, I'm pretty sure
> it wandered by years ago and seemed a manifestation of dunning-kruger
> then too.
>
> There's a reason the web page was last updated 6 years ago and did not
> take the world by storm in the intervening time. What it's TRYING to do
> has an enormous attack surface, to the point it would have been big news
> if it HAD worked. Extraordinary claims require extraordinary evidence.
>
> (I'm trying not to be prejudiced by
> https://lists.busybox.net/pipermail/busybox/2026-February/091907.html
> and https://lists.busybox.net/pipermail/busybox/2026-January/091889.html
> and such, but... there's a reason I keep thinking about AI psychosis in
> this case.)
>
> >> I'm not interested either. (Either we have hardware entropy or we don't
> >> have hardware entropy. Userspace can't programmatically provide entropy.)
> >
> > I see your point, but hardware is free from interference?
>
> No, it's about understanding threat models.
>
> Do you know why Diaper Dan loves eating McDonalds? Because back when I
> lived in New Jersey (I moved out in 1995) he was laundering money for
> the Russian mob.
>
> (Which he seems to have pivoted to after blowing through the entirety of
> Fred's estate, which he acquired by appointing himself executor of it,
> https://nyprobate.com/mary-trump-donald-trump-lawsuit-inheritance/ has
> some of the details but it was common knowledge around Atlantic City
> back in the day. Seriously, why do you think he's gone bankrupt so many
> times but
> https://www.theguardian.com/business/2019/apr/17/deutsche-bank-faces-action-over-20bn-russian-money-laundering-scheme
> was always willing to loan him more money? Because before 2008 the IRS
> didn't look at LOSSES as potential money laundering, so all an oligarch
> had to do was "loan" a billion dollars to a cleaner, who then spent 95%
> of it on the oligarch's businesses and then declared bankruptcy. The
> more blatant oligarchs even got a tax writeoff for the "losses", to
> apply against the new "income" to avoid paying taxes on the laundered
> money.)
>
> Since the russians love poisoning people (apparently Nalvany got done in
> by dart frog poison, which is just showboating), grabbing random
> commodity meals from an outlet that didn't know he was coming made that
> asshole feel safe back when he still had a temporal lobe.
>
> The same is approximately true of commodity hardware. You can do supply
> chain attacks on it, but a random raspberry pi grabbed off the shelf
> from best buy or something doesn't give a lot of attack surface.
> (Especially if you took public transit with your phone left home and
> paid cash. :)
>
> As I said: threat models. Who is likely after you to accomplish what? My
> programming output's posted publicly and subject to peer review, what
> would exploiting my stuff get anyone other than the usual personal
> theft? (Or done on hardware provided by an employer thus delegating
> fiduciary responsibility for securing it.) I have electrical tape over
> my phone's front and back facing cameras and never ever spend money
> through it because that's my comfort level, yes I'm aware there's no
> tape over the microphone but you gotta draw the line somewhere. I paid
> more than a new phone would cost to have the screen replaced recently
> because as nice as Elliott is, I don't trust the corporation that did
> https://www.kaspersky.com/blog/what-are-android-safetycore-and-key-verifier/53171/
> to provide a new OS version those can't be uninstalled from, and I
> really don't want to stop to come up to speed on grapheneOS right now. I
> could write for half an hour on the downsides of using an old android
> version that went out of service in 2022, and again about migrating to
> https://www.youtube.com/watch?v=4To-F6W1NT0 but there are no perfect
> options, and you've gotta pick a local peak in your threat model that
> mitigates "enough" risk. There is no "safe", just "safer" with a price tag.
>
> > Can be
> > protected and it is local. Unless the hardware itself is tampered or
> > remotely switchable. Which is not a theoretical hypothesis anymore,
> > unless very cheap and limited uCPU.
>
> If your hardware has been tampered with in a supply chain attack or evil
> maid situation, you've already lost.
>
> > Anyway, just let me say: CPUs are hardware,
>
> See the j-core stuff in https://landley.net/resume.html going back to
> 2014? Or stuff like
> https://web.archive.org/web/20001109095700/http://www.fool.com/portfolios/rulemaker/2000/rulemaker000901.htm
> from basically a previous life.
>
> I am aware that CPUs are hardware, thanks.
>
> > thus they can be used for
> > entropy. Despite CPUs not being available as devices (in a proper
> > terms we can intend a /dev/tty) their working affect indirectly the
> > userland activity in particular because of scheduler. Thus, the
> > scheduler jitters are a hardware source of entropy that can be
> > collected also by an userland application.
>
> Which the linux kernel has done since... 1996 I think?
>
> The kernel is providing those context switches for you. If the kernel is
> exploited, the idea that userspace using information provided from the
> kernel can keep you safe is basically the old hashing security argument
> (providing unknowable answers from known inputs). There used to be some
> conference videos from ~1985 about that. (Not HOPL II but filed next to
> the HOPL II tapes, years ago on VHS in a library I drove to back when I
> lived a more nomadtic lifestyle after my mother died and I inherited her
> station wagon...)
>
> > We can agree that we do not trust in userland,
>
> Who's "we", kemosabe?
>
> I don't trust the kernel, the hardware, and vaguely expect that if we're
> up against a state/oligarch actor somebody's got a drone pointing a yagi
> antenna through a window or hooked up a synchrophasor the building's
> power lines to reconstruct the processor operations from electromagnetic
> evidence of differential power consumption or similar nonsense. (Which
> was "cutting edge as far as I knew" circa 2005, meaning the Five Guys
> had probably been encoding it into their french fries 20 years before
> then...)
>
> Seriously, the dunning-krugerand priesthood were worried about this sort
> of thing when https://xkcd.com/538/ was obviously more common. As in
> https://apnews.com/article/crypto-cryptocurrency-kidnapping-new-york-f43b5da989093d956ab39bc5fc62a72a
> were IDIOTS because the pros quietly threaten family members and such
> and get away without leaving evidence.
>
> My father did defense contracting from before I was born until after I
> graudated and moved away (the stuff on kwaj was ICBM guidance and
> tracking systems, the New Jersey Stuff was the Aegis Phased Array Radar
> System). My grandfather (on the OTHER side of the family) worked for the
> NSA for 40 years and I _didn't_know_ until my mother's funeral in 2002
> (when he got very drunk and my brother had to wrestle his gun away from
> him; outliving his wife _and_ 2 of his 3 children did not sit well), at
> which point he'd been out of the game for 15 years (he never
> volunteered, he just did cryptography during world war II and they told
> him if he didn't "volunteer" for this new OSI thing that turned into the
> NSA they'd draft him and put him on the font line in Korea; he finally
> got out when some IDIOT tried to hand off information to him in Iraq in
> 1986 and blew his cover as a senior engineer at GE sent around the world
> to troubleshoot problems. I knew my father and mother met on the apollo
> program because he dated the boss's daughter, I _hadn't_ known said boss
> was Verhner Von Braun's NSA liason.)
>
> There is a reason I've never taken a job requiring security clearance. I
> have zero interest in getting any of that crap on me.
>
> "What level am I operating at? Not that."
>
> (I still need to read https://en.wikipedia.org/wiki/The_Puzzle_Palace
> which I _think_ was the book Grampa said was very good, but I also got
> the vague impression that No Such Agency turned into a PR firm when it
> got outed and the real work moved to like army intelligence or
> something? Not my area, I haven't asked, dowanna get that on me...)

even more off-topic, but if you like the sound of john le carre mixed
with contemporary british social commentary, i can't recommend
https://en.wikipedia.org/wiki/Slough_House_(novel_series) highly
enough. it gets a little weird when his "legally distinct boris
johnson" collides with the real boris johnson having been elected to
the position the earlier books feared the fictional one might get to,
but theonion.com has been having worse problems for a while now...

> > by principle. I can
> > agree but testing in userland is fine. Moreover for the same
> > principle, I can tell you that I do not trust the host and an userland
> > application might deceive its own behaviour pretending to be tetris
> > but being anything else. Let me clarify this point, I am not speaking
> > about a virus or a rootkit or whatever malicious.
>
> You literally cannot be paranoid enough. Thus I just assume exploitation
> and fraud in the system all the way down, treat it as a cost of doing
> business, and mostly try not to be worth targeting or let obvious stuff
> go unverified. (Can't stop it, might catch it after the fact, or at
> least preserve forensic evidence I'm currently unaware of the value of
> so experts eventually can if it ever comes up.)
>
>  From a technical perspective: busybox added a basic https
> implementation to its lib because without it wget and httpd are
> basically useless in a modern context. So added "simple RSA+AES tls 1.2"
> to the post-1.0 TODO heap but haven't really looked at it yet (outside
> of bookmarking https://www.muppetlabs.com/~breadbox/txt/rsa.html and
> such...)
>
> But that's "missing capability I don't want to depend on an external
> library to provide". If your kernel mechanism underlying libc's
> getentropy() is borked: fix your system.
>
> > I also agree that a A4 paper, smooth surface, standardised maniacally
> > precisely would not introduce any watermark in a pen writing while a
> > more "artisanry" piece of paper would.
>
> https://en.wikipedia.org/wiki/Printer_tracking_dots#Protection_of_privacy_and_circumvention
>
> Being aware and wanting to engage are different things. No thank you.
>
> (You leave fingerprints on everything. You leave DNA on everything.
> There are cameras everywhere. Don't read up about palantir if you don't
> want to lose sleep due to rage at the sheer injustice of guilllotines
> not currently being part of the social contract's generally agreed upon
> enforcement toolkit.)
>
> > By the way, I have cited busybox because I wish to have a toybox or a
> > busybox (the advantage of ash, from my PoV but ash can be provided as
> > its own alone)
>
> I'm trying to get toysh into reasonable shape but life has not been
> cooperating the past few years.
>
> > as self-contained executable which is something above
> > in terms of abstraction than a static binary, it is an executable
> > initramfs before even the concept of file system enters in the scene
>
> A filesystem before a filesystem?
>
> You have to have a filesystem to launch the first executable from,
> that's how PID 1 launches. (And before that it opens stdin/stdout/stderr
> from /dev/console which I've GRIPED ABOUT AT LENGTH in so many places
> because the static initramfs path is buggy in the kernel and they keep
> ignoring my attempts to fix it...)
>
> > (and thus cannot be accessible by userland in any manner by direct
> > interaction).
>
> https://landley.net/aboriginal/old used to glue a zisofs (squashfs
> didn't exist yet) onto the end of a kernel (lilo patch in a real boot, I
> don't remember if grub existed yet) or a user mode linux ELF executable
> (qemu didn't exist yet) and repurposed part of the ELF header to point
> to the offset to loopback mount the file from the initrd (initramfs
> didn't exist yet) and then pivot_root (I don't think mount --move
> existed yet)...
>
> There's a reason I was following initramfs very closely and wrote up my
> own documentation when I couldn't find any.
>
> I"m pretty sure you were around on the #busybox IRC channel and mailing
> list during this time.
>
> Rob
>
> P.S. One of my proposed talks at ELC, since they're having it in
> Minneapolis this year, is "booting Linux under VHDL simulation" where we
> build a toolflow (well, nvc), build simulated VHDL hardware that sort of
> thinks it's an ECP5 FPGA with simulated spi flash (also VHDL, from some
> foundation) and simulated giant block of SRAM (C via
> https://www.nickg.me.uk/nvc/manual.html#VHPI) bolted on, build linux
> from source with a new device tree, and then do hardware bringup through
> our own ROM bootloader (also written in C, which we also compile during
> this, then the SOC build creates the rom using a trap-based ELF loader
> WRITTEN IN VHDL, Jeff is crazy) that reads a vmlinux from the flash and
> ELF loads it into the sram and calls its entry point, so it can boot up
> and spit messages out to emulated serial port and eventually a serial
> console shell prompt.
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net