Hello,

I'd like to know what would be the options to tweak Linux for having a very fast boot. As fast as MorphOS... Is that possible ?

I looked a bit on the web and found this article :
IBM - Boot Linux Faster

I also saw references to this :
Daemon tools - collection of tools for managing UNIX services

An other various ideas like :
- Tweaking the kernel to use specific hardware and services only
- Changing boot sequence in inittab/fstab to load things in background
- Setting RC_STARTUP_PARALLEL to "yes" in /etc/conf.d/rc file
- booting with the option quiet to avoid slow text displaying
- using uncompressed kernel ?
- using softwares like RTLinux (commercial)
or InitNG


Well, that's a start list and maybe some of you know more about this !
If so, that would be very intesting to share your knowledge in this thread with all PPC community

Thanks a lot...

While you can reduce the boot time by doing the things you mentioned, you cannot get Linux to boot as fast as MorphOS. When MorphOS becomes a complete OS, its boot time will lengthen as well.
There are all very good things to do. I'm going to try InitNG soon as it seems pretty stable now. I would also add:
- Compile more things into the kernel as modules
- Load only those modules you absolutely need to at boot time

For example, you can compile ASFS or VFAT filesystems into the kernel as modules, but you don't need to load the modules at boot time because they will load when you try to mount the drive.

_________________
--Aaron
Gentoo 2006.1
Kernel-2.6.17-no4

Well I've installed it under my Ubuntu yesterday (which takes at least 30 or 40s to boot) and did not notice a big change...
InitNG seems to be good for parallel things but I'm not sure it's as good on a single CPU.

I guess I should try it with a more tweakable distro like Gentoo.

Actually boot time of MorphOS probably won't get much longer than it is now...
A lot of the reason for the ultra-fast bootup time is do to the fact that MorphOS does not initialize the hardware.
This is also the reason that for instance if you temperarily sets a wrong screen-mode, and just reboots the Pegasos, it will not return to normal. the machine needs to be turned of for a minimum of about 10 seconds, that it will be reset by hardware...
This, and also that there is no memory-protection is the reason MorphOS can boot as fast as it can.

Best regards

Martin Frederiksen

Hi !

I put that thread back to the top of the forum because I would like to know if some folks succeeded in enhancing the boot time of Linux on Efika. If so, what are the best results ?

thx for your answers.

Note : Another thread about this subject was also opened here:
http://www.powerdeveloper.org/forums/vi ... .php?t=551

Not particularly.

One of the beauties of MorphOS is that it loads it's drivers for most of the system up only when required.

You start your system and then it loads the graphics to get a display, and input so you can move mouse and keyboard around.

Audio (AHI) isn't loaded until you play an audio file in an audio application which loads ahi.device. Network device (viarhine.device etc.) isn't used until you start the TCP/IP stack. Serial ports aren't touched until you use serial.device.

I booted my Efika just now, and it was 26 seconds (I have kernel timestamps turned on always :) before it had even finished most of the driver loading.

No amount of parallelising startup scripts fixes the fact that it took 26 seconds to even get to the startup scripts :)

