On 06/11/2018 01.26, Juan Erbes wrote:

Después de la última actualización del sábado último, no puedo arrancar normalmente con Leap 15.1 Alpha. Escribí en Factory, pero no hubo respuestas.

Lo vi. No uso Factory, y mucho menos con btrfs... Tengo un TW en virtual. Ah, espera, que lo que tienes es la alpha de la 15.1. Brrr...

No se si será que despues de actualizar había arrancado W10 para editar un video, y éste escribió la partición raiz de Leap 15.1. Si intento arrancar con alguno de los últimos snapshots, no tengo problema. Pero si intento restaurar uno de los últimos snapshots, y luego arrancar normalmente, el problema continúa.

No, Windows aquí es inocente. No podrías arrancar ningún snapshot.

Sospecho que algo tiene que ver con los cambios en los sobvolumenes de btrfs, donde /var es ahora un subvolumen separado que puede ser escrito por los procesos en Leap 15.1: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.1/

No lo se.

Otro detalle: "Algunos paquetes modifican el contenido de /var o /srv en sus guiones %post de RPM. Estos paquetes son incompatibles. Si se encuentra con este tipo de paquete, elabore un informe de error. "

Huh.

Ahora que lo pienso, tengo el repo Packman de 15.0

No afectaria al arranque...

Volviendo al mensaje de error "/usr/bin/X", "X" es un symlink que apunta a /var/lib/X11/X y a su vez este nuevo "X" es un symlink que apunta a: /usr/bin/Xorg

Probé a borrar "/usr/bin/X", creandolo de nuevo apuntando directamente a /usr/bin/Xorg

Pero no funcionó.

En la 15.0 está así: cer@Legolas:~> l /usr/bin/X lrwxrwxrwx 1 root root 14 Apr 20 2018 /usr/bin/X -> /var/lib/X11/X* cer@Legolas:~> l /var/lib/X11/X lrwxrwxrwx 1 root root 13 Apr 20 2018 /var/lib/X11/X -> /usr/bin/Xorg* cer@Legolas:~> l /usr/bin/Xorg -rwxr-xr-x 1 root root 2402392 Apr 20 2018 /usr/bin/Xorg* cer@Legolas:~>

¿Alguna idea?

Reinstalar. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

On 06/11/2018 01.46, Juan Erbes wrote:

...

Reinstalar.

En vez de reinstalar, le di "actualizar", pero no funcionó.

Una de las "características", es que si desde Leap 15.1 monto la partición raíz de Opensuse 42.3 en /mnt puede ver el contenido de /var completo. Pero si hago al reves, en Opensuse 42.3 monto la partición raíz de Leap 15.1 en /mnt , /var aparece vacío.

Mejor me lo pones: formatea y reinstala. No pierdas el tiempo intentando averiguar porqué /var está vacío. O habla con un experto en btrfs. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

El lun., 5 nov. 2018 a las 22:11, Carlos E. R. () escribió:

On 06/11/2018 01.46, Juan Erbes wrote:

...

...

Reinstalar.

En vez de reinstalar, le di "actualizar", pero no funcionó.

Una de las "características", es que si desde Leap 15.1 monto la partición raíz de Opensuse 42.3 en /mnt puede ver el contenido de /var completo. Pero si hago al reves, en Opensuse 42.3 monto la partición raíz de Leap 15.1 en /mnt , /var aparece vacío.

Mejor me lo pones: formatea y reinstala. No pierdas el tiempo intentando averiguar porqué /var está vacío.

Esperaba que alguien contestara en Factory. Lo de "formatear y reinstalar" es algo muy "a la windows", y la verdad que como la conexión de internet que tengo es lenta, quisiera evitar tener que actualizar todo. Por otro lado, es muy probable que se trate de alguna tontería, ya que utilizando los últimos snapshots que va creando nuevos el sistema, carga sin ningún problema. Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El mar., 6 nov. 2018 a las 18:59, Sergio Lindo () escribió:

