Sound advice. You might also investigate systemd, which makes it a little easier to start services in parallel and/or on demand rather than all at once.
b.g. On Apr 17, 2014 3:41 AM, "David Hicks" <[email protected]> wrote: > > Unsure what the specifics are for your system but I'd recommend attempting to install 'bootchart' (should be as simple as apt-get install boothart) and seeing what's using most of the time during boot, so you can figure out what it is you want to optimise. > > Another generally good idea would be to review all the services that are installed by default and see if you can remove any. You might not need them all and while each one may not have a huge impact on boot time, if you remove a few that you don't need you could see some improvement. > > > On Thu, Apr 17, 2014 at 5:28 AM, Divya Subramanian < [email protected]> wrote: >> >> Any other way of cutting down boot time? >> >> Regards, >> >> Divya Subramanian >> >> >> On Wed, Apr 16, 2014 at 7:10 PM, David Hicks <[email protected]> wrote: >>> >>> >> The initramfs isn't the source of the slowdown, unless you have a really huge one. >>> >>> It could be a part of it, though maybe not a massive part. On my hacked up NAS uboot takes a few seconds to copy the initramfs from onboard NAND into the system RAM before it launches the kernel. If you ditched ramfs you could cut those few seconds out. It's not masses I suppose.... >>> >>> >>> On Tue, Apr 15, 2014 at 5:35 PM, Bill Gatliff <[email protected]> wrote: >>>> >>>> >>>> On Fri, Apr 11, 2014 at 8:42 AM, David Hicks <[email protected]> wrote: >>>>> >>>>> I'm not exactly the foremost expert on this but ... my understanding is that the initramfs, or initrd or whatever it is, contains a bunch of useful things the kernel needs to boot the board fully. Primarily these include hardware driver modules needed by the kernel ahead of when the main filesystem becomes available. For instance disk controllers and filesystem drivers. >>>>> >>>>> One way to reduce the use of the initramfs/initrd is to build a kernel that has the drivers you need built into it rather than loaded as modules from the ramfs. You would need to build a custom kernel (relatively easy with debian already on the device and using make-kpkg) with the kernel config customised to achieve this. >>>>> >>>>> I have no idea how much this would speed up boot time, if at all. You also lose some of the other benefits of using an initramfs/initrd, which I'm having trouble remembering right now. (recovery shell? various scripts for mdadm/lve? stuff...) >>>> >>>> >>>> Actually, baking the necessary modules into the kernel rather than loading them from initramfs would speed things up quite a bit, especially if the modules are demand-loaded. Reasons include the fact that you'd be doing the linking at build-time on your fast PC, rather than at run-time on a slow(er) ARM core. >>>> >>>> The initramfs isn't the source of the slowdown, unless you have a really huge one. The bootloader already has to load the kernel, and having the filesystem in RAM at the same time will usually speed things along. At least until you have to scour the eMMC to find the final root filesystem, but there's no avoiding that really... >>>> >>>> Granted, you can put things into initramfs that DO slow you down: hardware probing, lack of parallelism, sleeps, lots of shell scripts, and so on. But the initramfs concept itself doesn't present any speed issues. >>>> >>>> I haven't looked at Debian's initramfs lately, since I tend to build my own. But since Debian favors generalism over performance (as they should), it wouldn't surprise me to see one built from the ordinary Debian tools that drags its feet a lot before going to the user prompt. >>>> >>>> >>>> b.g. >>>> -- >>>> Bill Gatliff >>>> [email protected] >>> >>> >> >
