Boot times measured in milliseconds, not minutes.

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

Boot times measured in milliseconds, not minutes.

#1 Post by technosaurus »

First, I will explain why it takes so damn long to get to a desktop to begin with.

Since there are so many different reasons, I will go over these in the order they typically occur.

Loading Kernel
Traditionally:
First the bootloader has to load up from its various stages, process the command line and pass the buck to (in our case) the kernel (with optional initrd image)

Better:
boot directly with EFI
boot directly with coreboot -- filo
problems - currently difficult to automate EFI for a generic system and coreboot is complex enough to remain in the embedded systems developer domain

Running Kernel
Traditionally:
This part is really bad. Most kernels contain all kinds of built in stuff that is unnecessary for initial bringup, but then have several modules inside of an initrd image that need to be modprobed etc... just to boot it up.

Better:
Only include the parts necessary to mount the desired partition and run X (these should be around 1MB) It is almost always a safe bet to compress the kernel with lzop the small decompression overhead is compensated by the reduced time it takes to read the smaller image.

Bringing Up System
Traditionally:
We already touched on the initrd/initramfs, with the root filesystem, but if that was all it did, it wouldn't be too bad. Unfortunately for the casual desktop user the whole bringup process also involves a lot of setup and daemon process starting. I won't go into these (upstart, systemd, sysv,...) because all of these are basically unnecessary

Better:
On our EFI boot partition we create an init that mounts a devtmpfs, devpts, sys and proc then runs our xinit

Bringing Up X
Traditionally:
xinit does a bunch of stuff: Xorg goes through a whole detection/config process, a display manager, some configuration apps and daemons begin running and a full desktop with window manager starts up while preloading a bunch of stuff.

Better:
option 1: instead of respawning gettys, etc... use our "init" to keep X + a wm running and use the already specified autostart to handle daemons and background processes
option 2: If you cannot boot straight to your rootfs using EFI, build a subset of busybox/toybox and the basic parts of X (a static xfbdev/Xvesa + jwm multicall binary is less than 300kb compressed) into an initmpfs (not a ramfs - see Rob Landley's patch) and use it to bootstrap the rest.

That's pretty much it. I oversimplified a lot of things especially the process of shifting boot time daemons into autostart and setting up EFI. None of the tasks are that difficult, its just that there are a lot of them and some are time intensive (I hate building the kernel on my slow machines)

I initially started examining this way back in 2011 with Xvesa, jwm and a subset of busybox in under 1MB including the cut-down kernel and extraneous filesystem stuff. Now I am convinced that xfbdev is a better solution than xvesa (portable to arm, mips, ...) but we really need a kernel patch to make the framebuffer boot without input into its highest supported resolution. (Xvesa has the same problem, but can be reinitialized to higher resolutions with xrandr)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#2 Post by Karl Godt »

Have only one machine that used efi and already scrapped it for grub .

Interesting read :
Also, don't forget to disable the "Tickless system".
:?:
- Puppy by default should be Tickless i think, have no kernel source right now to look into .
cp /usr/src/linux/arch/x86/boot/bzImage /boot/efi/EFI/boot/bootx64.efi
I remeber that efi partition being somewhat 15MB in size .. , probably needs to enlarge that efi partition and that probably would render OEM machines bootless in WindowsOS regards .

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#3 Post by Ted Dog »

Nope, the boot part on win8.0 is large enough to violate all the rule and boot frugal EFI directly, and yes its fast, like that, even if not planned. :P I think EFI loads the whole part into memory.

User avatar
veronicathecow
Posts: 559
Joined: Sat 21 Oct 2006, 09:41

#4 Post by veronicathecow »

Would be nice to see faster boot times.
I was thinking of just no modprobing (unless you request it at the second and subsequent boot times) to cover the addition of new hardware (perhaps hold down a key to invoke it during boot and have an option to rescan from desktop?)
Also searching for puppy files takes ages and should just use the last file with again a boot option to search on hold down of a key?
But if technosaurus way works then that's a much better and faster solution. I will follow this thread. Thanks.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#5 Post by mikeb »

If you want faster recent puppies get to know bash and dive into its boot wrappers....its more than the odd modprobe. The sub folder search is a good one to start with but there is so much more that benefits from attention.. I halved the boot time of lucid by simply script hacking without any noticeable loss of functionality....and I'm sure newer versions are even more spaghetti bound judging by the feedback on the form....
Wrapping cotton wool around a problem does not solve the problem...the world of windows demonstrates that one.

bananas

mike

User avatar
veronicathecow
Posts: 559
Joined: Sat 21 Oct 2006, 09:41

#6 Post by veronicathecow »

Hi Mikeb, any chance you could share your hacks and where the files are? Thanks

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#7 Post by technosaurus »

puppy's method (a union of readonly squashfs(s) and a writeable layer) should take a lot more time because it uses files on drives that have to be mounted 1st, yet it is on par with other mainstream distros. This is not a testament to how good puppy is (the init is a huge hack) but how poor the other implementations are. I am posting my notes and experiences improving the Linux experience here in case Iguleder, Ibidem, goingnuts, micko or other key players need them, because I will be venturing out on my own into BSDland and don't want the tricks to be lost.

The most important of the tricks can be observed in the 1Mb microsaurus image, but since then man things have occurred:
devtmpfs has gone mainstream,
the finit_module syscall has been added,
I discovered "readahead",
learned of the freedesktop autostart (and other) standards
others have refined the kernel parameters needed for booting without modprobing
and lots of other stuff I am forgetting, If you have a curiosity, just ask.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#8 Post by mikeb »

It does take a long time compared to how it could be...not much point in making technical improvements elsewhere if you have a dog of hacked script or 3 bogging things down...my initrd init is 25 k rather than the 68 of the original lucid...just one example.

Since your info in aimed more generally rather than for puppy perhaps my comments are a little redundant.
Hi Mikeb, any chance you could share your hacks and where the files are? Thanks
could do but it wouldn't be puppy (you can make windows safe and fast but then there are complaints that some really crappy function no longer exists...people want bad food even if ultimately it kills them) .... breaking away from someone else's restraints was the point of my comment to you and that in doing so significant changes can be made even at the scripting level. The chances are it would be right for you but to accommodate a wider audience takes significant testing. Without the backing of mainstream support you are on your own and all that entails.

mike

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#9 Post by greengeek »

technosaurus wrote: I will be venturing out on my own into BSDland and don't want the tricks to be lost..
I get a sad, sad feeling that there is a risk of good Linux brains turning their backs on puppy because maintaining the 'Puppy' way of doing things can be inefficient.

Is there any chance that a new 'microsaurus' or 'bootasaurus' or something similar could become a super-efficient bootstrap that would then allow a "puppy" sfs to be overlayed over the top???

Who wouldnt want an OS that allowed the machine to boot really quickly to cli, then if desired, continue super quickly to an efficent minimalist gui, then if desired, continue into a Puppy sfs? (which could be as efficient / inefficient or bloated as any regular puppy happens to be...)

eg: like a minimalist Linux running a puppy (including all its newbie assisting wizards) as an sfs or in a VM of some sort.
Is such a thing technically possible?
.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#10 Post by technosaurus »

I honestly don't think the typical user wants a console at all (terminal yes, but no "console") so I focus on x. I can put my custom init.c and x startup helpers on github, but someone would need to modify the puppy installer to take full advantage... I can help with that, but I 'd really like to get it working on bsd too so we have another kernel choice before jumping the gun with an installer gui.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Post Reply