[Aboriginal] Using aboriginal as a bare-bones linux install

[Rob Landley]

On 10/21/2015 02:10 PM, Avery Payne wrote:
> I have an old 32-bit atom-based HP 311 netbook that I want to install
> aboriginal on.  The goal is to have a "clean slate" Linux install that
> has the absolute minimum software; literally, a Linux install with the
> "fewest" preconceived notions from a distro maintainer.  I have my own
> pedantic reasons for doing this, but they are my reasons; the biggest is
> not being dependent on a distro maintainer, and by extension, some of
> their decisions.

Well, there's still some decisions: Does your "absolute minimum"
software include the toolchain, or just boot to a shell prompt? If it
does should the packages be statically or dynamically linked? Is your
idea of minimal "busybox defconfig" (minimum number of configuration
decisions) or the combination of busybox+toybox I've worked out as the
minimal set of commands needed to build linux from scratch (plus ones
like "ps" that you kinda miss if they're not there on the command line)?

More pragmatically, packaging-wise do you want root-filesystem running
out of initramfs, or do you want it on the sd card filesystem too?

If the latter, in theory you can copy the contents of
root-filesystem-i686.tar.gz and native-compiler-i686.tar.gz into the
same directory and they should work. I.E. cribbing from
more/chroot-splice.sh:

# Copy root filesystem and native compiler
cp -lan "build/root-filesystem-$1/." "$CHROOT" || exit 1
cp -lan "build/native-compiler-$1/." "$CHROOT" || exit 1

> I really, really want to be able to build aboriginal in such a way that
> it builds direct to a SSD, filesystem and all, and install a boot
> loader, and bamo-presto, my very own bare-bones Linux install.

The system-image.sh stage builds the kernel and packages it into a
tarball, but there's nothing to say you can't add another script at the
end that does the above two cp to a target directory and adds your
bootloader.

> I've
> managed to get nice clean i686 builds, and the SSD mounted inside of
> QEMU as a "full drive";

Ok, you're ahead of me. :)

> I'm still working out the details needed to get
> the files moved from the image to the SSD without horking the target
> image (think /dev & friends coupled with handling all the symlinks),

Most of the symlinks are relative ones designed to be moved, the "init"
symlink in sources/root-filesystem for example.

The symlinks setup by sources/toys/hdainit.sh are probably absolute though:

  cp -rFs /usr/overlay/. /

That happens at boot time. The above hdainit gets copied into the
native-compiler squashfs as "init" at the top level, and then
sources/toys/sbin/init.sh mounts /dev/hda on /usr/overlay and then calls
/usr/overlay/init if it exists.

For chroots I do those fixups manually, see more/setup-chroot.sh for
example.

> and
> finally, some kind of bootloader installed (which terrifies me because
> if I screw that up, I could hork the host bootloader).

One of the reasons I do so much with qemu is it's very difficult to
persistently break it. :)

You'll want a boot USB stick or similar standing by when you play with
bootloaders.

> That being all said, thank you so much for your hard work on aboriginal.
> 
> (the following was hijacked from another thread on qcc):
>> What initially attracted me to tinycc was:
>> http://bellard.org/tcc/tccboot.html And the windows clowns following
>> grishka's "mob branch" (we don't need a maintainer, we can have
>> drive-by checkins with nobody steering!) are _father_ away from making
>> that work on a vanilla kernel than what that shipped _eleven_years_ago_. 
> Since I know bumpkis about C, just what about the current Linux kernel
> makes it so it can't be compiled with an older C compiler like tcc?  (or
> pcc for that matter...)  Is there some dependency in the kernel that
> requires a specific part of the language that older compilers won't handle?

It's not "older compilers" such as "using every part of the buffalo when
it comes to gcc features". They're getting better about it now that
http://llvm.linuxfoundation.org is providing pushback, but only half the
fixes are weaning the kernel off of gcc-isms, the rest are llvm
implementing more features the kernel uses.

I remember building the kernel died near the start trying to create an
asm-offsets with objdump and sed, but it looks like that part of the
kernel's been rewritten not to require that anymore?

Really, make a $PATH that only has tinycc as the cc and try it and see
what breaks. That's what I did. (No binutils, no nothing. Aboriginal's
host-tools.sh and more/record-commands.sh and
more/report-recorded-commands.sh give you an example.)

>> As I mentioned in the 2013 "why is toybox" youtube video mentioned
>> above, a self-hosting development environment needs 4 things:
>>
>> 1) kernel
>> 2) libc
>> 3) command line
>> 4) compiler
>
> You need to be able to load source into the environment.  I know from
> your view, you would do this while the image is still hosted, build
> inside the image, and deploy later.

Actually I create control-image filesystems that have source and attach
them to generic system-images that do what the control-images tell them.
That way I don't have to rebuild the system image to do an arbitrary build.

>  But for my needs, it will not
> really be self-hosting until I can pull source *after* deployment.

Busybox has wget and it's on the toybox roadmap. I also plan to add
rsync to toybox, and you can network mount filesystems (virtfs is built
into qemu, I'm told the new smb 2.0 is actually a sane protocol I should
write a server for, I was very interested in v9fs until its developers
convinced me not to...)

Heck, one of the things I've done is uuencode stuff, cut and paste it
through a serial console to uudecode. Mostly to get a binary onto a
recalcitrant system after the fact, but heck. There's a bunch of ways.

I'm pretty sure that was a section of my old 2008 presentation...

https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu

I went over a little of it starting on slide 133, and other bits of it
elsewhere in the presentation...

> Is there a ftp client in toybox?

Not yet, but there's one in busybox. ftpget/ftpput. The various
control-image files use that to upload results to the host. (The
dev-environment.sh build script launches a temporary ftp server to
receive the results, if it's available in the $PATH.)

>  If there isn't a pre-existing client for
> my needs, I'm looking at loading curl in the image.  Using wget is
> another option but I have no clue how many GNUisms will be needed to
> build it (and by extention how much the requirements will "pollute" the
> install with stuff that I might not want).

Busybox has one, toybox is scheduled to add one.

I note that 90% of the sites on the net you go to these days need https,
which means you'll need openssl built so toybox can call the openssl
comand line program to pipe the wget through. (Not implemented yet but
there was a message about it from... Isaac Dunham I think? posted to the
toybox mailing list a month or two back.)

Rob