Boot time hack extravaganza time!

Con Franco , entre chiste y conversacion, comenzamos a hacer modificaciones sobre el arranque en un MSI Wind (arthur). Logramos pasar de unos insufribles 120s a 40s. En una tarde.

Use Ubuntu 8.10. Usable en casi todas las distros Debian based.

GUARNIN : Desde aqui estan en las suyas. Si deciden hacer los cochinos trucos que con Franco logramos cocinar, es problema de cada uno. Si la maquina les quedo en estado de PWN, o no arranca o que se yo, ya saben.

Bueh, terminando el disclaimer, manos a la obra!

Antes de partir, recordar : la mayoria de los arranques NO tuvieron autologin. Pero creo que el primer grafico ya lo habia implementado.

1. Viendo que anda mal en el arranque

   Para entender que anda lento, mal o insufrible, instalar bootchart y mirar los graficos del arranque.

   Este era arthur, ayer.

   

   OHMAIGASH. Insufrible, no?

   Follow up:

   Lo primero es identificar los procesos que se estan tomando su buen buen tiempo en iniciar.

   • Readahead-list
   • Udevd + modprobe

   Y una vez que se iniciaba la sesion:

   • Nautilus
   • trackerd
   • gnome-do
   • gconfd-2
   • dropboxd
   • tomboy

   No era lo que tenia en mente.

   Ahora, la aproximacion de cualquier mortal es "saquemos servicios y programas, y dejemos la crema!". No podia cepillarme nautilus. Ni tampoco gconf. No uso tomboy, ni gnome-do, ni trackerd.

   Antes de seguir, en una conversacion a la hora de almuerzo con Eduardo (Silva), me comento acerca de algunas opciones que podemos pasar al momento de montar un sistema de archivo para evitar redundancia estupida.

   Claro, eso si, varios programas (Mutt entre ellos) van a sufrir. Se los advierto.

   Hack : Modificar el /etc/fstab y modificar la opcion de montado desde

   UUID=LALA-LALALA-LALA-LALALA / ext3 defaults 0 0

   a

   UUID=LALA-LALALA-LALA-LALALA / ext3 noatime,nodiratime 0 0
   (gracias al tio Catril, que casi lo botan, por indicar el error!)

   No necesito saber cuando se leyo un archivo. Asi que puedo ocupar ese tiempo ocioso en mejorar el throughput del disco.

   Hack : Deshabilitar el arranque de los programas dentro de la sesion : trackerd, dropboxd, tomboy y sus amigos cercanos.

   Tiempo de mejora : arranque en 95 segs.

   
   

2. Hack: Hacer profiling de readahead.

   No me gusta readahead, pero que le voy a hacer.

   Para hacer profiling, solo agregar "profile" al arranque del kernel. Este de ahi estara un bueeeen rato tratando de determinar los archivos a leer para "precargarlos".

   Ahora, para un mejor deleite...

   HACK PELIGROSO : Habilitar profiling hasta la sesion.

   # rm /etc/rc2.d/S90stop-readahead

   Reiniciar la maquina (en modo profile) y una vez que ya tengan un terminal andando en su sesion de GNOME/KDE/wharenes,

   $ sudo /etc/init.d/stop-readahead start

   No se olviden de

   $ sudo ln -s /etc/init.d/stop-readahead /etc/rc2.d/S90stop-readahead

   

3. Problema : ahora readahead era el culpable que el arranque anduviera charcha.

   Casi 30 segundos de a~adido (pero la sesion de GNOME entraba por un tubo). No era lo que yo queria, esos 30 segundos los valen :-)

   Y que es lo que haria cualquier ser humano en esas condiciones? Quizas quitar algunas lineas del archivo...

   Pero lo que hice fue absolutamente mas descabellado : precargue TODO. 2340 lineas de entretencion en /etc/readahead/boot para el deleite del I/O.

   Eso, aunque no lo crean, redujo el arranque a 50s :-)

   

4. Reexaminemos. Los cuellos de botella, nuevamente, udevd y oh! alsa-utils y alsactl...

   Los necesitaremos?

   Hack cochino:
   $ sudo mv /sbin/alsactl /sbin/oldalsactl

   Alsa utils voy a dejarlo por cariño solamente.

   $ sudo mv /sbin/vol_id /sbin/oldvol_id

   Y cambiemos los UUID=LALA-LALALAA.... del /etc/fstab a /dev/XdDa (/dev/sda1, /dev/sda2...etc).

   El otro sospechoso era el modprobe de modules-init-tools. Demosle.

   # cp /etc/init.d/module-init-tools /etc/init.d/old.module-init-tools

   Y cambiar lo siguiente...

   if [ "$VERBOSE" != no ]; then
log_action_msg "Loading kernel module $module"
modprobe $module $args || true
else
modprobe $module $args > /dev/null 2>&1 || true
fi


   No estoy usando modo verbose asi que cambiemos eso a...

   
# aqui habia un if
modprobe $module $args &
# aqui habia un fi


   Y de pasadita, en /etc/init.d/readahead

   
if /sbin/start-stop-daemon --start --quiet \
--pidfile /var/run/readahead-list.bogus \
--startas /sbin/readahead-list -- -s /etc/readahead/boot; then
log_end_msg 0


   cambiarlo a

   
if /sbin/start-stop-daemon --start --quiet \
--background --renice -20 \
--pidfile /var/run/readahead-list.bogus \
--startas /sbin/readahead-list -- -s /etc/readahead/boot; then
log_end_msg 0


   Pa ra le li zar!

5. Por esas cojonazas razones que no me explico de la mania de mandar /dev/null a cada archivo importante...

   # cat /dev/null > /etc/readahead/boot

   Es que el arranque cambio a 45s! Weeeeeeee!!!

   

7. Hack intrepido : gdm a los 20s.

   Esto va a requerir MUCHA paciencia.

   Xorg detecta casi todo el hardware gracias a Hal. Ahora, si hal no esta andando, entonces ni se inmuten en hacer

   # rm /etc/rc2.d/S30gdm -f
# ln -s /etc/init.d/gdm /etc/rc2.d/S10gdm

   Por que a no ser que tengan absolutamente todo precargado o bien que el Spaghetti Monster los haya bendecido con su apendice tallarinistico, NO VAN A TENER NI MOUSE NI TECLADO

   Pero solo con tener una seccion en xorg.conf

   Section "ServerFlags"
Option "AllowEmptyInput" "off"
EndSection

   Y un poco de paciencia...

   

   GDM a los 20 segundos! EA!

   Aunque igual el tiempo no baja de los 45/50 segundos desde el arranque.

Cosas que aun le falta pulir al procesito este.

Uno, es que la cantidad de cochinadas que le tuve que hacer al sistema estan dentro del rango de la vandalizacion.

Los to-do's que me quedan:

• Udevd y la que lo vino a parir: toma malditos 15 segundos de empezar a meter modulos. Estoy pensando seriamente en tirarlos al arranque. O mejor aun, derecho al kernel. Solo que el wireless (RTL8180) va a quedar fuera. Lastima.
• Modprobe : El maldito toma mucho tiempo en hacer que? Mañana intentare correr un strace cuando intente subir modulos. Lo mas seguro es que se ponga a jugar con algunos /etc/ld.so.conf exoticos o /etc/ld.cache
• Xorg y sus amigos : el maldito SI que toma CPU. Solo quedaria quitar unas cosas por aqui por alla, pero el anticuado sistema de compilacion realmente me da miedo.

Señor Catril, ball's on your court.