Última Actualización: 27 Sept 2005

El nivel de interés en Puppy crece a un ritmo sostenido, y mucha gente hace preguntas, en el foro de discusión, acerca de cuales son los secretos internos de Puppy.

Asique, decidí escribir esta página, explicando unos cuantos conceptos acerca de la estructura de Puppy, version 0.9.8+. Algo importante de entender es que Puppy es único. Desarrollé Puppy desde cero, archivo por archivo, por eso la arquitectura no está basada en ninguna otra distribución. Puppy ha evolucionado desde mis primeros experimentos hechos sobre "Como arrancar desde disco", a principios de 2003, hasta el increíble y exitoso fenómeno en que se ha convertido hoy en día.

Estoy usando Amaya para escribir esta página web, y usé Dia para crear las imagenes que estan más abajo. Pude haber escrito la página con Abiword, Composer o Bluefish, y pude haber creado las imagenes con Xpaint, Figurine, mtPaint o Sodipodi -- esta notablemente ámplia gama de aplicaciones, estan disponibles dentro de los insignificantes 50-60Mb de la compacta distribución Puppy. Aún así, si no alcanzara con las aplicaciones básicas, Puppy cuenta con los poderosos gestores de paquetes PupGet y DotPup, que ofrecen una gama cada día más diversa de aplicaciones que usted puede descargar e instalar con solo unos pocos cliqueos de su ratón. Incluso usted puede reconstruir su live-CD, incorporando solamente las aplicaciones de su preferencia.

De hecho, con el nuevo programa de re-masterizado de CD en Puppy 1.0.5, crear un live-cd o USB stick a su medida se ha convertido en una tarea sencillísima ... en fín, ese es otro tema!

El propósito principal de esta página es explicar de que forma Puppy difiere de otras distribuciones Linux; y el porque. Y consecuentemente, que cosas puede hacer, y cuales no, con Puppy, cosas que quizás puedan ser hechas, o no, con otras distribuciones. Fíjese en el siguiente diagrama:

El diagrama anterior muestra la estructura de Puppy cuando se lo arranca desde un live-CD

Cuando el live-CD arranca, vmlinuz, el kernel de Linux, se carga en memoria RAM, seguido por image.gz, que se carga en un 'ramdisk' (un sistema de archivos -filesystem- que reside totalmente en RAM). El sufijo ".gz" significa que el archivo está comprimido. El siguiente paso es descomprimirlo dentro del ramdisk para que se convierta en el sistema de archivos -filesystem- básico de Puppy, o sea, el directorio raíz '/' y todos los subdirectorios: /bin, /sbin, /lib, /dev, /tmp, etc.

Un objetivo fundamental de Puppy es que todo debe caber dentro del ramdisk, para de esa forma liberar la unidad de CD para que usted pueda usarla para algún otro propósito. Por otro lado, si todo reside en la RAM, el inicio y la ejecución de las aplicaciones es velocísimo.

Existe un problema, sin embargo, con que todo se aloje en la RAM: cuando la máquina se apaga, el contenido de la RAM se pierde. Asique lo que se necesita es alguna forma de salvar la configuración de usuario, e-mail, historial de páginas navegadas, y todo el resto. Lo que Puppy hace es, durante el arranque, busca una partición en disco adecuada, y si la encuentra, crea un archivo en ella llamado 'pup001'. De hecho el nombre del archivo puede ser cualquiera, yo arbitrariamente elegí 'pupxxx' donde 'xxx' es un número de 3 dígitos. Que sea un número de 3 dígitos tampoco tiene un sentido particular, excepto que actualmente estamos usando pup001 para el live-CD y para instalaciones USB.

pup001 es un único archivo, pero internamente es un sistema de archivos -filesystem- completo, de formato ext2. Después de crear este archivo, Puppy lo monta por medio del llamado dispositivo loopback, en el directorio /root. Este directorio /root es el directorio de usuario, su directorio, y es donde todas sus cosas personales son guardadas. Por eso, cuando usted apague la computadora y vuelva a encenderla, encontrará todo exactamente igual y a salvo.

Para ser estricto en la explicación del proceso de arranque, Puppy primero ha tenido que montar la partición del disco rígido como /mnt/home. Esto debe ser hecho antes de que Puppy pueda obtener acceso al filesystem pup001 y montarlo como /root. Esta es la razón de que usted vea 2 puntos de montaje en el diagrama.