Hola Juan,

...

No se si será que despues de actualizar había arrancado W10 para editar un video, y éste escribió la partición raiz de Leap 15.1.

No, por esta vez, W es inocente. ;)

...

Si intento arrancar con alguno de los últimos snapshots, no tengo problema. Pero si intento restaurar uno de los últimos snapshots, y luego arrancar normalmente, el problema continúa.

Supongo que te refieres a que los últimos snapshots son con Leap 42.3. Y los que no arrancan son con Leap 15.

No, cuando instale Leap 15.1 la hice desde dvd, formateando la partición raiz. Ahora estoy con el ultimo snapshot y el uname -r da: 4.12.14-lp151.17-default

...

Sospecho que algo tiene que ver con los cambios en los sobvolumenes de btrfs, donde /var es ahora un subvolumen separado que puede ser escrito por los procesos en Leap 15.1: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.1/

¿Cómo realizaste la instalación exactamente? ¿Mediante la opción actualizar del DVD?

La instalación de Leap 15.1 formatee la partición raiz yla hice desde dvd.

¿Ejecutando el comando zypper? Eso sólo actualiza los paquetes, pero no el esquema de particiones. ¿Ejecutando el comando zypper mientras estaba el entorno gráfico ejecutándose? Eso puede provocar que los paquetes de entorno gráfico no se instalen correctamente porque no puede escribir mientras se está ejecutando. ¿Desde qué versión hacia qué versión actualizaste?

Desde Leap 15.1 Alpha Build 271 a Build 318.2, aunque realmente a la Build 271 solo le faltaban las actualizaciones de la ultima semana, que son las que ocasionaron el problema. Este ultimo intento "de actualización" fue desde el menu del dvd, despues de haber aparecido el crash de Xorg.

Ha habido tres cambios importantes en la estructura de las particiones entre 42.2, 42.3 y 15.0. Ambas incompatibles entre sí. Una actualización normal no basta, hay que crear manualmente el nuevo sistema de particiones cada vez. Para mí, el esfuerzo necesario para obtener un resultado chapucero no merece la pena. Tanto de 42.2 a 42.3 como de 42.3 a 15.0, realicé instalación limpia con los nuevos esquemas de particiones.

Eso explica porqué al montar /var de Leap 15.1 te aparece vacío, porque para Leap 15 es un sub volumen.

...

Otro detalle: "Algunos paquetes modifican el contenido de /var o /srv en sus guiones %post de RPM. Estos paquetes son incompatibles. Si se encuentra con este tipo de paquete, elabore un informe de error. "

Ahora que lo pienso, tengo el repo Packman de 15.0

Si no usas un Transactional Server/MicroOS role, esto no es un problema. Por supuesto se pide que reportes el error para poder arreglar esos paquetes para Transactional Server/MicroOS.

...

Volviendo al mensaje de error "/usr/bin/X", "X" es un symlink que apunta a /var/lib/X11/X y a su vez este nuevo "X" es un symlink que apunta a: /usr/bin/Xorg

Probé a borrar "/usr/bin/X", creandolo de nuevo apuntando directamente a /usr/bin/Xorg

Pero no funcionó.

¿Alguna idea?

Arranca el sistema desde la última snapshot que funciona. Usa snapper para ver el diff entre esa snapshot y la siguiente. Busca los cambios relacionados con X. Aparte, para realizar una actualización correcta, hace falta crear el esquema de particiones y sub volúmenes correcto https://en.opensuse.org/SDB:BTRFS

Yo también recomendaría sacar los datos, y reinstalar.

¿También te "windowizaste"? El paquete Xorg en si, no aparece coo actualizado, pero si los drivers graficos y las librerías Mesa. Gracias, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El mar., 6 nov. 2018 a las 21:26, Juan Erbes () escribió:

El mar., 6 nov. 2018 a las 19:37, Juan Erbes () escribió:

...

El mar., 6 nov. 2018 a las 18:59, Sergio Lindo () escribió:

...