Breaking system support into modules works, but it is not very generic; you also have to mess with initramfs and initrd tools to get the required-for-boot modules included in the kernel. Loading the huge kernel image is ALSO a slow point in the boot process (6 seconds on my Efika, that's a 6MB kernel+initrd), the CHRP boot loader and basic kernel init before drivers are even looked at is 12 seconds;
I managed to shave 5 seconds off boot time here by setting (on Debian), /etc/defaults/rcS option RAMRUN and RAMLOCK. Another few seconds by making my default '/bin/sh' use dash (Debian Ash Shell) instead of busybox or bash (which incur a loading time, bash is 800k and dash is barely over 100k..).

There is some work in Gentoo for getting bash 'resident' so that loading time goes away. I don't know the full details of it.

Having an uncompressed kernel really doesn't help much and I'm not sure 'quiet' really improves the time unless you are spewing to the serial port and have a LOT of data going to it.

Ubuntu have done some work on this (this is where I got the idea to use dash and RAMRUN, RAMLOCK) and they have some fairly good tools which trade memory usage (not so sure this is wise on Efika) for less disk access, and preloading data;

http://ubuntuforums.org/showthread.php?t=254263

There are a couple of entries here about preload and using dash;

http://bootdebian.blogspot.com/2006_06_01_archive.html

.. which is mostly work done here;

http://initscripts-ng.alioth.debian.org ... harts.html

Some of those will completely trash your system if you don't have correct tools in initramfs!!

There are tons of ways to do it, but a lot of them impact other system configurations. If your goal is to get to KDE fastest, then it may not match the guy who needs to startup as reasonably fast as possible and then have a lot of memory available (is it okay to boot really fast but use all the memory, but slow application start time by paging back and forth?)

There's also the ability - check out Giorgio's patch set - to put the 5200B into "deep sleep" mode. With a switch connected to the IrDA connector you can "suspend" your Efika to a low power state instead of turning it off. Then simply push the switch and your boot time is less than a few seconds..

_________________
Matt Sealey

Hi !
thx for answering...
I must admit that I'm a bit lost (there many things that can be tuned so what is the best at the end ?).
If I understood well you only succeded to boot from 26s to 20s ? Am I right ?

And with Gentoo ? Did you try something ?
And is there an optimized ready-to-install fast boot stage4 somewhere for users ? That would be a good base.

That's maybe a crazy idea but I was also wondering if there was a way/a tool that could help to dump all (or a big part) of the memory content after a startup and then restore it on the next boot (with a kind of big file reading / memcpy) ?
That would be a dirty trick to load all stuff as fast as possible, but I guess that's impossible...

Well Matt you analysis is incorrect ... (at least not very clear).

The first lines of printk have a zero timestamp because when they're printed the timing stuff is not ready so they don't have timing info.

When it starts at 12 s, it counts that _not_ from the time the kernel started but from when the CPU was actually booted. Which means the whole time that the firmware took is included in those 12 s, and the auto-boot time as well ...
To convice yourself, just wait 2 minutes at the OF prompt before booting linux you'll see the timing info starting around 120 ...

On my kernel, from the first printk with timing info (which is quite early in boot),
to the handoff to userspace, there is less than 1 second ...
Deactivating the serial console cuts around 1 s of my total boot time (from boot to login prompt).

Of course I also have most driver (except harddrive) as module, so they're autoloaded in // with the boot scripts ...

Sylvain

edit: Well, it depends what you mean by "chrp bootloader" in your original post ... I just want to insist that the time is display is from cpu power up.

@Sylvain: do you mean that it's better to use all drivers as modules ?

I'm going to check that...

Do I also need to set RC_STARTUP_PARALLEL to yes for that ?

@Matt: about TCP/IP stack. I think this has to be started at boot for DHCP no ?

Luca "lu_zero" also said that in the other thread :
"enlightenment .17 starts in less than a second no matter where you are (tested on my G4 1000, old amd athlon)."

So that might be interesting to use e17 too... I know Frostwork used this desktop manager for the e17ka live distrib.

I know that. This was from a cold boot to show that.. well.. 25% of my boot time is getting from firmware to kernel.

It's by default 5 seconds of 'auto-boot-timeout', anywhere from 2-6 seconds to get the kernel loaded, then the CHRP bootloader comes up, it seems to stall for a little bit (because it is further decompressing the kernel), and at the point it is actually giving me a time, it's 12 seconds in. That's only because my auto-boot-timeout is very small. Booting over USB is even slower (tooo long..). The parts of the output where the time is 0, do not matter as there isn't a great deal going on in terms of the kernel.

I don't think having an uncompressed kernel will help, as you will just trade off that time where it is decompressing, for accessing the disk in firmware instead.

Add another 30 and the system is booted and it is trying to load GDM (but I have no graphics, so it explodes, although I used to have it retarget to my laptop :)

You can knock 2 or 3 seconds off system boot, but you will NEVER get rid of the 12 seconds before the system starts initialising drivers. But seriously, is booting in only 40 seconds REALLY that much of a problem? I don't think MorphOS has EVER been that fast for me and gotten all my applications and toolbars and tweaks loaded.
No. It takes 26 seconds to get from press the reset button to the END of kernel timestamps and the start of /sbin/init output.

To finish booting and give me a login prompt, it's usually around 45 seconds. However before I tweaked it, it took around 55 (basically ln -s dash sh, RAMRUN=yes, RAMLOCK=yes, CONCURRENCY=shell, removed some useless startup scripts).

I ONLY tweaked it because I really hate it when Debian cleans up my disk for me every boot (what a waste of time for temporary files!) and see no point for temporary files on disk. I'm an old Amigan, so I am used to T: being in RAM: :)

Using dash instead of bash, I just like the concept of it. It helps when I boot off USB too, not to use the disk so much. The startup scripts, I removed the useless ones because it really annoys me that it starts scripts even though they're disabled or even not installed.

_________________
Matt Sealey