Ha habido un gran interés en el Foro respecto de disponer de un live-CD que, sin hacer uso del disco rígido, tenga la posibilidad de almacenar toda la información de usuario. Por eso desarrollé el 'live-CD multisesión', introducido en la versión Puppy 1.0.0, que guarda en el CD original (RW) el contenido de /root, pudiendo de esa forma descartar completamente el archivo pup001. Este nuevo concepto se describe más abajo, siga leyendo! (nótese que la técnica multisesión no reemplaza al uso del archivo pup001, ámbos estaran disponibles.

Si usted está leyendo esta página por primera vez, estos detalles relacionados con usr_cram.fs pueden dejarlo algo confundido. Si es así, lea este párrafo muy por encima y salte al siguente encabezado. Siempre podrá volver más adelante para entender con mayor profundidad de que forma el archivo usr_cram.fs es colocado en memoria.

La mayoría de los archivos en Puppy, o en cualquier distribución Linux, residen en /usr, más aún, no hay necesidad, normalmente, de grabar nada en /usr (o sea, no es necesario editar, crear o eliminar archivos). Por eso el contenido de /usr puede ser comprimido, y eso es lo que Puppy hace. La totalidad del directorio /usr es comprimido en un único archivo llamado usr_cram.fs. Este archivo no se descomprime, se monta tal cual está en /usr por medio del llamado dispositivo loopback. La técnica específica no viene al caso ahora, pero es importante que usted esté al tanto que todo el directorio /usr está contenido en un único archivo, comprimido y de solo-lectura.

Usted puede notar que parte del diagrama anterior es de color anaranjado. Esto es para ilustrar los diferentes sitios donde el archivo usr_cram.fs puede ser localizado. Esos cuatro números, 1, 2, 3 y 4 corresponden al órden de búsqueda. Esto es, durante el arranque, Puppy primero trata de encontrar usr_cram.fs en el directorio "/" del ramdisk (lo que significaría que originalmente residía en image.gz). Segundo, Puppy tratará de buscar en /root (o sea dentro de pup001), tercero en /mnt/home (la partición de disco rígido) y finalmente en el CD.

Aún si Puppy llega hasta el cuarto paso, hará todo lo posible para no dejar usr_cram.fs en el CD. No queremos dejar usr_cram.fs en el CD. Realmente queremos copiarlo en el ramdisk o, de no ser posible, en el disco rígido. Si lo dejamos en el CD y lo montamos en /usr, Puppy va a ejecutar muy lento y la unidad de CD no va a estar disponible para otros propósitos. Asique Puppy va a verificar si hay suficiente RAM, y si la hay, copiará usr_cram.sf a "/" en el ramdisk para luego montarlo como /usr.

Actualización: Puppy 1.0.5 hace lo anterior con una pequeña diferencia. Es solo un pequeño detalle técnico, una desviación de lo anterior. usr_cram.fs ahora se monta en el directorio /.usr_cram y después se junta con /usr mediante UNIONFS. Si ahora no le vé el sentido, no se preocupe: el resultado final es exactamente el mismo.

Cuanta RAM es 'suficiente'? Puppy es más felíz en una computadora con, por lo menos 128M RAM. 128M es un buen tamaño, es suficiente para alojar a image.gz (descomprimido) y a usr_cram.fs en ramdisk. Al menos para el Puppy normal (tenemos algunos Puppys más gordos, particularmente Chubby Puppy que, en su disco de instalación de 90M, incluye OpenOffice, y necesita 256M para ejecutarse exclusivamente en RAM.

Pero, que pasa si su computadora tiene solamente 64M, 48M o incluso solo 32M de RAM? Bueno, usr_cram.fs no va a caber allí. Imagínese que image.gz descomprimido ocupa alrededor de 10M y usr_cram.fs 50M.

Puppy tiene, por así decir, una carta debajo de la manga. Si la computadora contiene una partición swap, Puppy automaticamente la usará, lo cual se hace para incrementar el espacio disponible en el ramdisk. Si usted alguna vez instaló otra distribución de Linux en su computadora, seguramente existirá una partición swap, que estará allí para ser usada por Puppy. Si su computadora tiene 128M de RAM, Puppy 0.9.8 usará 62 de esos Megabytes para el ramdisk (la versión 1.0.2+ usa 70M), sin embargo, si la computadora tiene una partición swap de, por ejemplo, 250M, entonces el tamaño del ramdisk se convierte en 62+250 = 312M!

Aún así, yo tomé una decisión respecto a la lógica de arranque de Puppy: solo copiar usr_cram.fs en ramdisk si hay, por lo menos, 62M de RAM física disponibles para el ramdisk. Por eso, en computadoras con memorias RAM menores que 128M, usr_cram.fs nunca será copiado en ramdisk, aún si existiera una partición swap.

Otra cosa para tener en cuenta es la relacionada con el órden de búsqueda, los 4 pasos referidos anteriormente. Cuando usted arranca Puppy desde el CD, si usted copia usr_cram.fs desde el CD (o desde "/") a /root (o sea, dentro de pup001), ese resulta ser el segundo lugar donde Puppy buscará la próxima vez que arranque. O si lo copia en "/" del disco rígido, que es el tercer lugar donde Puppy buscará. Asique, en una computadora con solo 32M RAM, usted puede arrancar desde el live-CD y tendrá la unidad de CD disponible para otros propósitos.

Sin embargo, computadoras con menos de 128M realmente necesitan una partición swap para que Puppy funcione apropiadamente. Aunque Puppy puede arrancar desde el live-CD en una computadora con solo 32M RAM, algunas de las aplicaciones requieren mayor memoria, Mozilla por ejemplo. Mozilla no puede ejecutar en una computadora con menos de 128M. De todas formas, como se mencionó antes, una partición swap aumenta el tamaño efectivo del ramdisk, asique usted puede lograr correr Mozilla en computadoras con muy poca RAM, aunque resultará más lento. Es una buena idea agregar un archivo swap, si usted dispone de algún espacio libre en el disco rígido.

Piense un poquito más en el asunto del órden de búsqueda... el #3 es interesante. Puppy buscará usr_cram.fs en el disco rígido, pero como llega ahí ese archivo? Si usted lo pone, estará allí, pero tambien si usted ejecuta el script install-to-hard-drive-option-1 (opción 1 de instalar en disco rígido).
...y, en ese caso, hay un problemita, ya que cuando usted arranque una nueva versión de Puppy desde el CD, Puppy encontrará ese viejo usr_cram.fs. Ay! nada bueno. Lo mismo pasará si usted pone usr_cram.fs en /root, para el caso.
Para resolver ese problema, Puppy aplica una técnica de verificar que ese usr_cram.fs es la versión correcta. Puppy verifica esto e ignora cualquier usr_cram.fs que encuentre y que tenga un número de versión incorrecto. Esta técnica es usada cuando usr_cram.fs es creado, el tamaño, en bytes, es registrado en /etc/sizeusrcram, y este dato es usado en el arranque para compararlo con el tamaño de usr_cram.fs.

La explicación anterior asume que /usr es de solo lectura, ya que lleva montado a usr_cram.fs comprimido. Sin embargo, la versión Puppy 1.0.1 cambió todo eso. Ahora /usr es de lectura/escritura. De nuevo: siga leyendo!

Un punto más importante acerca de esta arquitectura es que /usr es de solo lectura. Por eso, si usted descarga de internet un 'tarball' .tar.gz o un paquete RPM y quiere instalarlo en Puppy, no puede! Al menos, la mayoría de esos paquetes intentarán instalar parte de ellos en /usr.

Pero la versión 1.0.1 de Puppy ha revolucionado la administración de paquetes usando UNIONFS para hacer /usr de lectura-escritura. Cualquier archivo guardado en /usr es realmente guardado en /root/.usr, sin embargo, a los ojos del usuario, seguirán estando en /usr. La siguiente imagen lo explica:

"/root/.usr" es simplemente un directorio dentro de pup001 pero está montado en /usr, y las operaciones de escritura sobre /usr realmente van a parar a /root/.usr. Asique, como ve, dado que /root/.usr is realmente dentro de pup001, será guardado cuando finalize la sesión y nuevamente recuperado la próxima vez que Puppy arranque. (Je je, estoy dibujando lineas por todos lados: "esto se monta sobre esto otro, y esto otro sobre lo siguiente..." pero en la práctica es algo realmente simple!)

Un ventaja de tener /usr en modo lectura-escritura es que Puppy puede usar un sistema de administración de paquetes para instalarlos y removerlos. Estuve mirando por ahí, a ver que había disponible pero, como siempre, decidí reinventar la rueda, y el resultado es PupGet, un gestor de paquetes que incluye instalación, eliminación y verificación de dependencias.

PupGet ofrece los paquetes de la colección Puppy Unleashed. Todos esos paquetes estan disponibles para descarga, es solo cuestión de ir al menú Puppy, "Setup -> PupGet package manager", y seguir algunos simples pasos.

Todos los paquetes Unleashed estan disponibles en Internet, y PupGet puede descargarlos individualmente para instalarlos. Sin embargo, los desarrolladores Linux pueden crear sus propios live-CDs usando la colección Unleashed completa. El live-CD que usted está usando ahora, fué creado a partir de la colección Unleashed.

Puppy Unleashed le permite crear su propio Puppy, personalizado a partir de una colección de cientos de paquetes (aplicaciones). Para mayor información, vea La página de Puppy Unleashed.∞ (en Inglés)

Puppy 1.0.5. va aún más allá en la creación de un CD personalizado, con un programa llamado PCCC, o Puppy Custom CD Creator (Creador del CD Puppy personalizado). Este programa le permite usar su live-CD actual como punto de partida, y agregar o remover los paquetes que desee. PCCC está enlazado con el gestor de paquetes PupGet, y puede también mover al live-CD paquetes DotPup (Puppy tiene 2 sistemas de paquetes). PCCC es muchísimo más fácil de usar que de explicar!

Los drives USB de memorias Flash se han convertido en muy populares, y la capacidad mínima es de 128M, lo que equivale a cerca de 80 diskettes. Asique el diskette se está convirtiendo en historia y la mayoría de las computadoras en estos días pueden ser configuradas para arrancar desde USB, reemplazando la necesidad de un "disco de arranque" de emergencia (claro que también puede arrancar desde CD).

Sin embargo, tengo una anécdota al respecto. Un amigo mío compró una laptop Compaq nueva, un modelo más bien caro (Presario R3000), en octubre de 2004, y a mi me sorprendió que la configuración BIOS no tenía la opción de arrancar desde USB. Tenía la de "arrancar desde CD" pero no de USB. Eso es increíble y, sirva de advertencia a tener en cuenta si usted piensa en comprar una nueva computadora.

Otra advertencia. La mayoría de los drives Flash USB son genéricos, o sea, tienen una interfaz que está de acuerdo a la especificación estandar para almacenamiento masivo. Sin embargo hay algunos que no lo estan y eso probablemente le impida usarlos para arrancar un sistema operativo o usarlos para Linux. Hay una regla simple para elegir un drive Flash "normalizado": si en el paquete dice que funcionará con Windows XP sin necesitar un controlador instalado, entonces probablemente sea adecuado. De hecho, yo compré uno hace poco que ni siquiera venía con un CD y decía claramente en el paquete que funcionaría con XP y Linux sin ningún controlador especial.

Un drive Flash de 128M es ideal para Puppy. Tenga en cuenta que Puppy ocupa solamente entre 50-60M, asique cabe en un drive USB y quedan 70M libres para archivos personales. Exactamente: un sistema operativo completo, y también sus datos personales todo en un pequeño dispositivo facilmente transportable.

Sin embargo, hay una desventaja en la tecnología Flash, y es que no está designada para un ilimitado número de operaciones de escritura. O sea, usted puede guardar cosas en una memoria Flash cierta cantidad de veces. Leí en algún lugar que alguien había instalado Windows 95 en un drive Flash USB y después de cerca de 6 meses de uso, ya no pudo seguir grabando. La cantidad de operaciones de escritura que cada memoria puede realizar depende de la documentación que usted lea, digamos, tenga precaución con los números que manifiesta el fabricante, ya que ellos pueden decir algo así como 1.000.000 de ciclos de grabación, pero eso puede referirse a cada célula de memoria. Yo he visto magnitudes tan pequeñas como 50.000 grabaciones.

En fín, la buena noticia es que Puppy está especialmente diseñado para no escribir el drive Flash durante una sesión, y eso extiende enormemente su ciclo de vida. Fíjese en el siguiente diagrama:

Cuando Puppy arranca desde USB, los pasos son bastante parecidos a cuando lo hace desde el live-CD. El kernel vmlinuz es cargado en RAM, image.gz es descomprimido y cargado en el ramdisk.

Luego Puppy busca el archivo usr_cram.fs, primero en "/" del ramdisk, después en "/" de la partición USB. El primer caso se daría unicamente si Puppy fué creado con usr_cram.fs dentro de image.gz, lo cual no es lo normal. Asique optará por el segundo camino: Puppy encontrará usr_cram.fs en la partición USB y lo montará en /usr.

Pero Puppy intentará una optimización: si hay suficiente RAM, Puppy copiará usr_cram.fs en el ramdisk y después lo montará en /usr. Esto ralentizará el arranque un poquito, pero mejorará la velocidad después del arranque. Sin embargo, aún si Puppy deja usr_cram.fs en el drive USB y lo monta desde allí en /usr, eso no representa ningún problema, ya que /usr es de solo lectura. No habrá operaciones de escritura dentro de /usr asique la vida útil del drive Flash no está comprometida (la versión de Puppy 1.0.1 tiene UNIONFS lo que permite que /usr pueda ser de lectura-escritura. Pero todas las operaciones de escritura van en realidad a /root/.usr, que está localizado en el ramdisk, como se describe más abajo).

La primera vez que Puppy arranca desde USB, el archivo pup100 todavía no existe: Puppy tiene que crearlo. Puppy lo crea y lo monta directamenta /root, por medio de un dispositivo loopback.

Hasta ahora, la arquitectura es básicamente la misma que para el live-CD.

La vida útil del dispositivo Flash depende de las operaciones de escritura en /root, o sea, en pup100. Ese es su directorio home y las aplicaciones almacenan todo tipo de cosas ahí. Esto implicará una gran cantidad de operaciones de escritura. El kernel Linux almacena en memoria cache estas operaciones, pero aún así el cache es vaciado frecuentemente.

Una diferencia significativa ocurre la segunda vez que Puppy arranca desde el USB. Si hay suficiente RAM (recordando que el ramdisk puede también usar la partición swap si esta existe, asique el espacio disponible sería (la mitad) del tamaño de la RAM más el tamaño de la partición swap), entonces Puppy montará pup100 en el directorio /mnt/pupxxx y después copiará todos los archivos desde /mnt/pupxxx a /root.

De esa forma, una versión completa de pup100 estará en /root y no será necesario grabar al pup100 original. Cuando cierre el sistema, todos los archivos en /root son copiados nuevamente a /mnt/pupxxx actualizando, de esa manera pup100. Podríamos, en teoría, hacer copias de respaldo de pup100 en intervalos en vez de solo al cerrar la sesión, pero eso no está implementado en la versión actual de Puppy, para ser franco, casi nunca se me ha colgado Puppy y la única situación que podría causar la pérdida de información sería un corte de luz.

Puppy es extremadamente inteligente, y las optimizaciones descriptas más arriba son implementadas unicamente si existe RAM (+swap) suficiente. Si no hay RAM suficiente, bueno, entonces pup100 no podrá ser copiado en /root del ramdisk.

Para dar una idea de cuanto es "suficiente" RAM, a una computadora con 256M RAM le alcanza con un drive Flash de 128M. El archivo pup100 ocupará cerca de 60M y quedará RAM suficiente para que todo sea cargado en ramdisk. Si el drive Flash fuera de 256M el archivo pup100 alcanzaría 180M lo cual sería demasiado. Pero si la computadora tiene una partición swap, Puppy la usará automaticamente para aumentar el tamaño máximo utilizable del ramdisk.

Cualquiera sea el caso con su computadora, Puppy descubrirá la mejor configuración, en forma totalmente automática.

Como usted puede ver, Puppy consiste de solamente 4 archivos (de hecho es posible poner usr_cram.fs dentro de image.gz, con lo cual se reduciría a solamente 3 archivos, algunos sitios web de descarga pueden tener disponible tal configuración, la cual es conveniente para el caso de arrancar desde una red: solo tendría que preocuparse por 2 archivos, vmlinux e image.gz).

Para actualizar a la última versión de Puppy, solo necesita obtener el último vmlinuz, image.gz y usr_cram.fs. Actualizar es muy simple, pero con la versión 0.9.8 lo hice aún más simple ofreciendo una opción de actualización en los scripts de instalación. O sea, arranque el último live-CD y ejecute la instalación a USB, Zip o disco rígido, pero elija "actualizar" (update) en vez de "nueva instalación" (new installation).

...pero, es tan simple, que hasta puede hacerlo manualmente si quiere.

Puppy tiene un par de programas para copias de respaldo, incluyendo uno que yo escribí que solo guarda los archivos de /root que tengan cambios. Sin embargo, todos sus archivos personales o, en realidad, una fotografía completa del estado del sistema, reside en el archivo pup001 o pup100, asique usted puede grabar una instantanea del sistema simplemente copiando el archivo pup001/100. Después puede comprimirlo de la siguiente manera (asumiendo que la copia se llama pup100-12dec04):
Puppy does have a couple of archive programs, including one that I wrote that backs up only the changed files from /root each time. However, all your personal data, really, a snapshot of the entire the state of the system, is in the pup001 or pup100 file, so you can save a complete system snapshot just by making a copy of the pup001/100 file. Then compress it, like this (assuming the copy is named pup100-12dec04):

# gzip pup100-12dec04
y usted obtendrá un archivo llamado pup100-12dec04.gz. También puede usar "zip" o "bzip2", Puppy los tiene a ambos! Guarde ese archivo donde quiera.

Usted puede montar en cualquier momento un archivo pup100 previamente guardado y ver su contenido:

# losetup-FULL /dev/loop2 pup100-12dec04# mount -t ext2 /dev/loop2 /mnt/data
Usted también puede ver el contenido de pup100-12dec04 desde Windows usando el programa Explore2fs. También existe un controlador nativo para sistemas de archivo ext2, que corre en Windows NT/XP.

This is a most exciting new development. When I introduced this with v1.0.0, I thought it was a world first, but I discovered that the Morphix Linux people had been experimenting with a similar concept (but nowhere near as developed).

With v1.0.2, there is only one ISO file, for example puppy-1.0.2-mozilla.iso, and it becomes multisession if it is burnt that way when writing to CD. The concept here is that there is no pupxxx file at all! No hard drive required. Sessions are saved back to the CD, each session saved as a folder on the CD.

I won't draw another diagram... looking at the diagram at the top of this page, just remove the "pup001" box and the hard drive partition box, and there you have it. Folder /root is totally in ramdisk, and when Puppy boots the saved sessions are copied off the CD into /root in the ramdisk. The downside of this is that lots of RAM is required -- 256M at least, although it will use a Linux swap partition if it exists so 128M of RAM or less will work.

To read more: Puppy multisession live-CD introduction.∞

Esta sección está aún incompleta.

En los inicios de Puppy, escribí una página sobre los distintos pasos que dan lugar cuando Puppy arranca. Está bastante desactualizado, pero usted puede querer darle un vistazo: El proceso de arranque de Puppy Linux. (en Inglés)

Empezando a escribir esta sección...

Las primeras cosas en ocurrir son, el kernel Linux, archivo "vmlinuz" se carga en la RAM y el archivo "image.gz" se descomprime y luego se carga en /dev/ram0, que es un ramdisk de tamaño fijo de 11264K (incrementado a 12288K en Puppy 1.0.4+).

En el caso de que se trate de un Puppy de "imagen grande", o sea, con el archivo usr_cram.fs incluído en image.gz, tiene que estar especificado un parámetro para arranque del kernel "ramdisk_size=" con lo cual se especifica un tamaño adecuado para almacenar el archivo image.gz descomprimido, además del archivo usr_cram.fs y algún espacio libre. Por ejemplo:

ramdisk_size=63488

Para el caso de "imagen grande", /dev/ram0 será grande, en el ejemplo anterior 63488 Kbytes.

The program "/sbin/init" is executed. In the case of the "big image" Puppy, /sbin/init is just a link to /bin/busybox, as init is a program built-in to busybox. The normal situation though, is that /sbin/init is a shell script. Here it is:

#!/bin/sh
#v0.9.8 booting up in /dev/ram0, move root / to tmpfs...
INITARGS="`echo -n "$@" | sed -e 's/\/dev\/ram0/tmpfs/g'`"
PATH=/bin:/sbin

mount -t proc none /proc
mount -o remount,rw / #-n option not needed with busybox mount.

STARTUPFSSIZE=`cat /root0/.etc/ramdiskfssize` #currently set to 11264K (file gets updated below)
#specifying ram1 here as it isn't in use...
SIZERAMDISKM=`disktype /dev/ram1 | grep "Block device" | cut -f 4 -d " "`
SIZERAMDISKK=`expr $SIZERAMDISKM \* 1024`

#total ram, less any shared video...
PCRAMSIZE=`free | head -n 2 | tail -n 1 | tr -s " " | cut -f 3 -d " "`
#...note, busybox free output format different from standard free program.
if [ $PCRAMSIZE -gt 220000 ];then #256M
SIZEFILLK=`expr $PCRAMSIZE \/ 2` #half of ram.
else
if [ $PCRAMSIZE -gt 117000 ];then #128M
SIZEFILLK=67584 #63488
else
if [ $PCRAMSIZE -gt 60000 ];then #64M
SIZEFILLK=16384 #leaves about 7M free in f.s.
else
SIZEFILLK=11264 #only about 2M free in f.s.
fi
fi
fi
#precaution...
if [ $SIZEFILLK -lt $STARTUPFSSIZE ];then
SIZEFILLK=$STARTUPFSSIZE
fi

PHYSICALFILLK="$SIZEFILLK"

#want to know if there is a swap partition available...
SWAPPART=
SWAPINFO="`fdisk -l | grep "Linux swap" | head -n 1`"
if [ ! "$SWAPINFO" = ];then
#we can make the ramdisk real big now...
SWAPPART="`echo "$SWAPINFO" | cut -f 1 -d " "`"
SWAPSIZE="`fdisk -s $SWAPPART`"
#SWAPSIZE=`expr $SWAPSIZE \/ 2` #let's use half of the swap partition.
#...nah, grab the whole lot. Puppy can create a swap file later if reqd.
SIZEFILLK=`expr $SIZEFILLK + $SWAPSIZE`
#0.9.8... but have to delay swapon until rc.sysinit running... see below...
fi

mkdir /new_root
mount tmpfs /new_root -t tmpfs -o size=${SIZEFILLK}k;check_status $?
cp -a /bin /new_root/
cp -a /dev /new_root/
cp -a /etc /new_root/
cp -a /lib /new_root/
cp -a /mnt /new_root/
cp -a /root /new_root/
cp -a /root0 /new_root/
cp -a /sbin /new_root/
cp -a /usr /new_root/
cp -a /proc0 /new_root/proc
cp -a /var0 /new_root/var
mkdir /new_root/tmp
chmod 777 /new_root/tmp
sync

#0.9.8R2 rc.sysinit will start the swap partition running...
if [ ! "$SWAPPART" = "" ];then
echo -n "$SWAPPART" > /new_root/root0/.etc/swappartition1
fi

#i want to know the max size if not going to use the swap partition...
echo -n "$PHYSICALFILLK" > /new_root/root0/.etc/ramdiskphysicalfssize

echo -n "$SIZERAMDISKK" > /new_root/root0/.etc/ramdisksize
echo -n "$SIZEFILLK" > /new_root/root0/.etc/ramdiskfssize #size of f.s.
cat /etc/fstab | sed -e 's/\/dev\/ram0/tmpfs/g' > /new_root/etc/fstab
#if ever run install-to-hd script, /sbin/init must be normal symlink...
mv -f /new_root/sbin/init /new_root/sbin/init_ORIG
ln -s /bin/busybox /new_root/sbin/init

cd /new_root
mkdir old_root
umount /proc
#have code in /etc/rc.d/rc.sysinit which will umount /dev/ram0...
pivot_root . old_root
exec chroot . sh -c "exec /bin/busybox init $INITARGS" dev/console 2>&1

En breve, lo que este script hace es copiar todo el contenido de /dev/ram0 a un nuevo ramdisk tmpfs, lo que conlleva la ventaja de tener tamaño variable y puede usar una partición swap para crear a
In a nutshell, what this script does is copy all of /dev/ram0 to a new tmpfs ramdisk, which has the advantage of variable size and it can use a swap partition to create a very large effective size for the ramdisk. After the swap, /dev/ram0 is no longer being used.

Notice the very last line of the script. After the swap-over, "/bin/busybox init" is executed. This causes the init program built into Busybox to execute, the same as if /sbin/init was a link to /bin/busybox and init had been executed.

Próximamente...

(c)Copyright Barry Kauler 2005 Puppy Linux http://www.goosee.com/puppy∞