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] >> > >
