Febrero
2007
El tamaño si importa, parte 2, TCOS arrancando en 24 Mb
En otros artículos y como tarea pendiente en TCOS estoy intentando minimizar los requerimientos mínimos para que un equipo viejo pueda ser usado con TCOS.
Repasando los requerimientos de otros sistemas:
¿A qué viene todo esto?
Pues empiezo a preparar presupuestos de instalación, visito colegios con ordenadores prehistóricos y ya es cuestión de orgullo hacerlos funcionar (uno de esos es un Pentium 100 con 32 Mb)
Para evitar problemas y que el uso sea más sencillo he juntado (hace ya unas versiones) los modos de arranque TFTP y NFS, es decir, con un límite de 38 Mb (configurable en tcos.conf) y al principio del arranque decido si tengo memoria suficiente para descargar el usr comprimido o mejor monto NFS y hago la jaula.
He reducido radicalmente los tamaños del initramfs quedando «casi» en lo que ocupan los de debian:
Ahora:
Antes:
Tengo que decir que los dos initramfs tienen soporte para las mismas cosas (sonido, usb, discos locales, cdrom, todas las tarjetas de red...) Aún es posible minimizar más si en vez de dejar a mkinitramfs meter todos los módulos indicamos que módulos de red o placas vamos a usar...
El proceso de arranque sería así:
1.- Configurar en el DHCP los equipos que tengan menos de 38 Mb para que descarguen el initramfs NFS (creo que se hace con el option-string 128-129) si van a ser todos se deja por defecto en pxelinux.cfg/default.tpl y listo..
2.- El equipo arranca, detecta menos de 38 megas y monta por NFS un initramfs completo (con su /usr) hace chroot al nuevo punto de montaje y sigue como si nada.
3.- Los equipos con más de 38 Mb toman el initramfs normal descargan el usr.squashfs por tftp, lo montan y arrancan.
Sería la leche que pxelinux detectara el tamaño de ram y seleccionar el initramfs correcto así como el ramdisk_size pero creo que esto ya es pedir mucho... así que el que mezcle equipos demasido viejos tendrá que configurar un dhcpd.conf más complejo
Con todas estas mejoras he preparado mi vmware server (donde hago casi todas las pruebas) con una máquina virtual de 24 Mb de memoria, y he aquí:
He cerrado las X para hacer la captura de pantalla, pero las X funcionan y aún le sobra 1Mb. De esta forma no es usable ya que no tiene swap y a la mínima que se abra alguna ventana Xorg no tendrá memoria y seguramente se cierre o de un kernel panic. Para esto la mejor solución es usar los discos duros de los equipos para primero, ahorrar lo que vale una tarjeta de red buena que soporte PXE (arrancamos desde disco duro gracias al nuevo instalador de TCOS), y segundo poder swapear sin congestionar ni la red ni el servidor.
Después de sucesivas pruebas reduciendo RAM, puedo asegurar que 24 Mb es un buen límite (sin swap), porque aunque con 20 Mb también arrancan las Xorg, prácticamente no tiene ram suficiente y lo tiene que intentar varias veces... con 16 Mb se queda sin memoria antes de montar el NFS.
Resumiendo y como orgullo personal, he conseguido que el invento funcione con 24 Mb de memoria (el límite del procesador impondrá la velocidad de arranque) y que sea bastante sencillo el escalado/mezcla de distintos equipos en la misma red.
También hay que reconocer que un equipo pentium 200 con 24 Mb de ram funcione con los últimos kernel, las últimas Xorg, udev, un servidor de sonido como PulseAudio y algún daemon más, es un «milagro».
Otras mejoras que están por llegar al repositorio es la gestión de consolas (que funciona regular), es decir, ya no queda un shell de root abierto sino que pide usuario y contraseña (si se configura así), así como también una reducción radical del tiempo de carga (un equipo con 64 Mb carga en 5 seg menos) ya que he quitado las dependencias de los scripts de arranque ,como están ordenados por números no hace falta... así como la gestión del archivo pxelinux.cfg/default que ahora lo hace gentcos (configura la versión del kernel)
Iba a escribir un artículo nuevo pero creo que puedo ponerlo como coletilla de este que no ha quedado tan mal :P
Siguiendo con su constancia en el apoyo al software libre, la asociación GNUMAX vuelve a convocar las II Jornadas de Software Libre y Comunicaciones, que tendrán lugar los próximos 13 y 14 de Abril en Puerto del Rosario, Fuerteventura, Canarias.
Aún recuerdo lo bien que me acogieron en su anterior edición, y lo buena tierra y buena gente que es Fuerteventura y lo bien que se come. Un saludo Luis !!!
Espero poder escaparme a veros.
Repasando los requerimientos de otros sistemas:
- PXES: mínimo 32 Mb, recomendable 64 MB
- LTSP: En LTSP 5 32 Mb, conozco de instalaciones que con 16Mb o 24Mb funciona (usando swap en el servidor por la red) mínimos oficiales
- TCOS: hasta ahora los mínimos estaban en 32/64 Mb pero no eran demasiado precisos ni explicaban las condiciones.
¿A qué viene todo esto?
Pues empiezo a preparar presupuestos de instalación, visito colegios con ordenadores prehistóricos y ya es cuestión de orgullo hacerlos funcionar (uno de esos es un Pentium 100 con 32 Mb)
Para evitar problemas y que el uso sea más sencillo he juntado (hace ya unas versiones) los modos de arranque TFTP y NFS, es decir, con un límite de 38 Mb (configurable en tcos.conf) y al principio del arranque decido si tengo memoria suficiente para descargar el usr comprimido o mejor monto NFS y hago la jaula.
He reducido radicalmente los tamaños del initramfs quedando «casi» en lo que ocupan los de debian:
Ahora:
mariodebian:~$ du -ha /boot/initrd.img-2.6.17-2-486 /tftpboot/tcos/initramfs-2.6.17-2-486*
4,7M /boot/initrd.img-2.6.17-2-486
4,8M /tftpboot/tcos/initramfs-2.6.17-2-486
3,0M /tftpboot/tcos/initramfs-2.6.17-2-486-nfs
Antes:
FALBALA:~# du -ha /boot/initrd.img-2.6.17-2-486 /tftpboot/tcos/initramfs-2.6.17-2-486*He marcado en negrita, donde más trabajo he tenido (1,3 Mb menos es mucho en tan poco, casi el 30% menos)
4,4M /boot/initrd.img-2.6.17-2-486
6,1M /tftpboot/tcos/initramfs-2.6.17-2-486
3,0M /tftpboot/tcos/initramfs-2.6.17-2-486-nfs
Tengo que decir que los dos initramfs tienen soporte para las mismas cosas (sonido, usb, discos locales, cdrom, todas las tarjetas de red...) Aún es posible minimizar más si en vez de dejar a mkinitramfs meter todos los módulos indicamos que módulos de red o placas vamos a usar...
El proceso de arranque sería así:
1.- Configurar en el DHCP los equipos que tengan menos de 38 Mb para que descarguen el initramfs NFS (creo que se hace con el option-string 128-129) si van a ser todos se deja por defecto en pxelinux.cfg/default.tpl y listo..
2.- El equipo arranca, detecta menos de 38 megas y monta por NFS un initramfs completo (con su /usr) hace chroot al nuevo punto de montaje y sigue como si nada.
3.- Los equipos con más de 38 Mb toman el initramfs normal descargan el usr.squashfs por tftp, lo montan y arrancan.
Sería la leche que pxelinux detectara el tamaño de ram y seleccionar el initramfs correcto así como el ramdisk_size pero creo que esto ya es pedir mucho... así que el que mezcle equipos demasido viejos tendrá que configurar un dhcpd.conf más complejo
Con todas estas mejoras he preparado mi vmware server (donde hago casi todas las pruebas) con una máquina virtual de 24 Mb de memoria, y he aquí:
He cerrado las X para hacer la captura de pantalla, pero las X funcionan y aún le sobra 1Mb. De esta forma no es usable ya que no tiene swap y a la mínima que se abra alguna ventana Xorg no tendrá memoria y seguramente se cierre o de un kernel panic. Para esto la mejor solución es usar los discos duros de los equipos para primero, ahorrar lo que vale una tarjeta de red buena que soporte PXE (arrancamos desde disco duro gracias al nuevo instalador de TCOS), y segundo poder swapear sin congestionar ni la red ni el servidor.
Después de sucesivas pruebas reduciendo RAM, puedo asegurar que 24 Mb es un buen límite (sin swap), porque aunque con 20 Mb también arrancan las Xorg, prácticamente no tiene ram suficiente y lo tiene que intentar varias veces... con 16 Mb se queda sin memoria antes de montar el NFS.
Resumiendo y como orgullo personal, he conseguido que el invento funcione con 24 Mb de memoria (el límite del procesador impondrá la velocidad de arranque) y que sea bastante sencillo el escalado/mezcla de distintos equipos en la misma red.
También hay que reconocer que un equipo pentium 200 con 24 Mb de ram funcione con los últimos kernel, las últimas Xorg, udev, un servidor de sonido como PulseAudio y algún daemon más, es un «milagro».
Otras mejoras que están por llegar al repositorio es la gestión de consolas (que funciona regular), es decir, ya no queda un shell de root abierto sino que pide usuario y contraseña (si se configura así), así como también una reducción radical del tiempo de carga (un equipo con 64 Mb carga en 5 seg menos) ya que he quitado las dependencias de los scripts de arranque ,como están ordenados por números no hace falta... así como la gestión del archivo pxelinux.cfg/default que ahora lo hace gentcos (configura la versión del kernel)
Iba a escribir un artículo nuevo pero creo que puedo ponerlo como coletilla de este que no ha quedado tan mal :P
Siguiendo con su constancia en el apoyo al software libre, la asociación GNUMAX vuelve a convocar las II Jornadas de Software Libre y Comunicaciones, que tendrán lugar los próximos 13 y 14 de Abril en Puerto del Rosario, Fuerteventura, Canarias.
Aún recuerdo lo bien que me acogieron en su anterior edición, y lo buena tierra y buena gente que es Fuerteventura y lo bien que se come. Un saludo Luis !!!
Espero poder escaparme a veros.