Hola Juan,

...

No se si será que despues de actualizar había arrancado W10 para editar un video, y éste escribió la partición raiz de Leap 15.1.

No, por esta vez, W es inocente. ;)

...

Si intento arrancar con alguno de los últimos snapshots, no tengo problema. Pero si intento restaurar uno de los últimos snapshots, y luego arrancar normalmente, el problema continúa.

Supongo que te refieres a que los últimos snapshots son con Leap 42.3. Y los que no arrancan son con Leap 15.

No, cuando instale Leap 15.1 la hice desde dvd, formateando la partición raiz.

Ahora estoy con el ultimo snapshot y el uname -r da: 4.12.14-lp151.17-default

...

...

Sospecho que algo tiene que ver con los cambios en los sobvolumenes de btrfs, donde /var es ahora un subvolumen separado que puede ser escrito por los procesos en Leap 15.1: https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.1/

¿Cómo realizaste la instalación exactamente? ¿Mediante la opción actualizar del DVD?

La instalación de Leap 15.1 formatee la partición raiz yla hice desde dvd.

...

¿Ejecutando el comando zypper? Eso sólo actualiza los paquetes, pero no el esquema de particiones. ¿Ejecutando el comando zypper mientras estaba el entorno gráfico ejecutándose? Eso puede provocar que los paquetes de entorno gráfico no se instalen correctamente porque no puede escribir mientras se está ejecutando. ¿Desde qué versión hacia qué versión actualizaste?

Desde Leap 15.1 Alpha Build 271 a Build 318.2, aunque realmente a la Build 271 solo le faltaban las actualizaciones de la ultima semana, que son las que ocasionaron el problema. Este ultimo intento "de actualización" fue desde el menu del dvd, despues de haber aparecido el crash de Xorg.

...

Ha habido tres cambios importantes en la estructura de las particiones entre 42.2, 42.3 y 15.0. Ambas incompatibles entre sí. Una actualización normal no basta, hay que crear manualmente el nuevo sistema de particiones cada vez. Para mí, el esfuerzo necesario para obtener un resultado chapucero no merece la pena. Tanto de 42.2 a 42.3 como de 42.3 a 15.0, realicé instalación limpia con los nuevos esquemas de particiones.

Eso explica porqué al montar /var de Leap 15.1 te aparece vacío, porque para Leap 15 es un sub volumen.

...

Otro detalle: "Algunos paquetes modifican el contenido de /var o /srv en sus guiones %post de RPM. Estos paquetes son incompatibles. Si se encuentra con este tipo de paquete, elabore un informe de error. "

Ahora que lo pienso, tengo el repo Packman de 15.0

Si no usas un Transactional Server/MicroOS role, esto no es un problema. Por supuesto se pide que reportes el error para poder arreglar esos paquetes para Transactional Server/MicroOS.

...

Volviendo al mensaje de error "/usr/bin/X", "X" es un symlink que apunta a /var/lib/X11/X y a su vez este nuevo "X" es un symlink que apunta a: /usr/bin/Xorg

Probé a borrar "/usr/bin/X", creandolo de nuevo apuntando directamente a /usr/bin/Xorg

Pero no funcionó.

¿Alguna idea?

Arranca el sistema desde la última snapshot que funciona. Usa snapper para ver el diff entre esa snapshot y la siguiente. Busca los cambios relacionados con X. Aparte, para realizar una actualización correcta, hace falta crear el esquema de particiones y sub volúmenes correcto https://en.opensuse.org/SDB:BTRFS

Yo también recomendaría sacar los datos, y reinstalar.

¿También te "windowizaste"?

El paquete Xorg en si, no aparece coo actualizado, pero si los drivers graficos y las librerías Mesa.

En el email anterior había arrancado con el que a ese momento era e último snapshot Nº 209.

Ahora he arrancado con el "nuevo" snapshot Nº 211, y ha cargado sin problemas.

Pero si intento arrancar normalmente, falla.

