Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

AMD Radeon(TM) R2 en Jessie

40 views
Skip to first unread message

Julian Daich

unread,
Aug 22, 2020, 4:20:03 PM8/22/20
to
Hola,

¿ Hay forma de usar el controlador ATI Catalyst para la tarjeta AMD
Radeon(TM) R2 en vez del Radeon?
Tengo un equipo de escritorio en Wheezy y estoy dudando en actualizar
por el pobre rendimiento del controlador Radeon respecto al privativo.

Saludos,
--
Julian

Camaleón

unread,
Aug 23, 2020, 3:20:03 AM8/23/20
to
Parece que Debian no lo mantiene «oficialmente» desde Jessie, última
versión donde lo recomiendan¹.

Los controladores propietarios de las gráficas siempre son conflictivos
porque se construyen (dependen) de la versión del kernel, por eso deben
ir parejos (es decir, que una actualización del kernel requerirá
actualizar el controlador gráfico y viceversa).

Si necesitas imperiosamente instalar/utilizar el driver propietario de
AMD-ATI, yo haría lo siguiente: cargar en el equipo el LiveCD de la
versión de Debian que quieras instalar e intentar instalar el driver
directamente desde la web del fabricante², para ver si funciona
correctamente o qué problemas te da (revisa las dependencias de los
paquetes, versiones de bibliotecas requeridas, etc...).

Aunque lograras instalarlo, a largo plazo te dará problemas por lo que
te recomendaría usar el libre, aún a costa de la merma en el
rendimiento.

¹https://wiki.debian.org/ATIProprietary
²https://www.amd.com/en/support/previous-drivers/apu/amd-e-series-processors/amd-e2-series-apu-for-laptops/e2-7110-radeon-r2-graphics

Saludos,

--
Camaleón

Julián Daich

unread,
Aug 23, 2020, 9:50:03 AM8/23/20
to


El 23/8/20 a las 10:11, Camaleón escribió:
> El 2020-08-22 a las 22:14 +0200, Julian Daich escribió:
>
>> ¿ Hay forma de usar el controlador ATI Catalyst para la tarjeta AMD
>> Radeon(TM) R2 en vez del Radeon?
>> Tengo un equipo de escritorio en Wheezy y estoy dudando en actualizar
>> por el pobre rendimiento del controlador Radeon respecto al privativo.
>
> Parece que Debian no lo mantiene «oficialmente» desde Jessie, última
> versión donde lo recomiendan¹.
>
> Los controladores propietarios de las gráficas siempre son conflictivos
> porque se construyen (dependen) de la versión del kernel, por eso deben
> ir parejos (es decir, que una actualización del kernel requerirá
> actualizar el controlador gráfico y viceversa).
>

Hola.

Gracias. Pensé que DKMS solcionaba esos problemas.

> Si necesitas imperiosamente instalar/utilizar el driver propietario de
> AMD-ATI, yo haría lo siguiente: cargar en el equipo el LiveCD de la
> versión de Debian que quieras instalar e intentar instalar el driver
> directamente desde la web del fabricante², para ver si funciona
> correctamente o qué problemas te da (revisa las dependencias de los
> paquetes, versiones de bibliotecas requeridas, etc...).
>

Tienen .debs del 2015 para mi tarjeta. Creo que funcionan con el núcleo
4.04. Yo tengo instalado el 3.16. En Jessie no hay controlador ATI para
mi tarjeta en los repositorios de Debian. La pregunta es si hay
disponible un núcleo antiguo en los repositorios o tengo que compilar
uno propio para el controlador. No creo que pueda resolver eso con la
imagen en vivo, pero puedo llegar a ver si hay un núcleo antiguo en los
repositorios. Voy a hacer la prueba,

> Aunque lograras instalarlo, a largo plazo te dará problemas por lo que
> te recomendaría usar el libre, aún a costa de la merma en el
> rendimiento.
>

Siempre puedo dejar un núcleo dedicado si es que no trae efectos
secundarios en el futuro.

Saludos,

Julián
Julian Daich <juli...@gmail.com>

Camaleón

unread,
Aug 23, 2020, 10:20:03 AM8/23/20
to
El 2020-08-23 a las 16:43 +0300, Julián Daich escribió:

> El 23/8/20 a las 10:11, Camaleón escribió:

(...)

