general question about tinycore

[P5music]

Hello,
I would like to know what's happening when tinycore boots, at the various stages, so I ask if there is some documentation about that. In particular: what happens when that line of dots is drawing on the screen?
Thanks

[gerald_clark]

The line of dots is from your boot loader loading the kernel and initrd.

[P5music]

Do you mean loading from the disk? Tinycore is 10 Mb.
Disk light just blinks for a fraction of second and then stops while dots are displayed. Then, there is a further long pause and still disk light is off.

[tinypoodle]

The disk LED is supposed to blink only when there is disk activity...
The dots displayed by certain bootloaders are just to be considered as a general primitive progress bar.  

Some insightful documentation I would consult for my own purposes would be in:
http://youpibouh.thefreecat.org/loadlin/loadlin-1.6e.tgz
or on the syslinux wiki: syslinux.zytor.com/

However, for details specific to the bootloader of your preference you might want to consult it's equivalent documentation, to the extent available.

BTW, I think the subject of this thread is not accurate at all, because these are general questions about bootloaders, not in the slightest particular to TC.

[maro]

In the following description I'm going to use a TC 3.2 CD-ROM as an example as this makes it a bit more clear cut. In particular as I had removed the hard disk from the notebook I used to confirm my assumptions. The situation for a disk based installation is pretty much identical, but then the choice of a method of persistence might "muddle the waters" a bit.

The bootloader (i.e. ISOLINUX in the case of the CD-ROM) "knows" about the kernel (i.e. 'bzImage'). It loads it into memory and extracts it there. Likewise with the initrd (i.e. 'tinycore.gz'), it gets read from the CD-ROM and the gzip-ed CPIO archive gets extracted as a RAM based file system. I'm myself a bit hazy at what point the control is handed over from the boot loader to the kernel (IIRC it's before the initrd extraction), but using the "standard" CD-ROM as an example this medium is only required until the boot loader has read those two files.

After hitting 'Enter' (at the 'boot: prompt to get the whole thing going) I observed that the LED went off just before the screen had a kind of refresh (and clearly before the screen blanking that preceedes the 'Booting tinycore_3.2" message). On other hardware I noticed that the cursor (a blinking underscore) jumps from the line below 'boot:' to the top of the screen. In any of these cases I was able to eject the CD-ROM and still ended up with a successful TC system boot. So again, one can eject the CD-ROM without harm when the LED goes off for the first time (or the screen refreshes or the cursor jumps to the top of the screen) as at that point in time the boot loader has finshed it's work and the CD-ROM is no more required.

If one would leave the CD-ROM in the drive one would notice (unless one uses boot options 'base restore') that the LED shows again activity after the 'Booting tinycore_3.2' message. This is due to the activities of the TC startup process in which devices are for example checked whether they contain a 'tce' directory in their root.

Anyway, after the bootloader is out of the way the kernel executes '/init' (as contained in the initrd). One task of this small script is to potentially tweak '/etc/inittab' (in case that the 'multivt' boot code was used). The "action" then moves on to the execution of '/sbin/init'. To get an idea what 'sbin/init" does a certain man page or the respective BusyBox source code could be studied. To me in a nutshell it means the interpretation of "/etc/inittab". Due to that files content the '/etc/init.d/rcS' file (which in the case of TC is actually a softlink to '/etc/init.d/tc-config') will be run in single user mode. Here a lot of the TC "magic" is happening (e.g. boot code interpretation, incl. persitence options and restoration from backup). Only after this single user mode phase has finished will 'init' spawn either one or multiple '(run)getty' processes. The first (or only) one will autologin as 'root' which (if not using the 'noautologin' boot code) will automatically kick of a login shell for the default user (i.e. 'tc'). That login shell then will bring up the X server (unless the 'text' boot code was used), and the "standard boot process" has come to it's (visible) conclusion.

I recommend to study all involved sriptes carefully if one wants to find out more details.

[Ztoragefool]

somewhat more general question added:

which would be good readings to understand TC's guts? what is it derived from? debian, dsl, slackware, lfs... ?

as an example, i searched the web for how to set up bridged networking. i found lots of tutorials suggesting configurations for ubuntu or redhat, which refered to config files i didn't find on tc. i ended up taking commands in bootlocal but still wonder if this is best practice...

so, i could have...
  - asked silly questions within this forum
  - googled for "howto bridge tap XXXlinux"   <--   anything comparable to tc?

[gerald_clark]

TCL is not a distribution like Ubuntu or Debian, and therefore the instructions for these distributions do not apply.

TCL is a tool set.
It is not based on any other distribution, but is composed of a standard kernel, the busybox toolkit, and a bunch
of custom shell scripts.
You decide which tools you want to use, and you provide the configuration and startup.
Bootsync.sh and therefore bootlocal.sh are the hooks for this.

You will need to read the man pages for your selected tools to learn how to use them.
Man pages that are not included in the packages can be found on the internet.

[maro]

Just to add a few personal notes to what gerald_clark has already stated:

My first stop for online manuals is typically http://linux.die.net Just be aware that sometime those pages are a bit out of date and one might have to find either the appropriate version on the home page of the respective project or download the sources.

For some Core components (e.g. the kernel or BusyBox) I found it to be valuable to have the (extracted) source code ready to search through. That does not mean to read the whole lot, but often enough the sources of a BusyBox applet are not too large and I believe it does not take a lot to make some sense of it.

As most "bloated" distributions (e.g. Ubuntu) are relying on multiple (surplus) layers of "obfuscation" (in an attempt to appeal to non-technical users) there is often only little to be gained by searching those forums. I personally have found the Archlinux wiki and forum to be often a good place to search for some hints. Chances are that one just needs some pointers regarding some settings or config files, and so far the folks over at Archlinux often had something useful for me.

An alternative might be the LFS (LinuxFromScratch) project. Albeit I believe I had not as much "luck" to find the detail I needed. That is maybe due to the fact that it descibes more how to bootstrap a system, and then assumes that one has followed their steps from the beginning. So as TC has some degree of overlap it does not follow that their approach mirrors what would be suitable for TC. Plus I find struggle a bit more to work myself through their search results.

As TC is luckily not that big the first thing I do after downloading a new release is to extract the initrd (i.e. 'tinycore.gz'). This then becomes a searchable structure in which I can quite easily look into the "guts" (at least as far as scripts and config files are involved). For the TC specific GUI applications the sources are typically also available (just maybe not updated during the RC cycles, but rather only after the full release has happened).

[tinypoodle]

somewhat more general question added:

which would be good readings to understand TC's guts? what is it derived from? debian, dsl, slackware, lfs... ?

as an example, i searched the web for how to set up bridged networking. i found lots of tutorials suggesting configurations for ubuntu or redhat, which refered to config files i didn't find on tc. i ended up taking commands in bootlocal but still wonder if this is best practice...

so, i could have...
  - asked silly questions within this forum
  - googled for "howto bridge tap XXXlinux"   <--   anything comparable to tc?

For the specific subject, if I were you, I might rather first look at busybox/Linux based firmware for routers (e.g. OpenWRT) than at those GNU/Linux distros which you mentioned.