pauses in boot sequence

[SBor]

Hi,
I am using TC frugal install on a VIA Epia with 0,5GHz C3 processor and 256MB of RAM.
Boot device is a 2GB IDE flash module.
Compared to other Linux and Windows, TC boots fast, that is for sure.
But I would like it even faster, the PC is used kind of as an embedded device in a
model railroad panel.
Therefore I examined the /var/log/messages
and found that there are no entries in two periods during boot. I attached the log file.
As you can see, the kernel boots in no time until it starts dealing with extensions.
From 10:51:07 to 10:51:14 the extensions seem to be mounted. I assume that this is
when on the boot screen the names of the extensions are shown one by one on the screen.
One thing that I find strange is that there are some cp-commands listed in the log file,
but the "cp -ais" just creates symlinks per file in the archive, right?
Than between 10:51:14 and 10:51:24 the system stays mute for 10s.
This is in sync with what I see on the screen during boot. What is happening in that gap?
Is there a potential to get rid of this pause?
Than from 10:51:24 to 10:51:26 I see some scripts work and the usb-serial devices are finally recognized after already being recognized earlier by the ignorant kernel, thanks to the now loaded extension.
Than the next pause happens from 10:51:26 to 10:51:53. What is going on now?
After that it takes a few more seconds until I see X windows.

[curaga]

It might be more useful to take a bootchart ( http://wiki.tinycorelinux.net/wiki:bootchart ), as it would show what is happening.

[Rich]

Hi SBor

but the "cp -ais" just creates symlinks per file in the archive, right?

Yes. Extensions get mounted under  /tmp/tcloop  and their files get linked into the file system.
Enter   /bin/cp --help   to see what the  -ais  options do.

[maro]

A view things come to mind:

• It is difficult to figure out from here whether those delays are due to HW (or driver) recognition or simply large workloads in the file system (e.g. copying of many files). I don't know whether the timestamps in those messages reflect when a task gets started or when its finished.
  
• There are quite a few extensions that are getting installed at boot time, and one of them contains some kernel modules. It might be a good idea to create a cut down version of your 'onboot.lst' file that only contains an entry of 'usb-serial-KERNEL'. That way it might become clear whether the first "pause" is HW related or more a consequence of the other work the system has to do.
• Have you got a large backup file that needs to be extracted? This might explain the second "pause", and could be tested by avoiding the restoration via the 'norestore' boot code.

Generally speaking I'd suggest to remove as many "tasks" from the list your system has to do and add more with subsequent tests, whilst taking note of the boot duration for each of these cases. That way it should become clear which one is the "culprit".

[SBor]

Thanks for the answers!

It might be more useful to take a bootchart, as it would show what is happening.

First I thought: cool, a newbie asks a question and the answer is: remaster and use a magic tool. Well, it was not as hard as it sounded ;-)
Analysis showed, that 30s is consumed by a "cp" that is called from extension sun-jre7. Without that I almost halfed the boot time, yiiihaaa!
A quick replacement with sun-jre (version 6) leads to a mount error message during boot ("Invalid argument", when trying to load this from AppBrowser)

[SBor]

A quick replacement with sun-jre (version 6) leads to a mount error message during boot ("Invalid argument", when trying to load this from AppBrowser)

Okay, for the record, the above mentioned mount error was a result of an incompletely downloaded jre extension. Shame on me. The jre version 6 starts equally slow, because of the same copy operation in the startup script that copies quite some files from the mounted file system to the ramdisk. I can only guess that this was done for runtime speed reasons. Is that common practice for extensions? Is there an easy way to reduce the compression of an extension just to try if my 533MHz CPU is the cause of the 30s delay of the copy operation?

[curaga]

Even though sun-jre.tcz has some 700 files, creating 700 symlinks in ram should hardly take that long. Are you sure it's not copied to ram (copy2fs)?

You can of course run the same copy command after boot and measure, too.

[SBor]

Look inside the extension! The startup script of the extension copies half of the directories after the framework already created symlinks for all files. I don't use the copy2fs feature. That won't work with X plus samba server plus java runtime in 256MB of RAM.

You can of course run the same copy command after boot and measure, too.

I did not try that yet, because I suspect the extraction out of the tcz-file to be the time killer, so I could not simply do the copy again after loading the extension, because I suspect the source to be in the Linux cache. So maybe, just mount it manually and than copy... Hmm....

[curaga]

Look inside the extension! The startup script of the extension copies half of the directories after the framework already created symlinks for all files.

I don't use Java. Glad you found the reason.

I trust Arslan in that the copying was required to make Java work. I'm afraid I can't help on whether you could make it work without.

No, forcing a copy to ram for any other reason than making things work is unheard of so far.