> > Los controladores propietarios de las gráficas siempre son conflictivos
> > porque se construyen (dependen) de la versión del kernel, por eso deben
> > ir parejos (es decir, que una actualización del kernel requerirá
> > actualizar el controlador gráfico y viceversa).
> >
>
> Hola.
>
> Gracias. Pensé que DKMS solcionaba esos problemas.

Para que DKMS haga su trabajo, necesitas el controlador Catalyst y el
kernel que hay disponible en los repos de Debian. Es decir, que si no
hay paquete .deb de Catalyst en los repos para tu versión de Debian,
aunque tengas DKMS y el kernel de Debian no va a funcionar si instalas
el controladors de AMD-ATI desde otra fuente (p. ej., el controladora
que ofrece el fabricante desde su web.

De hecho, DKMS no es necesario para esto. Recuerdo que en su momento
tenía instalado el controlador propetario de nvidia (que estaba
disponible en los repos de Debian non-oss), y el kernel de Debian, sin
más, y esta combinación funcionaba sin problemas y son tener instalado
el paquete DKMS.

> > Si necesitas imperiosamente instalar/utilizar el driver propietario de
> > AMD-ATI, yo haría lo siguiente: cargar en el equipo el LiveCD de la
> > versión de Debian que quieras instalar e intentar instalar el driver
> > directamente desde la web del fabricante², para ver si funciona
> > correctamente o qué problemas te da (revisa las dependencias de los
> > paquetes, versiones de bibliotecas requeridas, etc...).
> >
>
> Tienen .debs del 2015 para mi tarjeta. Creo que funcionan con el núcleo
> 4.04. Yo tengo instalado el 3.16. En Jessie no hay controlador ATI para mi
> tarjeta en los repositorios de Debian.

Hum... para Jessie (Debian 8) sí lo tienes:

https://packages.debian.org/jessie/fglrx-driver

Lo que ya no tienes es el driver para versiones superiores (9 y
posteriores).

> La pregunta es si hay disponible un núcleo antiguo en los repositorios
> o tengo que compilar uno propio para el controlador.

Para Jessie no tienes problemas, tienes las instrucciones para
instalarlo en el enlace que te pasé antes. ¿A qué versión de Debian
quieres actualizar (Buster, testing...)?

> No creo que pueda resolver eso con la imagen en vivo, pero
> puedo llegar a ver si hay un núcleo antiguo en los repositorios. Voy a hacer
> la prueba,

Mucha gente desconoce que una LiveCD te permite instalar paquetes. Eso
sí, no puedes reiniciar el sistema o perderás todo lo que hayas hecho,
paquetes instalados incluído. Con una LiveUSB sí podrás instalar
paquetes en la llave USB y reiniciar manteniendo los cambios, sin
problemas. Es una forma de probar cosas sin tocar el sistema instalado,
yo siempre cargo una LiveCD en mis equipos antes de instalar una nueva
versión de Debian, y así anticipo posibles problemas con los componentes
que tengo instalados.

> > Aunque lograras instalarlo, a largo plazo te dará problemas por lo que
> > te recomendaría usar el libre, aún a costa de la merma en el
> > rendimiento.
> >
>
> Siempre puedo dejar un núcleo dedicado si es que no trae efectos secundarios
> en el futuro.

Tener un kernel desactualizado es un riesgo de seguridad, amén de las
incompatibilidades con otros servicios y paquetes, no te lo recomendaría.
Camaleón

Julián Daich

unread,
Aug 25, 2020, 5:50:03 AM8/25/20
to


El 23/8/20 a las 17:13, Camaleón escribió:
> Para que DKMS haga su trabajo, necesitas el controlador Catalyst y el
> kernel que hay disponible en los repos de Debian. Es decir, que si no
> hay paquete .deb de Catalyst en los repos para tu versión de Debian,
> aunque tengas DKMS y el kernel de Debian no va a funcionar si instalas
> el controladors de AMD-ATI desde otra fuente (p. ej., el controladora
> que ofrece el fabricante desde su web.
>

Hola,

Tengo que ver si hay forma de instalar el controlador de Jessie en
Strecht. Solo sería posible si en Strecht hay un núcleo compatible.

> De hecho, DKMS no es necesario para esto. Recuerdo que en su momento
> tenía instalado el controlador propetario de nvidia (que estaba
> disponible en los repos de Debian non-oss), y el kernel de Debian, sin
> más, y esta combinación funcionaba sin problemas y son tener instalado
> el paquete DKMS.
>

Seguramente porque lo hiciste a través de m-a


>
> https://packages.debian.org/jessie/fglrx-driver
>
> Lo que ya no tienes es el driver para versiones superiores (9 y
> posteriores).
>

Dicen hay que lo probaron hasta el núcleo 4.2. Siguiendo lo de más
arriba hay que ver lo que se puede llegar a hacer en Strecht.


> Mucha gente desconoce que una LiveCD te permite instalar paquetes. Eso
> sí, no puedes reiniciar el sistema o perderás todo lo que hayas hecho,
> paquetes instalados incluído. Con una LiveUSB sí podrás instalar
> paquetes en la llave USB y reiniciar manteniendo los cambios, sin
> problemas.

Hay que convertir a la llave USB en persistente solo, asegurarse de que
hay un GB libre e instalar los componentes privativos antes. Ya bajé la
imagen. Es tarea para el fin de semana.

> Es una forma de probar cosas sin tocar el sistema instalado,
> yo siempre cargo una LiveCD en mis equipos antes de instalar una nueva
> versión de Debian, y así anticipo posibles problemas con los componentes
> que tengo instalados.
>

Ojalá funcionara siempre eso. De momento el plan de pruebas es el
siguiente. Instalar en la imagen el núcleo más bajo posible.

1. deb de los repsoitorios Jessie
2. deb de ATI
3. probar si se puede con m-a
4. compilar el binario de ATI
5. Compilar por mi mismo un núcleo y probar lo de arriba.

Saludos,

Julián
--
Julian Daich <juli...@gmail.com>

Julián Daich

unread,
Aug 29, 2020, 3:20:03 PM8/29/20
to


El 25/8/20 a las 12:48, Julián Daich escribió:
> Hay que convertir a la llave USB en persistente solo, asegurarse de que
> hay un GB libre e instalar los componentes privativos antes. Ya bajé la
> imagen. Es tarea para el fin de semana.

Hola,

Tengo problemas para crear el USB de arranque. Abro otro hilo.

Julián Daich

unread,
Sep 6, 2020, 11:40:03 AM9/6/20
to


El 25/8/20 a las 12:48, Julián Daich escribió:
>> Es una forma de probar cosas sin tocar el sistema instalado,
>> yo siempre cargo una LiveCD en mis equipos antes de instalar una nueva
>> versión de Debian, y así anticipo posibles problemas con los componentes
>> que tengo instalados.
>>
>
> Ojalá funcionara siempre eso. De momento el plan de pruebas es el
> siguiente. Instalar en la imagen el núcleo más bajo posible.
>

Hola,

Hacerlo desde la imagen en vivo de dio muy buenos resultados de momento.
Una de las razones es que hay partes del sistema raíz que son difíciles
de mapear montadas en modo solo lectura. Muchas cosas no compilan bien y
no actualiza initramfs por ejemplo.

> 1. deb de los repsoitorios Jessie

Pide dejar xserver-xorg-core en la versión de Jessie. Después que
resolví las dependencias usando los repositorios de Jessie, dkms no
compila bien y no hay entorno gráfico. Pude ser por la causa de arriba.

> 2. deb de ATI

Da problemas de compilación de módulos en el núcleo. Puede ser por las
causas de arriba.

> 3. probar si se puede con m-a

Funciona con los repositorios de Jessie, pero despúes dice que por
porblemas de dependencias no puede instalar componentes extras.

> 4. compilar el binario de ATI

También pide dejar xserver-xorg-core en la versión de Jessie.

> 5. Compilar por mi mismo un núcleo y probar lo de arriba.

Es los mismo que 5.

Puedo probar 4 con los repositorios de Jessie, pero me late que lo que
pase no represente lo que pueda pasar con el equipo real.

¿ Que tan malo puede ser configurar /etc/apt/preferences para que
xserver-xorg-core se quede en Jessie y todo Xorg se quede sin
actualizaciones?

Camaleón

unread,
Sep 6, 2020, 1:30:03 PM9/6/20
to
El 2020-09-06 a las 18:36 +0300, Julián Daich escribió:

> El 25/8/20 a las 12:48, Julián Daich escribió:
> > > Es una forma de probar cosas sin tocar el sistema instalado,
> > > yo siempre cargo una LiveCD en mis equipos antes de instalar una nueva
> > > versión de Debian, y así anticipo posibles problemas con los componentes
> > > que tengo instalados.
> > >
> >
> > Ojalá funcionara siempre eso. De momento el plan de pruebas es el
> > siguiente. Instalar en la imagen el núcleo más bajo posible.
> >
>
>
> Hacerlo desde la imagen en vivo de dio muy buenos resultados de momento.
> Una de las razones es que hay partes del sistema raíz que son difíciles de
> mapear montadas en modo solo lectura. Muchas cosas no compilan bien y no
> actualiza initramfs por ejemplo.

(...)

No recuerdo cuál era el motivo que te impedía instalar el controlador
propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
el repositorio de non-free? :-?

Saludos,

--
Camaleón

Julián Daich

unread,
Sep 7, 2020, 7:10:03 AM9/7/20
to


El 6/9/20 a las 20:23, Camaleón escribió:
> No recuerdo cuál era el motivo que te impedía instalar el controlador
> propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
> el repositorio de non-free? :-?
>

Hola,

Está instalado en Jessie. Quiero ver la forma de poder seguir usando el
controlador FGLRX en Stretch. Jessie ya no tiene soporte.

Saludos.

Julián

Camaleón

unread,
Sep 7, 2020, 8:00:03 AM9/7/20
to
El 2020-09-07 a las 14:05 +0300, Julián Daich escribió:

> El 6/9/20 a las 20:23, Camaleón escribió:
> > No recuerdo cuál era el motivo que te impedía instalar el controlador
> > propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
> > el repositorio de non-free? :-?
> >
>
> Está instalado en Jessie. Quiero ver la forma de poder seguir usando el
> controlador FGLRX en Stretch. Jessie ya no tiene soporte.

Entonces supongo que la LiveCD sobre la que haces las pruebas es la
última versión estable (Buster) ¿no?

El paquete «deb» de AMD es para una versión concreta de Ubuntu, no te
servirá debido a la versión del kernel que tienes en Debian.

Lo más factible sería compilar el driver que hay para Linux (x86_64) y
seleccionar la opción de generar el paquete específico para la
distribución, si fuera posible. Consulta las notas de instalación¹ para
ver los requisitos de esta opción.

¹<http://www2.ati.com/relnotes/amd-catalyst-graphics-driver-installer-note
s-for-linux-operating-systems.pdf>

Saludos,

--
Camaleón

Camaleón

unread,
Sep 7, 2020, 9:40:03 AM9/7/20
to
El 2020-09-07 a las 15:16 +0300, Julián Daich escribió:

(mando a la lista)

> El 7/9/20 a las 14:50, Camaleón escribió:
> > El 2020-09-07 a las 14:05 +0300, Julián Daich escribió:
> >
> > > El 6/9/20 a las 20:23, Camaleón escribió:
> > > > No recuerdo cuál era el motivo que te impedía instalar el controlador
> > > > propietario de ATI en Debian Jessie ¿por qué no lo puedes instalar desde
> > > > el repositorio de non-free? :-?
> > > >
> > >
> > > Está instalado en Jessie. Quiero ver la forma de poder seguir usando el
> > > controlador FGLRX en Stretch. Jessie ya no tiene soporte.
>
> > Entonces supongo que la LiveCD sobre la que haces las pruebas es la
> > última versión estable (Buster) ¿no?
> >
>
> Hola,
> Np, Stretch.

Stretch ya es «oldstable». Obtendrás resultados más realistas con Buster,
que tiene un kernel más moderno.

> > El paquete «deb» de AMD es para una versión concreta de Ubuntu, no te
> > servirá debido a la versión del kernel que tienes en Debian.
> >
>
>
> Probé con la versión de Jessie.

No te sigo. Me refiero al paquete .deb que tienes en la web de AMD-ATI,
no al .deb que tienes en el repo «non-free» de Debian.

<https://www.amd.com/en/support/previous-drivers/apu/amd-e-series-process
ors/amd-e2-series-apu-for-laptops/e2-7110-radeon-r2-graphics>

> > Lo más factible sería compilar el driver que hay para Linux (x86_64) y
> > seleccionar la opción de generar el paquete específico para la
> > distribución, si fuera posible. Consulta las notas de instalación¹ para
> > ver los requisitos de esta opción.
> >
>
> Pide Xorg y por lo tanto xserver-xorg-core de Jessie
>
> Estamos volviendo en bucle a lo que escribí antes.

No te sigo aquí tampoco.
El paquete .zip de AMD-ATI te pedirá Xorg, eso es normal, pero no una
versión concreta sino que buscará la ruta del Xorg que tengas instalado
en el sistema. Que funcione o no es otra cosa, por eso tienes que
consultar los requisitos de instalación del controlador para ver qué
necesita.

La única posibilidad de éxito que veo para tener el driver antiguo y
propietario de ATI funcionando en una Debian moderna es compilando la
última versión disponible del controlador que proporciona el fabricante
con el kernel que tengas instalado.

Si esa combinación no funciona, bien por problemas de dependencias de
bibliotecas insatisfechas o versiones del sistema gráfico (Xorg) que no
son admitidas por el controlador de ATI, entonces no veo otra solución
para poner en marcha esa combinación concreta de tarjeta gráfica antigua
con driver antiguo en versiones recientes de Debian.

Saludos,

--
Camaleón

Julián Daich

unread,
Sep 8, 2020, 3:30:03 AM9/8/20
to

El 6/9/20 a las 18:36, Julián Daich escribió:
> ¿ Que tan malo puede ser configurar /etc/apt/preferences para que
> xserver-xorg-core se quede en Jessie y todo Xorg se quede sin
> actualizaciones?


Hola,

Entre tantos mensajes se perdió esta pregunta¿ alguine tiene alguna
respuesta?

Camaleón

unread,
Sep 8, 2020, 4:00:03 AM9/8/20
to
El 2020-09-08 a las 10:22 +0300, Julián Daich escribió:

(mando a la lista)

> El 7/9/20 a las 16:37, Camaleón escribió:
>
> >
> > Stretch ya es «oldstable». Obtendrás resultados más realistas con Buster,
> > que tiene un kernel más moderno.
> >
>
> Hola,
>
> Busco resultados que funcionen.

Lo que quiero decir es que con Stretch, en caso de que te funcione
_ahora_ vas a tener el mismo problema que con Jessie, a largo plazo.

Si quieres algo que funcione, no veo problemas para mantener el sistema
con Jessie, salvo que sea un equipo que tengas expuesto a Internet o
con funciones de servidor.

> > > > El paquete «deb» de AMD es para una versión concreta de Ubuntu, no te
> > > > servirá debido a la versión del kernel que tienes en Debian.
> > > >
> > >
> > >
> > > Probé con la versión de Jessie.
> >
> > No te sigo. Me refiero al paquete .deb que tienes en la web de AMD-ATI,
> > no al .deb que tienes en el repo «non-free» de Debian.
> >
>
> Como puse en un correo abterior el deb no compila bien.

Eso es lo que te decía, que ese paquete es para una versión concreta de
Ubuntu y te dará problemas en Debian con un kernel distinto.

> > <https://www.amd.com/en/support/previous-drivers/apu/amd-e-series-process
> > ors/amd-e2-series-apu-for-laptops/e2-7110-radeon-r2-graphics>
> >
> > > > Lo más factible sería compilar el driver que hay para Linux (x86_64) y
> > > > seleccionar la opción de generar el paquete específico para la
> > > > distribución, si fuera posible. Consulta las notas de instalación¹ para
> > > > ver los requisitos de esta opción.
> > > >
> > >
> > > Pide Xorg y por lo tanto xserver-xorg-core de Jessie
> > >
> > > Estamos volviendo en bucle a lo que escribí antes.
> >
> > No te sigo aquí tampoco.
> > El paquete .zip de AMD-ATI te pedirá Xorg, eso es normal, pero no una
> > versión concreta sino que buscará la ruta del Xorg que tengas instalado
> > en el sistema. Que funcione o no es otra cosa, por eso tienes que
> > consultar los requisitos de instalación del controlador para ver qué
> > necesita.
> >
>
> El instalador de AMD pide expresamente Xorg hasta 1.10 que es el que usa
> Jessie. Stretch viene con Xorg 1.19

Entonces mala solución le veo.

Pero no se sólo Xorg, también la versión del kernel. Estos son los
requisitos completos¹:

***
System Requirements
Before attempting to install the AMD Radeon Software Crimson Edition
Linux 15.11 Proprietary Graphics Driver, the following software must be
installed:

Xorg/Xserver 7.4 and above (up to 1.17)
Linux kernel 2.6 or above (up to 3.19)
glibc version 2.2 or 2.3
POSIX Shared Memory (/dev/shm) support is required for 3D applications

NOTE: If a Linux 2.6.11 or newer kernel was built with CONFIG_AGP
enabled, the kernel AGP frontend is required to load the fglrx kernel
module. To identify whether your kernel with CONFIG_AGP enabled, look
for CONFIG_AGP=y in the kernel config file, or if the 'agpgart' module
is loaded
***

El kernel de Stretch es 4.9, tendrías que instalar una versión anterior
para poder compilar ese driver, de ahí mis malos augurios para la
combinación que buscas :-(

¹<https://www.amd.com/en/support/kb/release-notes/rn-rad-lin-15-9#faq-Syst
em-Requirements>

Saludos,

--
Camaleón

Camaleón

unread,
Sep 8, 2020, 4:10:03 AM9/8/20
to
El 2020-09-08 a las 10:24 +0300, Julián Daich escribió:

> El 6/9/20 a las 18:36, Julián Daich escribió:
> > ¿ Que tan malo puede ser configurar /etc/apt/preferences para que
> > xserver-xorg-core se quede en Jessie y todo Xorg se quede sin
> > actualizaciones?
>
>
> Entre tantos mensajes se perdió esta pregunta¿ alguine tiene alguna
> respuesta?

En el caso de que te funcione para lo que buscas (tengo mis dudas por la
versión del kernel), tener el servidor X desactualizado no supone
más problema que la posible incompatibilidad con aplicaciones que
necesiten una versión determinada (superior) y obviamente, los problemas
o fallos de seguridad, que no se corrigen.

Saludos,

--
Camaleón

Julián Daich

unread,
Nov 29, 2020, 5:00:03 PM11/29/20
to
Hola,

Logré actualizar a Strecht y conservar el controlador AMD reteniendo
paquetes

sudo apt-mark hold libgl1-fglrx-glx libfglrx fglrx-atieventsd
fglrx-control fglrx-modules-dkms fglrx-driver glx-alternative-fglrx
linux-headers-3.16.0-11-amd64 linux-headers-3.16.0-11-common
linux-image-3.16.0-11-amd64 linux-kbuild-3.16

sudo apt-markmanual libgl1-fglrx-glx libfglrx fglrx-atieventsd
fglrx-control fglrx-modules-dkms fglrx-driver glx-alternative-fglrx
linux-headers-3.16.0-11-amd64 linux-headers-3.16.0-11-common
linux-image-3.16.0-11-amd64 linux-kbuild-3.16

sudo sed -i 's/jessie/stretch/g' /etc/apt/sources.list

sudo apt update
sudo apt upgrade

Después de reinicio para ver que no haya problmeas
sudo apt dist-upgrade

Ahora arranca con los dos núcleos y el controlador Catalyst como quería.

Solo un problemita. El núcleo 4.08 de Strecht no es compatible con
xserever-xorg-input-vmmouse de Jessie y por ende con
xserever-xorg-input-all. El reemplazo no se puede instalar por problemas
de dependencias. Si instalo los dos paquetes de arriba me quedo solo con
el núcleo 3.16 que no tiene soporte y si no los instalo da problemas
solo si uso máquinas virtuales por lo que lo dejo así sin instalar.

Saludos,

Julián


El 8/9/20 a las 12:30, Julián Daich escribió:
>
>
> El 8/9/20 a las 10:50, Camaleón escribió:
>> Si quieres algo que funcione, no veo problemas para mantener el sistema
>> con Jessie, salvo que sea un equipo que tengas expuesto a Internet o
>> con funciones de servidor.
>>
>
> Hola,
>
> Es un equipo de escritorio. No lo estoy usando mucho, pero cuando lo
> necesito me conecto a Internet.
>
>>>>
>>> El instalador de AMD pide expresamente Xorg hasta 1.10 que es el que usa
>>> Jessie. Stretch viene con Xorg 1.19
>> Entonces mala solución le veo.
>>
>> Pero no se sólo Xorg, también la versión del kernel. Estos son los
>> requisitos completos¹:
>>
>> ***
>> System Requirements
>> Before attempting to install the AMD Radeon Software Crimson Edition
>> Linux 15.11 Proprietary Graphics Driver, the following software must be
>> installed:
>>
>>      Xorg/Xserver 7.4 and above (up to 1.17)
>>      Linux kernel 2.6 or above (up to 3.19)
>>      glibc version 2.2 or 2.3
>>      POSIX Shared Memory (/dev/shm) support is required for 3D
>> applications
>>
>> NOTE: If a Linux 2.6.11 or newer kernel was built with CONFIG_AGP
>> enabled, the kernel AGP frontend is required to load the fglrx kernel
>> module. To identify whether your kernel with CONFIG_AGP enabled, look
>> for CONFIG_AGP=y in the kernel config file, or if the 'agpgart' module
>> is loaded
>> ***
>>
>
> Gracias por la info. Los deb FGLRX de Jessie fueron probados hasta el
> núcleo 4.2.
>
>> El kernel de Stretch es 4.9, tendrías que instalar una versión anterior
>> para poder compilar ese driver, de ahí mis malos augurios para la
>> combinación que buscas:-(
>>
>
> En la imagen en vivo no tuve problema para revertir Xorg a la versión de
> Jessie, pero los módulos de FGLRX no compilan bien y el problema puede
> ser porque parte del sistema está solo en modo lectura. Con otros
> módulos también dio problemas por esto último. APT no da problemas de
> dependencias por usar el núcleo 4.9 con fglrx-driver.
>
> Puedo probar es volver a revertir la imagen en vivo al Xorg de Jessie e
> instalar el binario de AMD, pero dudo que sea confiable porque parte del
> sistema está en modo solo lectura.
>
> Saludos,
>
> Julián
>
>> ¹<https://www.amd.com/en/support/kb/release-notes/rn-rad-lin-15-9#faq-Syst
>>
>> em-Requirements>
>>
>> Saludos,
>

--
Julian Daich <juli...@gmail.com>

Camaleón

unread,
Nov 30, 2020, 3:00:04 AM11/30/20
to
El 2020-11-29 a las 23:59 +0200, Julián Daich escribió:

> Logré actualizar a Strecht y conservar el controlador AMD reteniendo
> paquetes

(...)

> sudo apt update
> sudo apt upgrade
>
> Después de reinicio para ver que no haya problmeas
> sudo apt dist-upgrade
>
> Ahora arranca con los dos núcleos y el controlador Catalyst como quería.
>
> Solo un problemita. El núcleo 4.08 de Strecht no es compatible con
> xserever-xorg-input-vmmouse de Jessie y por ende con
> xserever-xorg-input-all. El reemplazo no se puede instalar por problemas de
> dependencias. Si instalo los dos paquetes de arriba me quedo solo con el
> núcleo 3.16 que no tiene soporte y si no los instalo da problemas solo si
> uso máquinas virtuales por lo que lo dejo así sin instalar.

Los metapaquetes tienen ese problema, que generan muchas dependencias, lo cual
es su función, por lo que si necesitas tener un sistema «fronkonstin» con
partes de distintos orígenes y versiones de paquetes, es mejor que no
instales metapquetes sino las versiones concretas.

«xserver-xorg-input-all» es un metapquete, que instala
«xserver-xorg-input-vmmouse» quizá de ahí el problema.

Un paquete del núcleo moderno no debería tener problemas con versiones
anteriores del servidor X o sus módulos. Quizá lo que te dé guerra es
manetener distintas versiones de «xserver-xorg-core», pero si no
necesitas esos paquetes «-input», siempre puedes optar por la solución
salomónica que es lo que has hecho: no instalarlos.

Saludos,

--
Camaleón

Julián Daich

unread,
Nov 30, 2020, 6:30:03 AM11/30/20
to


El 30/11/20 a las 9:56, Camaleón escribió:
> Los metapaquetes tienen ese problema, que generan muchas dependencias, lo cual
> es su función, por lo que si necesitas tener un sistema «fronkonstin» con
> partes de distintos orígenes y versiones de paquetes, es mejor que no
> instales metapquetes sino las versiones concretas.
>
Hola,

Eso se soluciona fáicl.
apt-mark manual <todas las dependencias del megapaquete que quieras
dejar y se autodesimstalan>

> «xserver-xorg-input-all» es un metapquete, que instala
> «xserver-xorg-input-vmmouse» quizá de ahí el problema.
>
> Un paquete del núcleo moderno no debería tener problemas con versiones
> anteriores del servidor X o sus módulos. Quizá lo que te dé guerra es
> manetener distintas versiones de «xserver-xorg-core», pero si no
> necesitas esos paquetes «-input», siempre puedes optar por la solución
> salomónica que es lo que has hecho: no instalarlos.

El mayor inconveniente parece es que se borra task-desktop que tiene
muchas dependencias, pero se soluciona con lo de arriba.
0 new messages