kernel (vmlinuz) boots, runs /sbin/system-init - whose last action is to switch_root.
switch-root performs a recursive rm to free up space as part of handing over to the new (main desktop) initialisation process.
But AFAIK the mounting of fd64.sfs when on HDD doesn't get removed from the Bulldog/early stage boot, its in use, ro, so in effect remains linked into the 'underdog' (hidden) space.
So we can boot with basesfs=direct ... and following switch_root fd64.sfs is still mounted/used within the early boot process, such that the main session /aufs layer from where content of the fd64.sfs is accessed is still available.
Booting with basesfs=ram... tends to eat near on 1GB of ram after initially booting (fd64.sfs copied into ram), however booting with basesfs=direct and that declines down to less than 200MB (pointers being used), but that grows as more files (browser/office ...etc.) are opened and 'cached'. A more efficient (ram) choice. Booting with pfix=nox and I can umount sda1 where fd64.sfs is located and that seemingly obliges, because the main session doesn't see the Bulldog/initramfs 'system'. When startx is run however, up pops the fatdog icon over sda1, indicating it shouldn't/can't be unmounted. When using physical HDD that makes no difference as the HDD is physically attached, if however fd64.sfs was on a removable disk or USB then that would result in failure/crash if the disk/usb were physically unplugged. In effect anything that the switch_root rm didn't remove, such as fd64.sfs being mounted at /mnt/somefolder within initramfs, and switch_root's rm of that content invisibly fails with sorry read only content cannot be removed.
Clever how it works, Bulldog files are largely removed excepting the read only (sfs) contents and where access to that is still maintained within the main session that is switch_root into, but not the actual files/data, rather just pointers, that are still within the bulldog/initramfs hidden layer
https://github.com/torvalds/linux/blob/ ... tramfs.txt
When switching another root device, initrd would pivot_root and then
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
rootfs, nor unmount it. Instead delete everything out of rootfs to
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
with the new root (cd /newmount; mount --move . /; chroot .), attach
stdin/stdout/stderr to the new /dev/console, and exec the new init.Since this is a remarkably persnickety process (and involves deleting
commands before you can run them), the klibc package introduced a helper
program (utils/run_init.c) to do all this for you. Most other packages
(such as busybox) have named this command "switch_root".
Conceptually a rootkit could prevent itself from being deleted as part of switch_root and remain active/resident within Bulldog/initramfs, running invisibly in the background, perhaps only visible via top and square braces kthreadd type indication, of which in a regular boot there are many.
Has anyone looked into methods of monitoring those for potential suspicious/unusual activities? A trojan/virus hidden in that invisible layer would seemingly be the ideal choice for hackers.