Voy a intentar reinstalar el grub, para ver si cambia algo.

No me deja, porque dice que es un sistema de "solo lectura". Salu2 -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 06/11/2018 22.59, Sergio Lindo wrote:

Ha habido tres cambios importantes en la estructura de las particiones entre 42.2, 42.3 y 15.0. Ambas incompatibles entre sí. Una actualización normal no basta, hay que crear manualmente el nuevo sistema de particiones cada vez. Para mí, el esfuerzo necesario para obtener un resultado chapucero no merece la pena. Tanto de 42.2 a 42.3 como de 42.3 a 15.0, realicé instalación limpia con los nuevos esquemas de particiones.

Sólo aplica a la raiz con btrfs, pero es su caso.

Eso explica porqué al montar /var de Leap 15.1 te aparece vacío, porque para Leap 15 es un sub volumen.

Desde luego, actualizar de 42.X a 15.1 con btrfs no es posible de manera automatizada. Ni online ni offline. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Hola Juan,

La instalación de Leap 15.1 formatee la partición raiz yla hice desde dvd.

Entonces lo hiciste correctamente. Y no hace falta reinstalar. (no windowsation XD)

Desde Leap 15.1 Alpha Build 271 a Build 318.2, aunque realmente a la Build 271 solo le faltaban las actualizaciones de la ultima semana, que son las que ocasionaron el problema. Este ultimo intento "de actualización" fue desde el menu del dvd, despues de haber aparecido el crash de Xorg.

Vale, no había entendido bien tu problema. Creía que ya habías hecho rollback. Como dice Carlos, el funcionamiento del rollback es algo más complejo. Cuando usas la entrada de Grub para arrancar el sistema desde una snapshot, esas snapshots son de sólo lectura. Sólo puede haber una capa de todos los copy-on-write sobre la que se puede escribir. Esa capa es la snapshot principal. Para hacer rollback, hay que hacer que esa capa de escritura esté sobre la snapshot que quieres restaurar. Para eso, después de haber arrancado desde la snapshot de sólo lectura, ejecuta: sudo snapper rollback Eso hará que la capa de escritura esté sobre la snapshot actual. Pero, sigues estando en una snapshot de sólo lectura, así que tienes que reiniciar para que el sistema arranque desde la capa de escritura. Sólo que esta vez, la capa de escritura está sobre la snapshot que se quería restaurar. Y todas las nuevas snapshots se crearán a partir de ésta. Espero que te sirva. Un saludo.-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Lo había hecho varias veces desde el menú de Yast, pero el problema continuaba. Tal vez me halla equivocado en algo.

Desde el menú de Yast no se puede hacer ese tipo de rollback. Sólo se pueden restaurar ficheros.

Probaré esta tarde a hacerlo por consola, como tu dices.

Claro, cuéntanos cómo te ha ido. :)-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El jue., 8 nov. 2018 a las 18:18, Juan Erbes () escribió:

Funcionó perfecto con "sudo snapper rollback"

Pero se nota que de alguna forma estaba utilizando un snapshot anterior a la última actualización que ocasionó el problema. En vez de 390 paquetes a actualizar, ahora tengo 437, pero los iré actualizando por etapas, para ver cual ocasiona el problema, si se repite.

Muchas Gracias!

Saludos, Juan

El jue., 8 nov. 2018 a las 18:07, Sergio Lindo () escribió:

...

...

Lo había hecho varias veces desde el menú de Yast, pero el problema continuaba. Tal vez me halla equivocado en algo.

Desde el menú de Yast no se puede hacer ese tipo de rollback. Sólo se pueden restaurar ficheros.

...

Probaré esta tarde a hacerlo por consola, como tu dices.

Claro, cuéntanos cómo te ha ido. :)

