no unionfs system is used only symlinks --- right ?
No overlayfs/aufs/unionfs ... just bulk standard kernel
everything is symlinked into the initrd --- right ?
Now yes, thanks to you, before I was extracting tar files into / (within initrd).
how did you build your initrd
It's very minimal, just enough to get to busybox cli. I'll have to strip out private bits (ssh keys etc) and upload my latest version
where did you get the components
Compiled from source, or as I use Fatdog as the built-tool and the same kernel version I can pinch bins and libs from Fatdog and drop them in. I do that for mc. Just a handful of programs, busybox, fnvnc, openssl (required by ..) openssh, wireless tools (iwconfig/wifi stuff) ... and otherwise just files/folders/scripts. All compiled statically, preferably musl and I upx the binaries (so no libs involve, like the kernel has no external modules/firmware, the required bits are all built into the kernel).
i understand that you build your kernel from scratch - right ?
Yes. Boot fatdog, load the devx sfs, grab the latest kernel source from kernel.org (I'm tracking the 5.4 kernel), extract that source code, cd into it and
make localyesconfig
make -j4
(I have 4 cores on my build system, if I compiled on my 2 core laptop I'd use make -j2 instead).
That creates a bzImage ... which can just be renamed to vmlinuz and you have your kernel. At least that's how I started off, and later I revisited the configuration (make menuconfig ... and change whatever settings and save, ... and then run make -j4 again to build that) and changed things so that it builds with a framebuffer ...etc. under something like devices, graphics ... in make menuconfig (forget offhand exactly where).
is the file layout standard linux --- / /bin /sbin etc
Yes
as i understand it you are running most things in qemu -- right ?
I compiled and added in fbvnc into my build (a framebuffer based version of a vnc client) and boot with a vga=ask kernel boot parameter (actually I've coded the choice I use) and select a VESA choice. Once that's booted I wifi net connect and then can vnc into my desktop system (that is running fatdog and has x11vnc (server) running) using fbvnc ... and up pops the gui desktop.
So the kernel (vmlinuz) boots and the kernel hands over to my /sbin/system-init which looks like
Code: Select all
#!/bin/ash
[ $$ -eq 1 ] || exit 1 ### bail out unless we're PID 1
KERNEL_POLL_MSECS=${KERNEL_POLL_MSECS:-5000} # default kernel polling value if unset
# mount core filesystems
/bin/mount -t proc proc /proc # mount /proc first so /proc/self/exe works from now
mount -t sysfs sysfs /sys
if ! mount -t devtmpfs devtmpfs /dev 2> /null; then # /dev/null may not exist yet
# if no devtmpfs, use tmpfs and use mdev instead
mount -t tmpfs tmpfs /dev -o mode=755 # mode 755 is what devtmpfs uses
mdev -s
fi
[ -f /null ] && rm /null # Clear up the null file created above
[ ! -e /dev/shm ] && mkdir -p /dev/shm
[ ! -e /dev/pts ] && mkdir -p /dev/pts
[ "$TZ" ] && hwclock -t # set kernel timezone
# debugging and error logging comment out next two lines for greater info during bootup
! grep -q showerr /proc/cmdline && exec 2> /dev/initrd.err
grep -q debuginitrd /proc/cmdline && set -x
# enable polling
if ! grep -q block.events_dfl_poll_msecs /proc/cmdline; then # if not explicitly set
echo $KERNEL_POLL_MSECS > /sys/module/block/parameters/events_dfl_poll_msecs
fi
loadkmap < /lib/boot/keymaps/uk # keymap hard coded to use uk (GB)
ifup lo # required by ssh
# Hand PID 1 over to busybox init (that references /etc/inittab)
exec /sbin/init
where that last line hands over to /sbin/init ... that is a sym link into busybox init.
Busybox init then does its stuff and uses either its own integral /etc/inittab, or if one exists in /etc/inittab that is used instead. The busybox integral version looks like
https://git.busybox.net/busybox/tree/examples/inittab
No rc.d or anything like that coded/used, just a (graphical/framebuffer) cli within initrd that is then used to read/copy whatever the vnc server serves (gui desktop) to the framebuffer (display).
More recently, rather than using tarballs, I've added /opt/sfs folder into which I've copied mc.sfs and net.sfs files rather than having to mount and load them from externally. Once mounted (mkdir /mnt/mc;mount /opt/sfs/mc.sfs /mnt/mc), I sym link them into / (cd /; cp -ars /mnt/mc/* .)
Fundamentally the initrd is just busybox and all of the userland commands that contains are sym linked to that. Once booted then sfs's are mounted (mc.sfs and net.sfs in my case), and sym linked into / ... which then has a pretty functional cli based system, with wifi networking, openssh (scp, sftp, ssh, sshfs) and mc (file manager and ncurses style (easy to use) text editor). With that available you can pretty much go in any direction you like, but with access to a gui desktop via vnc and all that that offers, I have no need to add to that 'base system' (I have however recently added qemu.sfs so it can run a qemu session directly, such as booting any iso's, other vmlinuz/initrd's, image files, partition ...etc.), so it could boot multiple instances of other systems (Puppy, tinycore) and vnc into those (multiple desktops/concurrent-systems). But that's not really a necessity, as I could just boot one of the iso's directly and install/use qemu within that. Accordingly I've not copied qemu.sfs into /opt/sfs .. but instead leave it 'outside' so available to be mounted/sym-linked should I so choose.
Very much similar to tinycore in many respects, except their kernel is more portable, whilst mine is highly machine specific. Far easier to just use tinycore as the 'base system' rather than going through all of the above build process. When you're booting a system to just vnc into a server, a client system that is just handing raw screen reading from the server to throw to the display, that can be pretty much anything, security isn't really a issue (mem copy what is thrown across tcp onto the display). If the server is a iso read only booted system as mine is, then that's moderately secure, and also means that web sites see that system as the source system, not the actual source system. So any files on the tinycore system are secure, unreachable unless that system is otherwise opened up. You get to choose which files you might transfer to/from the server such as via scp, or using sshfs/mc (mounting and using a file manager).