= Casper = == Background == Casper and the boot process of live-cd images on ARM based hardware is currently very slow. As part of the blueprint UbuntuSpec:mobile-lucid-une-casper-speedup the process needed to be first investigated, profiled and conclusions drawn on that information. Time-stamping information was added to the ''call_scripts'' function in ''/usr/share/initramfs-tools/scripts/functions'' of a karmic live-cd, the date binary added, and the initramfs recreated using ARM/ModifyCasper. The same time-stamping was done with lucid alpha 1 with the same results. To see the conclusion of the investigations, [[https://wiki.ubuntu.com/ARM/CasperSpeedup#Conclusion|click here]]. == Initial Findings == The output from the initial time-stamping. === 5 seconds plus (aka, the culprits) === ||[[ARM/CasperSpeedup#10adduser|10adduser]]|| 26 seconds || ||[[ARM/CasperSpeedup#19keyboard|19keyboard]]|| 23 seconds || ||[[ARM/CasperSpeedup#24preseed|24preseed]]|| 11 seconds || ||[[ARM/CasperSpeedup#14locales|14locales]]|| 8 seconds || ||[[ARM/CasperSpeedup#45disable_guest_account|45disable_guest_account]]|| 8 seconds || === Two to 5 seconds (aka, should be looked at) === ||[[ARM/CasperSpeedup#22sslcert|22sslcert]]|| 5 seconds || ||[[ARM/CasperSpeedup#35fix_language_selection|35fix_language_selection]] || 4 seconds|| === One second or less (aka, no use optimizing) === ||10driver_updates|| ||20iso_scan|| ||30custom_installation|| ||01integrity_check|| ||05mountpoints|| ||05mountpoints_lupin|| ||10custom_installation|| ||10ntfs_3g|| ||12fstab|| ||13swap|| ||15autologin|| ||18hostname|| ||20xconfig|| ||22gnome_panel_data|| ||22screensaver|| ||22serialtty|| ||23etc_modules|| ||23networking|| ||25configure_init|| ||30accessibility|| ||31disable_update_notifier|| ||32disable_hibernation|| ||33enable_apport_crashes|| ||34disable_kde_services|| ||36disable_trackerd|| ||37kubuntu_netbook_installer_link|| ||40install_driver_updates|| ||41apt_cdrom|| ||42disable_apparmor|| ||43disable_updateinitramfs|| ||44pk_allow_ubuntu|| ||46disable_services|| ||47unr_ubiquity|| == More detailed analysis == === 10adduser === {{{ chroot /root debconf-communicate -fnoninteractive casper > /dev/null < /dev/null }}} Takes around 12 seconds. {{{ chroot /root debconf-communicate -fnoninteractive casper > /dev/null </dev/null took only 0.147s but the following code in debconf's File.pm (from init) debug "db $this->{name}" => "loading database"; while (! eof $this->{_fh}) { my ($item, $cache)=$this->{format}->read($this->{_fh}); $this->{cache}->{$item}=$cache; } takes around 3 seconds (incidentally its called twice, once timed at 1 second, the second time at 3 seconds). An strace confirms that the majority of time spent in some scripts that use debconf-communicate is loading this file. There are a couple of ways of working around this. One is to change the template.dat file format to a binary mmap-able sqlite db. Another is to simply only open the file once, keep its fd around (e.g. using a FIFO) and shut it down again at the end of casper meaning a total database load time of just four seconds. Yet another way would be to use stacked debconf databases to reduce the amount of data read to only the bare minimum that is needed. In other words, we have options. The debconf-communicate speed-up could improve live-cd load times significantly. With that in mind, an initial proof of concept will be produced to see what improvement this will make before identifying other area's to look at.