Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'arranque'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 11 resultados

  1. Existen numerosas aplicaciones libres para crear un Live booteable a partir de una imagen de instalación o Live de casi cualquier distribución. No obstante, llevar a cabo el proceso manualmente valiéndose de Grub directamente ofrece una serie de ventajas adicionales y puede resultar más útil y rápido. En primer lugar y como es obvio, necesitaremos un dispositivo USB con el que trabajar, en algún formato compatible con Grub, no es necesario que sea Fat32 salvo en el caso de querer un dispositivo de arranque UEFI. Ahí sí que nos hará falta una pequeña partición Fat al principio de la memoria del dispositivo. Instalando GRUB El proceso es bastante sencillo, bast instalar grub en el dispositivo USB mediante la orden grub-install, colocar las imágenes .iso dentro de éste, sin necesidad de descomprimirlas o modificarla en modo alguno e ir añadiendo entradas al grub.cfg para cada una de ellas. En primer lugar montamos el USB (que bien podemos hacerlo gráficamente desde cualquier administrador de archivos). Para el ejemplo no especificaré letra o número de partición, me limitaré a poner XY, ustedes mejor comprueben primero con fdisk -lCuál es la partición con la que van a trabajar. Y como punto de montaje utilizaré la ruta /media/USB. mount /dev/sdXY /media/USBCreamos un directorio boot en la raíz del dispositivo USB mkdir /media/USB/bootY en mi caso también crearé un directorio iso donde colocaré las imágenes que quiero utilizar. mkdir /media/USB/boot/iso BIOS Ahora toca instalar grub en ese dispositivo, indicando dónde está el directorio /boot que acabamos de crear: grub-install --target=i386-pc --recheck --boot-directory=/media/USB/boot /dev/sdX UEFI Para el arranque UEFI, la orden es un poco distinta: grub-install --target x86_64-efi --efi-directory /media/USB --boot-directory=/media/USB/boot --removable NOTA Si se pone un poco tonto por las etiquetas o el sistema de bloques podemos añadir la opción --force para que ignore las advertencias y continúe con el proceso. Híbrido BIOS + UEFI Por último, podemos crear un dispositívo híbrido, que pueda funcionar tanto con BIOS como con UEFI. Para eso necesitaremos pequeña partición, del al menos 1MB, al principio del disco, para el MBR. Una segunda partición FAT32 para los archivos de UEFI Y una tercera partición en cualquier formato soportado por grub, donde se encontrará las imágenes y los archivos de configuración. Podemos prescindir de esta tercera partición si lo que buscamos es utilizar una partición FAT32. En esa situación podríamos valernos de la misma partición que usamos para los archivos de UEFI. Como hemos dicho instalaremos ambas cosas. Primero indicaremos dónde está la partición UEFI y cuál es la partición de datos (si son la misma, lo pondremos duplicado). Recordemos que yo he creado un directorio de trabajo dentro de la partición de datos y lo he nombrado como boot. Será dentro de este último directorio donde estarán tanto los archivos de configuración de grub, como las imágenes iso No especificaremos particiones, sólo el directorio donde previamente tendremos montadas dichas particiones grub-install --target=x86_64-efi --efi-directory=/Directorio-montaje-UEFI --boot-directory=/Directorio_montaje_datos/boot --removable --recheckAhora le toca el turno a la contraparte BIOS y, para el MBR sí que especificaremos en qué unidad, no partición, unidad, queremos efectuar la instalación y, una vez más, el directorio de datos donde estarán las imágenes iso y los archivos de configuración y que yo he nombrado como boot: grub-install --target=i386-pc --boot-directory=/Directorio_montaje_datos/boot --recheck /dev/sdX Configurando GRUB Llegados a este punto ese dispositivo USB es booteable, pero al estar el grub.cfg vacío no podremos pasar de la pantalla de GRUB, así que vamos a crear el archivo y a añadir las distribuciones que queremos arrancar. Encabezando el archivo /media/USB/boot/grub/grub.cfg tendremos lo siguiente: El UUID del dispositivo (no el de la partición dentro de éste) podremos averiguarlo mediante el comando blkidBajo esta línea y sin ningún otro añadido podremos ir colocando las líneas de arranque de las diferentes imágenes .iso que hemos copiado dentro del directorio homónimo, repito, sin ningún tipo de modificación. La problemática de este punto viene en la forma de crear las imágenes Live o Instalación que tiene cada distribución, distintos sistemas de arranque, diferentes rutas para los archivos, distintos tipos de compresión... Entre los modos más comunes tenemos: Arch Debian Debian Live / GNU/Linux Vagos Fedora Linux Mint OpenSuse Si no damos con la tecla, en la wiki de ArchLinux tenemos una lista más completa de distribuciones y cómo se añaden en el Grub https://wiki.archlinux.org/index.php/Multiboot_USB_drive
  2. Hacía tiempo que quería escribir algo parecido, pero he de reconocer que me había olvidado por completo y hasta hoy no me ha venido de nuevo a la memoria y viendo que hay por ahí quien ya se me ha adelantado ¿Por qué no? El initrd (Init Ram Disc) o, en la actualidad, initramfs, es un sistema temporal de archivos utilizado durante el arranque del sistema y tiene como misión cargar en ram aquellos módulos y otros elementos necesarios para el arranque del sistema y que son necesarios antes de que haya sido montado el directorio raíz. Es decir, suministra al kernel aquellos módulos que no han sido incluido en él pero que son necesarios para poder arrancar el equipo. Sin embargo, puede ocurrir que las imágenes de arranque por defecto de un disco de instalación, en este ejemplo Debian, no tengan los módulos que necesitamos para que el sistema arranque o que no lo haga como es debido, así que no nos queda otra que remangarnos y poner manos a la obra No me voy a parar a describir el proceso de compilación de módulos del kernel, eso es otro tema, sólo la parte que corresponde a la modificación de la imagen y posterior "reempaquetado". COmpilar Kernels y módulos ya lo hemos tratado antes: Como era de esperar, necesitaremos la imagen o imágenes de arranque para poder trabajar con ellas. Lo habitual es que estén incluidas en la imagen iso de Debian, pero la versión más reciente y actualizada la encontraremos también en la ftp de Debian junto con dichas imágenes de instalación. En este caso me interesan las imágenes de arranque de una Debian Testing Amd64, por lo que me voy a buscar las imágenes del installer-amd64 actuales http://ftp.debian.org/debian/dists/testing/main/installer-amd64/current/images/ Vemos que aquí tenemos 3 opciones distintas Neetbot Cdrom Hd-media Depende de la imagen de instalación que queramos modificar, nos decantaremos por una o por otra. Yo me iré a por la Netboot, que me hace ilusión axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz axel http://ftp.de.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux Vemos que me he descargado ambas, tanto la imagen de Linux como la initrd.img Descomprimirla para trabajar con ella no requerirá demasiado esfuerzo, pero puede no resultar tan intuitivo como cabría esperar, ya que se trata de una archivo cpio comprimido y teniendo en cuenta que nos va a descomprimir un gran número de directorios separados, lo mejor que podemos hacer es trabajar dentro de una carpeta aislada para no volvernos locos después. mkdir initrd cp initrd.gz initrd cd initrd gzip -cd initrd.gz | cpio -id El resultado de descomprimir la imagen será parecido al directorio raíz de un sistema instalado root@Shiba:/home/shiba/initrd# ls -la total 24240 drwxr-xr-x 17 shiba shiba 4096 abr 21 12:35 . drwxr-xr-x 36 shiba shiba 24576 abr 21 12:34 .. drwxr-xr-x 2 root root 4096 abr 21 12:35 bin drwxr-xr-x 2 root root 4096 abr 21 12:36 dev drwxr-xr-x 12 root root 4096 abr 21 12:35 etc -rwxr-xr-x 1 shiba shiba 456 abr 21 12:35 init drwxr-xr-x 2 root root 4096 abr 21 12:35 initrd -rw-r--r-- 1 shiba shiba 24719513 abr 21 12:34 initrd.gz drwxr-xr-x 14 root root 4096 abr 21 12:35 lib drwxrwxr-x 2 root root 4096 abr 21 12:35 lib64 drwxr-xr-x 2 root root 4096 abr 21 12:35 media drwxr-xr-x 2 root root 4096 abr 21 12:35 mnt drwxr-xr-x 2 root root 4096 abr 21 12:35 proc drwxr-xr-x 2 root root 4096 abr 21 12:35 run drwxr-xr-x 2 root root 4096 abr 21 12:35 sbin drwxr-xr-x 2 root root 4096 abr 21 12:35 sys drwxrwxr-x 2 root root 4096 abr 21 12:35 tmp drwxrwxr-x 6 root root 4096 abr 21 12:35 usr drwxrwxr-x 6 root root 4096 abr 21 12:35 var En este punto ya estaríamos en disposición de compilar los módulos que necesitamos incluir y colocarlos en los directorios correspondientes, que como cualquier sistemas debería ser /lib/modules/Versión-arquitectura/kernel. Eso sí, tengamos en cuenta precisamente lo que he marcado en rojo, la versión y arquitectura del kernel en el que está basado la imagen. Por ejemplo, sustituir el módulo ath9k para una tarjeta wifi muy nueva que blablabla no nos interesa la historia... root@Shiba:/lib/modules# find . -name ath9k.ko ./4.9.0-1-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko ./4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Pues compilamos por separado la versión funcional del módulo y lo sustituimos ahí para que luego sea cargado por el instalador. Así de sencillo cp ath9k.ko ~/initrd/lib/modules/4.9.0-2-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko Puede ocurrir y ocurre que cuando nos enfrentamos a la tarea de compilar un módulo para una versión de Linux concreta, el sistema desde el que lo hacemos trabaja con otra diferente y las cosas se ponen un poco complicadas. Una forma un poco bruta pero funcional de lidiar con esto e modificar el archivo make para modifica o añadir la opción de compilar para la versión concreta a la que apuntamos: Si no se trata de sustituir sino de incluir un módulo que no está incluido en la imagen initrd original, el proceso es idéntico, copiaríamos el módulo en el lugar que le correspondería dentro de /lib/modules, creando los directorios necesarios, pero tendríamos también que modificar el archivo init para que sea tenido en cuenta y cargado durante el arranque. Dicho archivo lo encontraremos en lo que sería el directorio raíz de la imagen initrd, en mi caso: root@Shiba:/home/shiba/initrd# nano init #!/bin/sh -e # used for initramfs export PATH . /lib/debian-installer/init-debug debugshell "just booted" mount /run mkdir -p /run/lock mount /proc mount /sys /lib/debian-installer/start-udev init='/bin/busybox init' for i in $(cat /proc/cmdline); do case $i in init=/init|init=init) # Avoid endless loop : ;; init=*) init=${i#init=} ;; noshell) sed -i '/^tty[23]/s/^/#/' /etc/inittab ;; esac done debugshell "before init" exec $init Y no nos complicamos en absoluto, simplemente cargamos dicho módulo, con la ruta recién creada bien definida, haciendo uso de modprobe Pero como ya he dicho, mi intención es no pararme a describir el proceso de compilar un módulo para el kernel sino otros menesteres y ya que estoy metido en faena y era una tarea que tenía pendiente, voy a modificar los banners que se muestran en el instalador de Debian para ajustarlos a GNU/Linux Vagos y que todo se vea más bonito ¿Qué les parece? Que por cierto, se encuentra dentro del directorio install o install-arquitectura y ya que los banners que quiero cambiar son para la versión gráfica, será la imagen initrd GTK, la otra es para el modo texto. Y sí, así de complicado es esto Una vez descomprimida, para encontrar los banners del instalador debemos mirar dentro de /usr/share/graphics y sustituirlos por los que queremos incluir con el nombre de logo_debian.png o logo_debian_dark.png, depende de si luego fijamos el tema claro u oscuro Los he hecho deprisa y corriendo, tampoco se pongan muy exigentes Evidentemente, los temas gtk2 los encontraremos, como es de esperar, en /usr/share/themes y por defecto habrán dos, Clearlooks y Dark. Quien quiera ponerse con el aspecto de la ventana del instalador, tiene vía libre para modificar los archivos gtrkc como si no hubiera mañana para que luzca como mejor le parezca. Yo me limitaré a poner el oscuro por defecto y poco más, que saben que a mí las cuestiones de personalización no me atraen mucho que digamos Y una vez nos hayamos quedado a gusto añadiendo y modificando módulos y poniendo paras arriba el instalador ha llegado la hora de volver a comprimir la imagen de arranque para incluirla en la imagen iso de instalación de Debian. En definitiva, comprimamos la imagen initrd que es a lo que venimos find . | cpio -o -H newc | gzip > ../initrd.gz Y reempaquetamos la imagen iso de instalación de Debian, que también está perfectamente descrito en el foro, as que no me hagan repetirme Si no la he cagado demasiado ahora, cuando arranque la imagen de instalación de Debian, se cargarán los banners y el tema que he definido en la imagen de arranque y el instalador de Debian que dará precioso y cuco O bueno... que conste yo ya avisé que las cuestiones de personalización no eran precisamente mi fuerte Vamos a intentar arreglarlo como buenamente se pueda, pero no prometo nada
  3. Entre las ventajas de Systemd, implantado ya en algunas distribuciones y a punto de serlo en muchas otras, es la posibilidad de analizar y optimizar el arranque mediante las propias herramientas del propio systemd. Analizando el arranque Las órdenes que utilizaremos para realizar los análisis son todas las relacionadas con: systemd-analyze time Como ven, es bastante obvia su función y es fácil de recordar. De hecho, si no especificáramos nada, por defecto se ejecutaría la orden con la misma opción un "time" systemd-analyze Si la ejecutamos tal cual, sin ninguna otra opción nos devolverá una estimación (muy precisa) del tiempo que emplearía el sistema en arrancar con la configuración actual, diferenciando de manera clara y por separado el tiempo correspondiente al kernel en sí y al espacio de usuario: root@Shiba87:/home/shiba# systemd-analyze Startup finished in 3.315s (kernel) + 13.375s (userspace) = 16.691s Ahora que sabemos cuál es nuestro tiempo de arranque, podemos empezar a trabajar para optimizarlo y/o reducirlo haciendo uso del resto de opciones de systemd-analyze y, por supuesto, systemctl. Empezamos por pedirle una lista detallada de todos los servicios que se inician al arrancar el sistema y su impacto en el tiempo total de arranque: systemd-analyze blame Ahora la respuesta será mucho más extensa y concisa root@Shiba87:/home/shiba# systemd-analyze blame 11.440s systemd-fsck-root.service 1.108s keyboard-setup.service 1.069s sys-kernel-debug.mount 1.068s dev-mqueue.mount 1.067s dev-hugepages.mount 830ms systemd-udevd.service 762ms systemd-udev-trigger.service 684ms systemd-tmpfiles-setup-dev.service 408ms systemd-modules-load.service 404ms systemd-sysctl.service 355ms vboxdrv.service 247ms home.mount 124ms cron.service 111ms systemd-readahead-replay.service 95ms systemd-update-utmp-runlevel.service 85ms console-setup.service 77ms systemd-tmpfiles-clean.service 72ms systemd-remount-fs.service 52ms networking.service [...] O podemos centrarnos específicamente en los más lentos: systemd-analyze blame | head Nos quedaría sólo con los tiempos de cabeza, es decir, los más lentos root@Shiba87:/home/shiba# systemd-analyze blame | head 11.440s systemd-fsck-root.service 1.108s keyboard-setup.service 1.069s sys-kernel-debug.mount 1.068s dev-mqueue.mount 1.067s dev-hugepages.mount 830ms systemd-udevd.service 762ms systemd-udev-trigger.service 684ms systemd-tmpfiles-setup-dev.service 408ms systemd-modules-load.service 404ms systemd-sysctl.service También podemos centrarnos en los puntos "críticos" systemd-analyze critical-chain Y que nos devuelva una estructura clara y en orden de todos ellos. root@Shiba87:/home/shiba# systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @13.279s └─multi-user.target @13.278s └─vboxweb-service.service @13.275s +2ms └─vboxdrv.service @12.918s +355ms └─basic.target @12.916s └─sockets.target @12.916s └─dbus.socket @12.915s └─sysinit.target @12.914s └─console-setup.service @12.828s +85ms └─kbd.service @12.818s +8ms └─remote-fs.target @12.817s └─local-fs.target @12.816s └─home.mount @12.568s +247ms └─local-fs-pre.target @12.270s └─systemd-remount-fs.service @12.197s +72ms └─keyboard-setup.service @2.165s +1.108s └─systemd-udevd.service @1.334s +830ms └─systemd-tmpfiles-setup-dev.service @648ms +684ms └─systemd-journald.socket @645ms └─-.mount @630ms Otras opciones interesantes son plot y dot, que nos permiten realizar gráficos con toda la información anterior para que nos sea más sencillo procesarla de una manera más "visual". El gráfico será devuelto en forma de imagen svg, así que a menos que queramos ver una enorme lista de puntos uno tras otros, tendremos que indicar también el archivo de destino donde irán a parar los datos: systemd-analyze plot >> archivo-grafico.svg El resultado es una imagen gigantesca con todos los servicios, sus tiempos y una serie de indicaciones que nos serán muy útiles para analizar los datos de systemd Analyze Para el diagrama de puntos tendremos que ser incluso más específicos a la hora de crear el archivo svg y necesitaremos hacer uso de las herramientas del paquete graphviz systemd-analyze dot | dot -Tsvg > Archivo-diagrama.svg El resultado es... bueno, difícil de describir con palabras Como ven tenemos un diagrama muy complejo de todos los servicios y las dependencias entre ellos, el orden que ocupan... en fin, una maraña de información muy muy completa Para quienes quieran profundizar más en las herramientas de análisis, toda la información se encuentra en las Wikis oficiales y en las de muchas distribuciones http://www.freedesktop.org/software/systemd/man/systemd-analyze.html Optimizando el Arranque Una vez que tengamos una idea clara de cómo es la secuencia de arranque de nuestro sistema, podemos ponernos manos a la obra para optimizarla. Habilitando/deshabilitando servicios Aunque no era mi intención en cuanto a métodos de optimización empezaré por lo más obvio y que seguramente todos tenemos ahora mismo rondando por nuestra cabeza, que viene siendo deshabilitar directamente algunos servicios que no necesitamos. Esto es bastante sencillo, simplemente elegiremos aquellos demonios de la lista que nos ha devuelto el systemd-analyze que no queremos que sean cargados y, mediante el uso de systemctl, nos desharemos de ellos systemctl disable demonio.service O, si por el contrario quisiéramos realizar el proceso inverso, es decir, habilitar un servicio systemctl enable demonio.service Así con cada uno de los demonios con los que trabajemos. Readahead Pero no es eso de lo que venía a hablar aquí, sino de otras formas de optimizar el arranque, como puede ser readahead. Algo tan sencillo como systemctl enable systemd-readahead-collect systemd-readahead-replay nos permitirá optimizar de manera sensible el arranque de nuestro sistema. Preload Incluido en los repositorios de algunas distribuciones, nos permitirá realizar una análisis de las funciones y demonios más utilizados en el sistema para cargarlos antes de necesitarlos, lo que redundará en una mejor respuesta del sistema y esto a su vez, en un arranque más agilizado. Para los que no podemos instalar preload desde repositorios, el proceso para activarlo sería el siguiente: wget http://optimate.dl.sourceforge.net/project/preload/preload/0.6.4/preload-0.6.4.tar.gz tar -xfvz preload*.tar.gz cd preload* ./configure make make install Tras la instalación, habilitamos el servicio y lo ponemos en marcha: systemctl start preload.service systemctl enable preload.service Prelink Sólo nos queda hablar de prelink, igualmente en respositorios de muchas distribuciones y que nos permitirá agilizar no sólo el arranque sino la ejecución de muchas aplicaciones al realizar enlaces entre binarios y librerías o más bien "pre-enlaces", acelerando la ejecución de las mismas. una vez instalado el paquete, la primera vez ejecutaremos directamente prelink -afmR Y le dejaremos obrar su magia. En ocasiones posteriores, como las librerías y aplicaciones cambian, se actualizan, se instalan nuevas, se desinstalan antiguas, etc, configuraremos Prelink para que busque cambios y se ejecute de forma periódica. Editamos el archivo /etc/default/prelink cambiando la línea: PRELINKING=no por PRELINKING=yes más abajo tendremos las opciones de chequeo: PRELINK_FULL_TIME_INTERVAL= Y de ejecución forzada en caso de no haberse encontrado ningún cambio en las librerías del sistema PRELINK_NONRPM_CHECK_INTERVAL= El número que acompaña a dichas opciones representa los días que pasarán entre un chequeo/ejecución y la siguiente UPower UPower es un demonio, un API, y un conjunto de herramientas de línea de comandos. Cada fuente de poder del sistema es representada como un dispositivo, sin importar que sea o no un dispositivo físico. La administración realizada por este servicio consigue que durante el arranque las unidades se inicien y sincronicen con DBus de manera más eficiente, redundando en un arranque más rápido. Aunque se puede configurar de multitud de maneras diferentes según lo que necesitemos, en principio la configuración básica es más que suficiente, basta con instalar el paquete upower y habilitar el servicio systemctl enable upower Montar/chequear particiones "secundarias" tras el arranque Una de las cosas que más puede demorar el arranque son las tareas llevadas a cabo por fsck y mount. Con el objetivo de aligerar estos procesos podemos indicar como opción en nuestro fstab que aquellas particiones que no están estrictamente necesarias para el arranque sean montadas/montada después de éste, al acceder por primera vez a ellas. Particiones como /home o algunas que hemos creado para temas concretos, discos secundarios, etc. Especialmente aquellas que no es seguro que vayamos a utilizar y, por tanto, no vale la pena estar cargándolas y revisándolas continuamente cada vez que arrancamos el equipo. En el caso concreto de /home, permitirá que otros servicios no dependientes de éste sean cargados durante el arranque antes y durante el montaje/checkeo del propio home Las opciones a las que nos referimos son: noauto, que es la opción habitual para indicar que no se monte dicha partición de manera automática x-systemd.automount, que indica que no va a ser montada ni chequeada durante el arranque sino cuando se demande. Ejemplo Bootchart Por último, a modo de curiosidad, otro proceso que antes realizamos de manera manual, pero que también podemos realizar de manera automática. Gracias al servicio bootchart lograremos crear un gráfico de nuestra secuencia de arranque. Para eso, a la línea del kernel de nuestro grub habrá que añadir las siguientes opciones initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart Y habilitar el servicio bootchart, por su puesto. systemctl enable bootchart
  4. Hola a todos. Por motivos llaborales, tengo que trabajar en un ordenador que tiene windows 8.1 instalado. Para estar a gusto he conseguido un hdd en el que he instalado debian testing, con tres particiones (/, swap y home). He probado en varios ordenadores diferentes (linux, y windows xp y 7), y en todos me reconoce el disco y arranco desde debian, pero en w8 no me reconoce nada. he probado saliendo de UEFI, con UEFI y de todas loas maneras posibles (por supuesto, arranque rápido deshabilitado). He visto que w8 no me reconoce el disco, ya que no aparece montadol al insertarlo, pero sí que aparece como dispositivo extraíble. Al buscar soluciones, me han dicho que no tiene letra de unidad asignada (C:, D:, ...). He probado a asignársela a mano y no me ha dejado. Tampoco borrando los drivers e insertando el disco de nuevo. No sé qué tengo que hacer para conseguir que w8 me reconozca el hdd, y poder trabajar con debian. A lo mejor tengo que crea la partición /boot separada en él, e instalar ahí un cargador de arranque. Si es eso, pòr favor, indicadme cómo hacerlo 8si es posible, sin reinstalar el disco hdd). Muchas gracias a todos.
  5. Estoy planeando montar mi pc en un cajón/mueble, algo de modding barato.... El caso es que quiero tener un w7 para jugar y no quiero hacer particiones, así que se me ha ocurrido poner 3 hdd... - Windows 7 - Linux Mint - Datos comunes (aunque sólo me inyeresa en linux) Como se configuraría GRUB?? soy totalmente analfabeto en ésos temas.... Quiero que arranque Mint por defecto y supongo que todo limpio, ambos SO limpios y formateados...
  6. Tenía un dual trial? boot con Debian, Linux Mint y Windows. Los otros días decidí cambiar a Linux Mint por otro Debian, entonces ahora tengo dos Debian y un Windows El problema que tuve es que cuando inicié de nuevo en el Debian viejo que ya estaba instalado veo que me aparece un mensaje: A start job is running for deb-disk-by/[Acá un codigo largo] [Acá un contador de tiempo] Tenía un contador de tiempo que me hacía esperar un minuto y medio, y eso me retrasaba mucho el arranque Buscando un poco encontré que mi problema era que cuando cambié Linux Mint por Debian decidí compartir la particion de intercambio (swap) y se cambió el UUID de esa partición. El UUID sería algo así como un código que identifica a la partición Entonces el Debian que ya estaba instalado es como que no encontraba la swap Para ver si el problema es ese uno puede abrir una terminal y ver qué es lo que tiene el archivo /etc/fstab, que se vería algo así: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a ┏ # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sdb1 during installation UUID=c05302c7-f6cc-4485-94fa-c561892b367c / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda1 during installation ┃ UUID=7E48-14F9 /boot/efi vfat defaults 0 1 ┃ # swap was on /dev/sda5 during installation ┗━┓ UUID=7f810102-c3a0-488b-8c6d-88903bb5a48a none swap sw 0 0 ┃ /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 ┃ /dev/sdc1 /media/usb0 auto rw,user,noauto 0 0 Ahí dice cual es el UUID del swap, que sería el 7f810102-c3a0-488b-8c6d-88903bb5a48a Ese es el UUID que busca la PC al iniciarse, para ver el verdadero UUID de la swap hay que usar el comando sudo blkid que muestra algo como: /dev/sda1: LABEL="ESP" UUID="7E48-14F9" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d5510176-8b7f-4843-a706-dff4ecd44d19" /dev/sda2: PARTLABEL="Microsoft reserved partition" PARTUUID="55ee9231-98f2-48bd-9c17-0a49ba76c6cf" /dev/sda3: LABEL="windows" UUID="7A24D09024D050AD" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="806d1925-250c-4556-9385-7de1bd6ca7bb" /dev/sda4: LABEL="datos" UUID="58d66e82-3832-4edc-a62f-8f93c8bd05f8" TYPE="ext4" PARTLABEL="datos" PARTUUID="2894b2d8-cb16-44ec-81f1-483e82594883" /dev/sda5: UUID="3550194e-bce5-43d9-b9c6-26f272924e0e" TYPE="swap" PARTLABEL="swap" PARTUUID="c92da4f2-db76-480d-a3f8-2ee1e5da5e1f" /dev/sda6: UUID="59a685b5-c577-4992-b6c9-fb6229a7ad0d" TYPE="ext4" PARTLABEL="debian" PARTUUID="fb7ea62e-f488-4e62-a380-272e22891d5d" /dev/sdb1: UUID="c05302c7-f6cc-4485-94fa-c561892b367c" TYPE="ext4" PARTLABEL="debianssd" PARTUUID="3c91aa42-6744-4586-aa99-ddc557ae0908" Ahí dice que el UUID de la swap es 3550194e-bce5-43d9-b9c6-26f272924e0e , que no coincide con el que aparecía en el fstab. Entonces lo que tuve que hacer es editar el /etc/fstab y poner el UUID correcto. Se puede hacer con el comando sudo nano /etc/fstab (Ctrl-O para guardar y Ctrl-X para salir)
  7. Bueno, hace unos días se me fue la imagen y decidí que era hora de hacer funcionar la gráfica dedicada nvidia (que para eso me la incluí en el presupuesto). Mientras hago instalaciones modo texto, no hay problema, pero una vez instalado el sistema, a la hora de iniciarse, se queda enganchado en la carga inicial. He probado con vagos, debian, mint, y kaos. Los live no van, menos en la de kaos, en su versión non-free (vamos, cargando el firmware privativo de nvidia). He realizado una prueba final, que consiste en volver a la integrada intel, realizando una instalación de debian sin ningún problema, reiniciando unas cuantas veces, y comprobando que no hay ningún problema. Después he vuelto a configurar la placa para que inicie la gráfica dedicada, y al iniciar el sistema linux se ha quedado en el siguiente mensaje: [....] Waiting for /dev to be fully populated... Lleva así bastantes minutos. Sospecho que hay un conflicto con la gráfica. Antes de hacer el cambio, he comprobado el kernel que tenía (3.13) y he instalado los controladores privativos de nvidia. Me salió un mensaje diciendo que había un conflicto con los existentes en el kernel (nouveau), supuestamente resuelto en un reinicio. No se que más contar. Datos de interés: - Placa Base: Gigabyte B85-HD3 - Gráfica: Asus Geforce GT 610 Si no me queda más remedio, me tocará volver a la integrada, pero me gustaría poder utilizar la otra. Alguna idea?
  8. 1. BREVE INTRODUCCIÓN/CONCEPTOS BÁSICOS Un bootanimation es una animación de inicio o arranque para dispositivos con Android, y consiste en una colección de imágenes .png que se proyectan en la pantalla una tras otra con la suficiente rapidez como para que se vea como una animación. El bootanimation está contenido en un archivo .zip con esa carpeta/carpetas de imágenes, y también un archivo desc.txt, que es el encargado de marcar la resolución-tamaño de reproducción de las imágenes, los frame por segundo o velocidad de reproducción, así como el orden en que aparecen las imágenes y los loops (bucles) que queramos añadirle. Como se puede ver en la imagen... - 1 es la resolución del bootanimation (puedes utilizar la resolución de tu dispositivo; por ejemplo en la foto es 320x480). - 2 son los fps del bootanimation (fotogramas o frames por segundo). Cuanto más alto sea el nº, más rápido se reproducirá tu bootanimation. Un fps tipo es 30. - 3 estas son las carpetas que contienen las imágenes para tu bootanimation. - 4 es un indicador para el bootanimation para que busque nuevas órdenes. - 5 especifica el nº de veces que esta sección del bootanimation se reproducirá ("0" significa infinito). - 6 define la pausa en segundos antes de repetirse o moverse en la línea siguiente ("0" significa que no hay pausa, "10" significa 10 segundos de pausa). Dentro de la carpeta/carpetas "part" están todas las imágenes que componen la animación y están tituladas numéricamente para marcar el orden de aparición de las mismas durante la animación (001, 002, 003, etc). Es muy importante que cuando tengamos creados los archivos necesarios los comprimamos en un zip de la siguiente manera (si no el bootanimation no funcionará): 2. INSTALACIÓN DE UN BOOTANIMATION Para cambiar el bootanimation de nuestro dispositivo es necesario tener acceso Root. Se puede cambiar de varias maneras: 1- Con Root Explorer: movemos el nuevo bootanimation.zip a system/media o data/local (dependiendo de dónde se encuentre). Reiniciamos el móvil. 2- Desde el recovery: usando un zip de instalación que haga lo anterior. 3- Con apk del Market. 4- Con determinados software de PC.
  9. Nunca he sido amigo de "tapar" el arranque con cosas bonitas, pero como el amigo portaro nos dejó un tema para plymouth con el logo del foro para poner en GNU/Linux Vagos, me decidí a probar a ver que tal se adaptaba. El proceso no me ha dado ningún problema: aptitude install plymouth plymouth-drm plymouth-x11 he habilitado el GRUB_GFXMODE=1042x768x32 y añadido la opción splash como GRUB_CMDLINE_LINUX_DEFAULT dentro de /etc/default/grub actualizado grub update-grub he metido el tema "debian-Vagos" en /usr/share/plymouth/themes y me he puesto a configurar plymouth: plymouth-set-default-theme Debian-Vagos Actualizado el initramfs update-initramfs -u Y antes de reinicir, he probado a ver si funciona: plymouthdplymouth --show-splash Resultado: Peeeeeeeeeeeeeeeeeeeeeeeeero, cuando he reiniciao el que ha aparecido es el tema por defecto, fondo negro y una barra en la parte inferior de color blanco y azul, nada que ver con el tema elegido. He probado con varios temas más, siempre con el mismo resultado, lo muestra bien al simular, pero al arrancar nada, el tema por defecto siempre. No sé si es que estoy pasando algo por alto, si será un bug de plymouth o que directamente no se lleva conmigo pero me parece rarísimo. Si tienen alguna idea, es bienvenida. Gracias y SalUnix
  10. Matthew Garrett ha escrito una entrada interesante a la vez que preocupante en su blog, donde informa de un, según sus propias palabaras, bizzarro bug de Uefi en el ThinkCentre M920p de la empresa Lenovo. El origen del problema parece ser una paranóica función de chequeo adicional que compara las entradas correspondientes a los sistemas instalados y sólo permite su ejecución si coincide con los patrones marcados de fábrica, en este caso, parece que únicamente permitirá "Windows Boot Manager" o "Red Hat Enterprise Linux", bloqueando cualquier otro sistema con el que tratemos de arrancar el equipo. Este problema fue descubierto tras varios intentos de instalar Fedora 17 en el equipo, cuya instalación termina de forma satisfactoria, pero a la hora de intentar iniciarlo el equipo se bloquea debido a esta restricción de Uefi. En un primer momento observó que la entrada correspondiente a Fedora ocupaba 6 Bytes más que la de Windows, algo que fue sencillo de corregir, dejando la misma estructura para ambas entradas, aunque no sirvió de nada, Windows podía arrancar, pero Fedora seguía sin hacerlo. Cada entrada de Uefi tiene una cadena descriptiva. Ésta es usada por el firmware para mostrársela a los usuarios en el menú (En lugar de "HDD0", "USB3"...), el firmware puede mostrar en la lista "Windows Boot Manager" y "Fedora Linux", no hay ningún motivo para que el firmware tenga que analizarla. No obstante, las evidencias son claras, teniendo dos entradas con la misma estructura, una que diga "Windows Boot Manager" y la otra no, sólo la primera funcionará. Llegado a este punto, Matthew ha estudiado muy por encima el firmware de Levono y descubierto que, efectivamente, hay una función que hace una comprobación de esta cadena descriptiva y la compara con los valores prefijados "Windows Boot Manager" y "Red Hat Enterprise Linux" y en caso de no concordar con ninguno, muestra un error, impidiendo el arranque. Según sus palabras, es realmente bizarro que el fabricante haya incluido código adicional para comprobar con qué sistema estamos iniciando el equipo. Aún no han podido verificar hasta qué punto es de estricta esta verificación, si es necesaria una concordancia absoluta o es simplemente el prefijo "Red Hat Enterprise Linux" lo que comprueba (En este caso sería sencillo, bastaría con "falsearlo"). Por ahora, para todos aquellos que quieran instalar una distribución que no sea Red Hat Enterprise, lo mejor es cambiar el firmware por uno más antiguo. Una examen más exhaustivo del código del firmware posiblemente permita dar con alguna solución al problema. http://mjg59.dreamwidth.org/20187.html
  11. El día de ayer, Pierre Schmitz, anunció que ya esta disponible la nueva imagen de instalación de Arch Linux correspondiente al mes de octubre. Viene con todo un conjunto de paquetes actualizados y entre los cambios más destacados se es de destacan: Systemd es el sistema de arranque utilizado para iniciar el Live. initscripts ya no esta disponible en el sistema live, pero sí es instalado en el disco duro al completar el proceso de instalación del sistema. Esto será cambiado pronto Se ha simplificado el arranque y configuración de EFI. gimmiboot se utiliza para mostrar un menú en los sistemas EFI Estos nuevos paquetes están disponibles en el sistema Live: ethtool, fsarchiver, gummiboot-efi, mc, partclone, partimage, refind-efi, rfkill, sudo, testdisk, wget, xl2tpd www.archlinux.org/news/install-medium-20121006-introduces-systemd/
×
×
  • Crear Nuevo...