Al menos al hacer la actualización por etapas, el problema reapareció con los primeros paquetes actualizados: Mesa-dri - DRI plug-ins for 3D acceleration Versión alternativa Versión instalada Versión: 18.0.2-lp151.19.1 18.0.2-lp151.18.2 Hora de construcción: mié 31 oct 2018 12:49:24 -03 vie 19 oct 2018 18:06:35 -03 Si una mira los ultimos releases: https://www.mesa3d.org/ Son todos bugfixes. Para Factory está Mesa 18.2.4 : https://software.opensuse.org/package/Mesa Veremos que pasa. Salu2 USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 09/11/2018 13.00, Juan Erbes wrote:

...

Veremos que pasa.

Lamentablemente, tanto los paquetes para Leap 15.0, Tumbleweed y Factory, Mesa 18.2.4 están compilados con glibc 2.27, mientras que la versión presente en Leap 15.1 es glibc 2.26.

Tendré que evitar actualizar el paquete Mesa, hasta que pongan alguna versión más reciente con el problema solucionado en alguno de los bugfixes de las versiones más recientes de Mesa. Esta es una versión con los mayores bugfixes: https://www.mesa3d.org/relnotes/18.1.0.html

No te olvides de abrir un bugzilla. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

Lamentablemente, tanto los paquetes para Leap 15.0, Tumbleweed y Factory, Mesa 18.2.4 están compilados con glibc 2.27, mientras que la versión presente en Leap 15.1 es glibc 2.26.

Pero cómo se puede escapar esto en el proceso de control de calidad?? -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El lun., 12 nov. 2018 a las 6:47, Carlos E. R. () escribió:

On 12/11/2018 10.42, miguel gmail wrote:

...

...

Lamentablemente, tanto los paquetes para Leap 15.0, Tumbleweed y Factory, Mesa 18.2.4 están compilados con glibc 2.27, mientras que la versión presente en Leap 15.1 es glibc 2.26.

Pero cómo se puede escapar esto en el proceso de control de calidad??

¿Porqué, si es a propósito?

Finalmente, opté por formatear la partición raiz (despues de rearmar mi pc, a la cual le ingresó una descarga eléctrica a traves de la red), e instalé en lugar de Leap 15.1 alpha, Tumbleweed que ya viene con glibc 2.27 y Mesa 18.1.17. A un amigo le había instalado también Leap 15.1 alpha, y cuando terminaba de reproducir un video se coolgaba Xorg. El viernes último le hice una actualización, y borró del menú de grub las entradas de windows y el acceso a los snapshots de Sneaper y se colgaba al tratar de cargar el entonrno gráfico, sin ningun opción de acceso a consola (Alt + Control + Fx (1 a 5)). En esta semana, también se la formateo y le pongo Tumbleweed. Al menos durante la instalación de los paquetes adicionales, daba la impresión de que la equipe con la mitad de memoria (8 Gb en vez de 16) porque el mobo que coloque tiene solamente 2 slots de memoria DIMM. Pensaba que era el mobo que se pinchó, pero por ahora lo unico de lo que estoy seguro es que mi tarjeta de video R9 380X de 4 GB de RAM murió y tube que colocar una R7 240 de 2 GB de RAM. Tengo que volver a probar el mobo, para ver si realmente se pinchó, o era solamente la tarjeta de video. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

On 13/11/2018 15.09, miguel gmail wrote:

El lun., 12 nov. 2018 a las 10:47, Carlos E. R. () escribió:

...

On 12/11/2018 10.42, miguel gmail wrote:

...

...

Lamentablemente, tanto los paquetes para Leap 15.0, Tumbleweed y Factory, Mesa 18.2.4 están compilados con glibc 2.27, mientras que la versión presente en Leap 15.1 es glibc 2.26.

Pero cómo se puede escapar esto en el proceso de control de calidad??

¿Porqué, si es a propósito?

Entiendo que a propósito es el cambio de versión de glibc y eso me parece bien.

Lo que digo es que no entiendo cómo puede pasarse por alto la dependencia de otros paquetes (miles?) con glibc... ¡glibc!

Bueno, es una alfa. Pero que yo sepa, todo depende de glibc. Desde siempre. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)