I have built a 32 bit version of Docker daemon and client, and I am now attempting to configure Tiny Core 8.0 x86 to run these.

I have resolved most of the problems by installing a few missing dependencies, rebuilding the kernel after enabling a couple of missing flags, and symlinking the persistent storage location to a folder under /mnt/sda1. At this point, the Docker daemon starts up without any errors. When I try to run the following test:

docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux_go:359: container init caused \"rootfs_linux.go:90: jailing process inside rootfs caused \\\"pivot_root invalid argument\\\"\"".The test will run successfully, however, if I set environment variable DOCKER_RAMDISK to true, which sets the no pivot option on runc. So the pivot_root problem should hopefully be the final hurdle to getting this system working.

Doing a little reading into kernel documentation, I came across an article entitled ramfs, rootfs and initramfs. The apparently relevant information from that article:

Quote

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.

I have also found this reiterated in several other sources as well. Summary of the main points:

initrd is loaded into ramdisk which is an actual file system.

initramfs is not a file system.

For initrd pivot_root is used and for initramfs switch_root is used

You can not use pivot_root on an initramfs rootfs, you will get Invalid Argument. You can only pivot real file systems.

This is unfortunately very new territory for me (I'm fairly new to linux, so I'm still getting familiar with the various technologies and vocabulary). This may be more of a conversation for me to have with the Docker community, but thought I would post here to see if anyone has some ideas.

It is also possible that I have completely misdiagnosed the problem, so feel free to call me an idiot

Part of your problem may be related to what I alluded to in another thread. In a fat distro like Ubuntu, the initial ram disk is compiled into the kernel, then another file system on the hard drive is "pivoted" to so as to become the new root file system. In TCL, the ram disk is loaded as an initrd (initial ram disk), then continues to be the root file system after the boot process is complete. No other file system is pivoted to. If you want to use TCL as your docker OS then you will need to build another file system image to load after the stock core.gz (or modify the supplied core.gz) instead of trying to pivot to another FS. As you say, it works when you don't pivot, which makes sense. Pivoting is for the classic install where all the OS files are on a hard drive.

Thanks, andyj. Actually looking at this again, it appears the environment variable DOCKER_RAMDISK is designed for just that to make Docker work when the root is on a ramdisk. I believe I initially misinterpreting this variable, thinking it was for holding the container file system in RAM (which would not work for largish containers in the environment I am planning to use this). I'll do some resource monitoring to confirm, but there actually is probably not any problem here (working as designed).

I did some resource monitoring as I loaded containers of various sizes, and can confirm that they are using the persistent storage (versus loading their filesystem into RAM). So all problems appear to be resolved and I am able to run Docker daemon and client in 32bit on Tiny Core. Solution for this particular problem was just setting the environment variable DOCKER_RAMDISK=true before starting the daemon.

Thanks again for the help! It is always satisfying to complete a proof of concept successfully. Now onto my next challenge..