[opensuse-es] AMDGPU "no funciona" desde la última actualización
Hola :) El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona. La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional. Arrancando con "nomodeset" consigo tener un equipo funcional, pero no puedo bajar el brillo (está al máximo y quema los ojos que da gusto), el monitor externo no funciona, ... El HW es: Lenovo T495s AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx Esto es lo que dice lspci: 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev d2) Subsystem: Lenovo Device [17aa:5127] Kernel modules: amdgpu El comando inxi devuelve esto: # inxi -GxxSza System: Kernel: 5.7.7-1-default x86_64 bits: 64 compiler: gcc v: 10.1.1 parameters: BOOT_IMAGE=/boot/vmlinuz-5.7.7-1-default root=UUID=3fdb5281-9201-4189-8d53-73ed044bab6a resume=/dev/disk/by-id/nvme-WDC_PC_SN730_SDBQNTY-256G-1001_19451D805162-part2 nomodeset mitigations=off Console: tty 1 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20200717 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso vendor: Lenovo driver: N/A bus ID: 05:00.0 chip ID: 1002:15d8 Device-2: Chicony type: USB driver: uvcvideo bus ID: 4-2.1:4 chip ID: 04f2:b67c serial: <filter> Display: server: X.org 1.20.8 compositor: kwin_x11 driver: N/A note: display driver n/a FAILED: ati unloaded: fbdev,modesetting,radeon,vesa resolution: <xdpyinfo missing> OpenGL: renderer: llvmpipe (LLVM 10.0.0 256 bits) v: 3.3 Mesa 20.1.2 compat-v: 3.1 direct render: Yes Sí, tengo el driver amdgpu, el microcódigo amdgpu y el firmware amdgpu instalado. De hecho, es una de las cosas que se actualizaron el viernes. He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ... Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo.. Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :( Llevo todo el fin de semana buscando en Internet, pero no veo que la gente tenga ese problema. Veo foros y listas de hace tiempo que recomiendan lo mismo (nomodeset, que sí me funciona) o bien usar amdgpu.dc=1 ó 0 (o alguna otra opción de amdgpu) ... pero eso no me funciona. Si alguien más tiene este HW, que lo sepa de antemano. Si alguien ha conseguido resolver este problema ... se agradecen ideas ;) Gracias !!! Rafa -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona.
La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional.
Vaya.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo..
Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :(
Hay una especie de snapshots de TW en un servidor, no recuerdo el nombre. Como no uso TW no estoy al tanto del detalle. Creo que guardan cinco versiones. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXxVZmRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVmMsAnidamDI+zj9yHVlqH9n6 0hT2xryBAJ4g6QEBy8DPPbYKMGXkdbXQdqJNNA== =X8sX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
...
Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo..
Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :(
Hay una especie de snapshots de TW en un servidor, no recuerdo el nombre. Como no uso TW no estoy al tanto del detalle. Creo que guardan cinco versiones.
Mira aquí: https://review.tumbleweed.boombatower.com/about.html (No tengo todavía abierto el FF para mirar yo, estoy actualizando) Te voy a hacer un forward de dos mensajes de mi archivo. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXxVb2Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVXw8AnilnfyADAN5RyV+U3yMi E9PSPPqoAJ9mxXQ/EQyvOiAFRIBFFEEtet0tFQ== =+WJ3 -----END PGP SIGNATURE-----
Hola :)
On Mon, Jul 20, 2020 at 9:45 AM Carlos E. R.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
Eso es lo que me da rabia ... es como lo de systemd ... te obligan a usarlo. En casa ya he migrado un portátil a Gentoo que me permite elegir entre openrc y systemd ... No entiendo la "oligación" cuando es FLOSS y precisamente la F de Free viene a significar que puedes elegir ... Ahora RHEL 8 ... ha quitado KDE del repo oficial ... Esta semana migro el otro portátil a Gentoo o ArtixLinux y el PC lo mismo. No entiendo porqué tengo que usar lo que SUSE o Red Hat deciden que es lo mejor para ti. No NECESITO systemd. Igual que elijo my DE, mi navegador, mi cliente de correo, editor de textos, ... Si Gentoo, que tiene muuuucha menos gente "en plantilla" lo puede hacer (otras distros tbn) ... y NO tienen el presupuesto de SUSE ni Red Hat ... Sí, estoy protestando porque nos metimos en esto del FLOSS para tener una libre elección ... No me extraña que la gente se vaya a MacOS (que no me gusta nada), pero por lo menos no les venden esa falsa "libertad". El mundillo de Linux se está llenando de muchas tonterías últimamente (MHO). En otro portátil tengo FreeBSD y estoy encantado. Hacía mucho que no lo usaba ... y la verdad es que me va muy bien.
Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo..
Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :(
Hay una especie de snapshots de TW en un servidor, no recuerdo el nombre. Como no uso TW no estoy al tanto del detalle. Creo que guardan cinco versiones.
OK, gracias, buscaré :) Rafa -- 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
Hola :)
On Mon, Jul 20, 2020 at 10:10 AM Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
On Monday, 2020-07-20 at 10:45 +0200, Carlos E. R. wrote:
On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
...
Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo..
Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :(
Hay una especie de snapshots de TW en un servidor, no recuerdo el nombre. Como no uso TW no estoy al tanto del detalle. Creo que guardan cinco versiones.
Mira aquí:
https://review.tumbleweed.boombatower.com/about.html
(No tengo todavía abierto el FF para mirar yo, estoy actualizando)
Te voy a hacer un forward de dos mensajes de mi archivo.
Muchas gracias. Recibidos. Voy a mirarlos a ver si consigo solucionar esto. Rafa -- 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
Hola :)
On Mon, Jul 20, 2020 at 10:10 AM Carlos E. R.
(No tengo todavía abierto el FF para mirar yo, estoy actualizando)
Suerte ;)
Te voy a hacer un forward de dos mensajes de mi archivo.
http://download.opensuse.org/history/ En este enlace que me pasaste tienen la versión anterior del fimware y del microcódigo. Lo he descargado, he hecho el "downgrade" y ... funciona perfectamente. Ya puedo controlar el brill, no se cuelga al arrancar, ... Muchas gracias !!! Rafa -- 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 20/07/2020 13.28, Rafa Griman wrote:
Hola :)
On Mon, Jul 20, 2020 at 10:10 AM Carlos E. R. <> wrote: [...]
(No tengo todavía abierto el FF para mirar yo, estoy actualizando)
Suerte ;)
Ah, sin problemas, estoy en Leap 15.1 - me gusta la vida más tranquila ;-)
Te voy a hacer un forward de dos mensajes de mi archivo.
http://download.opensuse.org/history/
En este enlace que me pasaste tienen la versión anterior del fimware y del microcódigo. Lo he descargado, he hecho el "downgrade" y ... funciona perfectamente. Ya puedo controlar el brill, no se cuelga al arrancar, ...
Muchas gracias !!!
Fantástico! :-D Hala, ahora un bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 20/07/2020 12.30, Rafa Griman wrote:
Hola :)
On Mon, Jul 20, 2020 at 9:45 AM Carlos E. R.
wrote: [...] He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
Eso es lo que me da rabia ... es como lo de systemd ... te obligan a usarlo. En casa ya he migrado un portátil a Gentoo que me permite elegir entre openrc y systemd ... No entiendo la "oligación" cuando es FLOSS y precisamente la F de Free viene a significar que puedes elegir ...
Bueno, el systemd no me va mal a mí. Ni bien ni mal. Sigo el camino de mínima resistencia. Cuando hay alguna cosa que no funciona, entonces me cabreo, pero si no, pues no me molesto en cambiar de distro. Prefiero lo que entiendo y estoy cómodo. El Leap no me gusta: conforme el decimal de la versión se agranda se va volviendo más obsoleta. Y en algunas aplicaciones como el Shotwell, que por ser parte de gnome es core y no lo actualizan, y se nota. Pero el TW me gusta menos.
Ahora RHEL 8 ... ha quitado KDE del repo oficial ...
Contro.
Esta semana migro el otro portátil a Gentoo o ArtixLinux y el PC lo mismo. No entiendo porqué tengo que usar lo que SUSE o Red Hat deciden que es lo mejor para ti. No NECESITO systemd. Igual que elijo my DE, mi navegador, mi cliente de correo, editor de textos, ...
Si Gentoo, que tiene muuuucha menos gente "en plantilla" lo puede hacer (otras distros tbn) ... y NO tienen el presupuesto de SUSE ni Red Hat ...
A lo mejor tienen menos voluntarios. Es que lo dijeron, si hay voluntarios para seguir con initd, que lo hagan, no hay problema. Lo mismo que hay un grupo que mantiene el KDE3. El Gnome ahora necesita systemd.
Sí, estoy protestando porque nos metimos en esto del FLOSS para tener una libre elección ... No me extraña que la gente se vaya a MacOS (que no me gusta nada), pero por lo menos no les venden esa falsa "libertad".
El mundillo de Linux se está llenando de muchas tonterías últimamente (MHO). En otro portátil tengo FreeBSD y estoy encantado. Hacía mucho que no lo usaba ... y la verdad es que me va muy bien.
Je. ¿Te has enterado de la trifulca en el kernel por lo del lenguaje inclusivo? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
El lun., 20 jul. 2020 a las 5:01, Rafa Griman (
Hola :)
El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona.
La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional.
Arrancando con "nomodeset" consigo tener un equipo funcional, pero no puedo bajar el brillo (está al máximo y quema los ojos que da gusto), el monitor externo no funciona, ...
El HW es: Lenovo T495s AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx
Esto es lo que dice lspci:
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev d2) Subsystem: Lenovo Device [17aa:5127] Kernel modules: amdgpu
El comando inxi devuelve esto:
# inxi -GxxSza System: Kernel: 5.7.7-1-default x86_64 bits: 64 compiler: gcc v: 10.1.1 parameters: BOOT_IMAGE=/boot/vmlinuz-5.7.7-1-default root=UUID=3fdb5281-9201-4189-8d53-73ed044bab6a resume=/dev/disk/by-id/nvme-WDC_PC_SN730_SDBQNTY-256G-1001_19451D805162-part2 nomodeset mitigations=off Console: tty 1 wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20200717 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Picasso vendor: Lenovo driver: N/A bus ID: 05:00.0 chip ID: 1002:15d8 Device-2: Chicony type: USB driver: uvcvideo bus ID: 4-2.1:4 chip ID: 04f2:b67c serial: <filter> Display: server: X.org 1.20.8 compositor: kwin_x11 driver: N/A note: display driver n/a FAILED: ati unloaded: fbdev,modesetting,radeon,vesa resolution: <xdpyinfo missing> OpenGL: renderer: llvmpipe (LLVM 10.0.0 256 bits) v: 3.3 Mesa 20.1.2 compat-v: 3.1 direct render: Yes
Sí, tengo el driver amdgpu, el microcódigo amdgpu y el firmware amdgpu instalado. De hecho, es una de las cosas que se actualizaron el viernes.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
Yep, he probado a arrancar con el kernel anterior, pero ocurre lo mismo..
Voy a ver si en el FTP/repo de SUSE puedo encontrar versiones antiguas de esos paquetes. Si la shay, pruebo esta noche porque es el portátil del trabajo y ahora no puedo andar haciendo pruebas ... :(
Llevo todo el fin de semana buscando en Internet, pero no veo que la gente tenga ese problema. Veo foros y listas de hace tiempo que recomiendan lo mismo (nomodeset, que sí me funciona) o bien usar amdgpu.dc=1 ó 0 (o alguna otra opción de amdgpu) ... pero eso no me funciona.
Si alguien más tiene este HW, que lo sepa de antemano. Si alguien ha conseguido resolver este problema ... se agradecen ideas ;)
¡No me digas que tienes Snapper desactivado!
Por si lo tienes activado, lo más sencillo es volver el sistema a un
snapshot anterior:
https://en.opensuse.org/openSUSE:Snapper_Tutorial
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref...
https://www.linux.com/topic/desktop/how-easily-roll-back-changes-snapper/
Yo no actualicé a la última versión de Tumbleweed, porque leí que
firefox elimina los bookmarks.
Parece que este fin de semana fue un día fatídico para la informática:
https://www.baenegocios.com/negocios/Hackearon-los-servidores-de-Telecom-202...
Un ataque Ransomware a través de Office 365, que al estar en un
dominio público de microsoft no tiene la protección de los propios
firewalls.
El comando inxi -GxxSza
System: Kernel: 5.7.7-1-default x86_64 bits: 64 compiler: gcc v: 10.1.1
parameters: BOOT_IMAGE=/boot/vmlinuz-5.7.7-1-default
root=UUID=d58a1c43-4793-43b0-9421-c1c5bc361fe8 splash=silent
resume=/dev/disk/by-id/ata-WDC_WD10EZEX-60WN4A0_WD-WCC6Y1CPU7TZ-part4
quiet
Desktop: KDE Plasma 5.19.3 tk: Qt 5.15.0 wm: kwin_x11 dm:
SDDM Distro: openSUSE Tumbleweed 20200714
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere
[Radeon RX 470/480/570/570X/580/580X/590]
vendor: Sapphire Limited Nitro+ driver: amdgpu v: kernel
bus ID: 01:00.0 chip ID: 1002:67df
Display: x11 server: X.org 1.20.8 compositor: kwin_x11
driver: amdgpu FAILED: ati
unloaded: fbdev,modesetting,radeon,vesa resolution:
<xdpyinfo missing>
OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM
3.37.0 5.7.7-1-default LLVM 10.0.0) v: 4.6 Mesa 20.1.2
direct render: Yes
El resultado de lsmod
Module Size Used by
fuse 143360 5
xt_MASQUERADE 20480 1
xt_tcpudp 20480 3
ip6t_REJECT 16384 11
nf_reject_ipv6 20480 1 ip6t_REJECT
ip6t_rpfilter 16384 1
ipt_REJECT 16384 2
nf_reject_ipv4 16384 1 ipt_REJECT
xt_conntrack 16384 12
ebtable_nat 16384 1
ebtable_broute 16384 1
ip6table_nat 16384 1
ip6table_mangle 16384 1
ip6table_raw 16384 1
ip6table_security 16384 1
iptable_nat 16384 1
nf_nat 53248 3 ip6table_nat,iptable_nat,xt_MASQUERADE
iptable_mangle 16384 1
iptable_raw 16384 1
iptable_security 16384 1
nf_conntrack 176128 3 xt_conntrack,nf_nat,xt_MASQUERADE
nf_defrag_ipv6 24576 1 nf_conntrack
nf_defrag_ipv4 16384 1 nf_conntrack
rfkill 28672 3
ip_set 57344 0
nfnetlink 16384 1 ip_set
ebtable_filter 16384 1
ebtables 40960 3 ebtable_nat,ebtable_filter,ebtable_broute
ip6table_filter 16384 1
ip6_tables 36864 7
ip6table_filter,ip6table_raw,ip6table_nat,ip6table_mangle,ip6table_security
iptable_filter 16384 1
ip_tables 32768 5
iptable_filter,iptable_security,iptable_raw,iptable_nat,iptable_mangle
x_tables 53248 17
ebtables,ip6table_filter,xt_conntrack,ip6table_raw,iptable_filter,iptable_security,ip6t_rpfilter,xt_tcpudp,ip6_tables,ipt_REJECT,iptable_raw,ip_tables,ip6table_mangle,ip6table_security,xt_MASQUERADE,ip6t_REJECT,iptable_mangle
bpfilter 36864 0
xfrm_user 45056 2
xfrm_algo 16384 1 xfrm_user
af_packet 61440 6
twofish_generic 20480 0
twofish_avx_x86_64 53248 0
twofish_x86_64_3way 28672 1 twofish_avx_x86_64
twofish_x86_64 16384 2 twofish_x86_64_3way,twofish_avx_x86_64
twofish_common 24576 4
twofish_x86_64,twofish_generic,twofish_x86_64_3way,twofish_avx_x86_64
serpent_avx_x86_64 49152 0
serpent_sse2_x86_64 53248 0
serpent_generic 32768 2 serpent_sse2_x86_64,serpent_avx_x86_64
blowfish_generic 16384 0
blowfish_x86_64 24576 0
blowfish_common 20480 2 blowfish_generic,blowfish_x86_64
cast5_avx_x86_64 49152 0
cast5_generic 24576 1 cast5_avx_x86_64
cast_common 16384 2 cast5_generic,cast5_avx_x86_64
cdc_ether 24576 0
usbnet 53248 1 cdc_ether
des_generic 16384 0
libdes 24576 1 des_generic
mii 16384 1 usbnet
algif_skcipher 16384 0
camellia_generic 32768 0
camellia_aesni_avx_x86_64 28672 0
camellia_x86_64 53248 1 camellia_aesni_avx_x86_64
xcbc 16384 0
md4 16384 0
algif_hash 16384 0
af_alg 32768 2 algif_hash,algif_skcipher
nct6775 81920 0
dmi_sysfs 20480 0
hwmon_vid 16384 1 nct6775
msr 16384 0
edac_mce_amd 32768 0
kvm_amd 114688 0
ccp 114688 1 kvm_amd
kvm 843776 1 kvm_amd
snd_hda_codec_hdmi 73728 1
irqbypass 16384 1 kvm
snd_hda_intel 57344 2
snd_intel_dspcfg 28672 1 snd_hda_intel
snd_hda_codec 167936 2 snd_hda_codec_hdmi,snd_hda_intel
joydev 28672 0
crct10dif_pclmul 16384 1
crc32_pclmul 16384 0
snd_ctxfi 143360 3
ghash_clmulni_intel 16384 0
snd_hda_core 110592 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_hwdep 16384 1 snd_hda_codec
aesni_intel 368640 0
snd_pcm 172032 5
snd_ctxfi,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
crypto_simd 16384 6
camellia_aesni_avx_x86_64,serpent_sse2_x86_64,aesni_intel,serpent_avx_x86_64,cast5_avx_x86_64,twofish_avx_x86_64
snd_timer 49152 1 snd_pcm
wmi_bmof 16384 0
cryptd 28672 2 crypto_simd,ghash_clmulni_intel
r8169 106496 0
sp5100_tco 20480 0
glue_helper 16384 7
camellia_aesni_avx_x86_64,camellia_x86_64,twofish_x86_64_3way,serpent_sse2_x86_64,aesni_intel,serpent_avx_x86_64,twofish_avx_x86_64
snd 114688 17
snd_ctxfi,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
pcspkr 16384 0
k10temp 16384 0
fam15h_power 16384 0
i2c_piix4 28672 0
acpi_cpufreq 28672 0
realtek 24576 1
libphy 147456 2 r8169,realtek
tiny_power_button 16384 0
button 24576 0
soundcore 16384 1 snd
xfs 1544192 1
hid_generic 16384 0
usbhid 65536 2
uas 32768 0
usb_storage 81920 1 uas
btrfs 1609728 1
blake2b_generic 20480 0
libcrc32c 16384 4 nf_conntrack,nf_nat,btrfs,xfs
xor 24576 1 btrfs
amdgpu 5959680 20
raid6_pq 122880 1 btrfs
amd_iommu_v2 20480 1 amdgpu
gpu_sched 40960 1 amdgpu
i2c_algo_bit 16384 1 amdgpu
ttm 118784 1 amdgpu
ohci_pci 20480 0
drm_kms_helper 262144 1 amdgpu
crc32c_intel 24576 2
syscopyarea 16384 1 drm_kms_helper
sysfillrect 16384 1 drm_kms_helper
xhci_pci 20480 0
sysimgblt 16384 1 drm_kms_helper
fb_sys_fops 16384 1 drm_kms_helper
xhci_hcd 299008 1 xhci_pci
cec 61440 1 drm_kms_helper
ohci_hcd 61440 1 ohci_pci
rc_core 61440 1 cec
ehci_pci 20480 0
ata_generic 16384 0
ehci_hcd 102400 1 ehci_pci
drm 581632 17 gpu_sched,drm_kms_helper,amdgpu,ttm
serio_raw 20480 0
usbcore 335872 13
xhci_hcd,ohci_hcd,ehci_pci,usbnet,usbhid,usb_storage,ehci_hcd,xhci_pci,ohci_pci,cdc_ether,uas
sr_mod 28672 0
pata_atiixp 16384 0
cdrom 81920 1 sr_mod
wmi 32768 1 wmi_bmof
l2tp_ppp 32768 0
l2tp_netlink 24576 1 l2tp_ppp
l2tp_core 40960 2 l2tp_ppp,l2tp_netlink
ip6_udp_tunnel 16384 1 l2tp_core
udp_tunnel 16384 1 l2tp_core
pppox 16384 1 l2tp_ppp
ppp_generic 49152 2 pppox,l2tp_ppp
slhc 20480 1 ppp_generic
sg 45056 0
dm_multipath 40960 0
dm_mod 167936 1 dm_multipath
scsi_dh_rdac 16384 0
scsi_dh_emc 16384 0
scsi_dh_alua 20480 0
Si te sirve de algo, te dejo el resultado de dmesg:
[ 0.117679] ftrace: allocated 167 pages with 5 groups
[ 0.117790] rcu: Hierarchical RCU implementation.
[ 0.117790] rcu: RCU event tracing is enabled.
[ 0.117791] rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8.
[ 0.117792] Tasks RCU enabled.
[ 0.117793] rcu: RCU calculated value of scheduler-enlistment delay
is 25 jiffies.
[ 0.117794] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[ 0.121638] NR_IRQS: 33024, nr_irqs: 488, preallocated irqs: 16
[ 0.121868] spurious 8259A interrupt: IRQ7.
[ 0.121881] Console: colour dummy device 80x25
[ 0.121885] printk: console [tty0] enabled
[ 0.121900] ACPI: Core revision 20200326
[ 0.121984] clocksource: hpet: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 133484873504 ns
[ 0.121997] APIC: Switch to symmetric I/O mode setup
[ 0.122344] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.142000] clocksource: tsc-early: mask: 0xffffffffffffffff
max_cycles: 0x2e3773c9d9f, max_idle_ns: 440795331739 ns
[ 0.142003] Calibrating delay loop (skipped), value calculated
using timer frequency.. 6412.55 BogoMIPS (lpj=12825108)
[ 0.142005] pid_max: default: 32768 minimum: 301
[ 0.142035] LSM: Security Framework initializing
[ 0.142059] AppArmor: AppArmor initialized
[ 0.142138] Mount-cache hash table entries: 32768 (order: 6, 262144
bytes, linear)
[ 0.142183] Mountpoint-cache hash table entries: 32768 (order: 6,
262144 bytes, linear)
[ 0.142420] LVT offset 1 assigned for vector 0xf9
[ 0.142424] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[ 0.142425] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
[ 0.142428] Spectre V1 : Mitigation: usercopy/swapgs barriers and
__user pointer sanitization
[ 0.142429] Spectre V2 : Mitigation: Full AMD retpoline
[ 0.142430] Spectre V2 : Spectre v2 / SpectreRSB mitigation:
Filling RSB on context switch
[ 0.142432] Spectre V2 : mitigation: Enabling conditional Indirect
Branch Prediction Barrier
[ 0.142432] Spectre V2 : User space: Vulnerable
[ 0.142434] Speculative Store Bypass: Mitigation: Speculative Store
Bypass disabled via prctl and seccomp
[ 0.142690] Freeing SMP alternatives memory: 36K
[ 0.257742] smpboot: CPU0: AMD FX-8320E Eight-Core Processor
(family: 0x15, model: 0x2, stepping: 0x0)
[ 0.257865] Performance Events: Fam15h core perfctr, AMD PMU driver.
[ 0.257869] ... version: 0
[ 0.257869] ... bit width: 48
[ 0.257870] ... generic registers: 6
[ 0.257870] ... value mask: 0000ffffffffffff
[ 0.257871] ... max period: 00007fffffffffff
[ 0.257871] ... fixed-purpose events: 0
[ 0.257872] ... event mask: 000000000000003f
[ 0.257908] rcu: Hierarchical SRCU implementation.
[ 0.258001] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[ 0.258001] smp: Bringing up secondary CPUs ...
[ 0.258001] x86: Booting SMP configuration:
[ 0.258001] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7
[ 0.318057] smp: Brought up 1 node, 8 CPUs
[ 0.318057] smpboot: Max logical packages: 1
[ 0.318057] smpboot: Total of 8 processors activated (51300.43 BogoMIPS)
[ 0.418479] node 0 initialised, 3255059 pages in 96ms
[ 0.418773] devtmpfs: initialized
[ 0.418773] x86/mm: Memory block size: 128MB
[ 0.419930] PM: Registering ACPI NVS region [mem
0xc7fb0000-0xc7fdffff] (196608 bytes)
[ 0.419930] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.419930] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[ 0.422046] pinctrl core: initialized pinctrl subsystem
[ 0.422135] PM: RTC time: 08:33:50, date: 2020-07-20
[ 0.422136] thermal_sys: Registered thermal governor 'fair_share'
[ 0.422137] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.422137] thermal_sys: Registered thermal governor 'step_wise'
[ 0.422138] thermal_sys: Registered thermal governor 'user_space'
[ 0.422286] NET: Registered protocol family 16
[ 0.422354] audit: initializing netlink subsys (disabled)
[ 0.422361] audit: type=2000 audit(1595234030.300:1):
state=initialized audit_enabled=0 res=1
[ 0.422361] cpuidle: using governor ladder
[ 0.422361] cpuidle: using governor menu
[ 0.422361] ACPI: bus type PCI registered
[ 0.422361] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.422361] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.422361] PCI: not using MMCONFIG
[ 0.422361] PCI: Using configuration type 1 for base access
[ 0.422361] PCI: Using configuration type 1 for extended access
[ 0.422966] mtrr: your CPUs had inconsistent variable MTRR settings
[ 0.422966] mtrr: probably your BIOS does not setup all CPUs.
[ 0.422967] mtrr: corrected configuration.
[ 0.424547] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[ 0.424547] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[ 0.426078] ACPI: Added _OSI(Module Device)
[ 0.426079] ACPI: Added _OSI(Processor Device)
[ 0.426080] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.426080] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.426081] ACPI: Added _OSI(Linux-Dell-Video)
[ 0.426082] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[ 0.426083] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[ 0.433892] ACPI: 2 ACPI AML tables successfully acquired and loaded
[ 0.435468] ACPI: Interpreter enabled
[ 0.435492] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.435493] ACPI: Using IOAPIC for interrupt routing
[ 0.435579] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.436844] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved
in ACPI motherboard resources
[ 0.436855] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug
[ 0.437183] ACPI: Enabled 7 GPEs in block 00 to 1F
[ 0.445453] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.445458] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM
ClockPM Segments MSI EDR HPX-Type3]
[ 0.445762] acpi PNP0A03:00: _OSC: platform does not support
[PCIeHotplug SHPCHotplug PME LTR DPC]
[ 0.446055] acpi PNP0A03:00: _OSC: OS now controls [AER PCIeCapability]
[ 0.446396] PCI host bridge to bus 0000:00
[ 0.446398] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
[ 0.446400] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
[ 0.446401] pci_bus 0000:00: root bus resource [mem
0x000a0000-0x000bffff window]
[ 0.446402] pci_bus 0000:00: root bus resource [mem
0x000d0000-0x000dffff window]
[ 0.446403] pci_bus 0000:00: root bus resource [mem
0xc8000000-0xdfffffff window]
[ 0.446404] pci_bus 0000:00: root bus resource [mem
0xf0000000-0xfebfffff window]
[ 0.446406] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 0.446416] pci 0000:00:00.0: [1022:9600] type 00 class 0x060000
[ 0.446544] pci 0000:00:02.0: [1022:9603] type 01 class 0x060400
[ 0.446564] pci 0000:00:02.0: enabling Extended Tags
[ 0.446589] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[ 0.446711] pci 0000:00:06.0: [1022:9606] type 01 class 0x060400
[ 0.446730] pci 0000:00:06.0: enabling Extended Tags
[ 0.446753] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
[ 0.446861] pci 0000:00:07.0: [1022:9607] type 01 class 0x060400
[ 0.446880] pci 0000:00:07.0: enabling Extended Tags
[ 0.446903] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[ 0.447010] pci 0000:00:09.0: [1022:9608] type 01 class 0x060400
[ 0.447029] pci 0000:00:09.0: enabling Extended Tags
[ 0.447052] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[ 0.447159] pci 0000:00:0a.0: [1022:9609] type 01 class 0x060400
[ 0.447178] pci 0000:00:0a.0: enabling Extended Tags
[ 0.447201] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
[ 0.447317] pci 0000:00:11.0: [1002:4391] type 00 class 0x010601
[ 0.447338] pci 0000:00:11.0: reg 0x10: [io 0xa000-0xa007]
[ 0.447346] pci 0000:00:11.0: reg 0x14: [io 0x9000-0x9003]
[ 0.447355] pci 0000:00:11.0: reg 0x18: [io 0x8000-0x8007]
[ 0.447363] pci 0000:00:11.0: reg 0x1c: [io 0x7000-0x7003]
[ 0.447372] pci 0000:00:11.0: reg 0x20: [io 0x6000-0x600f]
[ 0.447380] pci 0000:00:11.0: reg 0x24: [mem 0xf7effc00-0xf7efffff]
[ 0.447511] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310
[ 0.447528] pci 0000:00:12.0: reg 0x10: [mem 0xf7efe000-0xf7efefff]
[ 0.447671] pci 0000:00:12.1: [1002:4398] type 00 class 0x0c0310
[ 0.447688] pci 0000:00:12.1: reg 0x10: [mem 0xf7efd000-0xf7efdfff]
[ 0.447833] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320
[ 0.447853] pci 0000:00:12.2: reg 0x10: [mem 0xf7eff800-0xf7eff8ff]
[ 0.447931] pci 0000:00:12.2: supports D1 D2
[ 0.447932] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[ 0.448035] pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310
[ 0.448051] pci 0000:00:13.0: reg 0x10: [mem 0xf7efc000-0xf7efcfff]
[ 0.448198] pci 0000:00:13.1: [1002:4398] type 00 class 0x0c0310
[ 0.448215] pci 0000:00:13.1: reg 0x10: [mem 0xf7efb000-0xf7efbfff]
[ 0.448360] pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320
[ 0.448380] pci 0000:00:13.2: reg 0x10: [mem 0xf7eff400-0xf7eff4ff]
[ 0.448457] pci 0000:00:13.2: supports D1 D2
[ 0.448458] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[ 0.448567] pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500
[ 0.448741] pci 0000:00:14.1: [1002:439c] type 00 class 0x01018a
[ 0.448760] pci 0000:00:14.1: reg 0x10: [io 0x0000-0x0007]
[ 0.448768] pci 0000:00:14.1: reg 0x14: [io 0x0000-0x0003]
[ 0.448776] pci 0000:00:14.1: reg 0x18: [io 0x0000-0x0007]
[ 0.448785] pci 0000:00:14.1: reg 0x1c: [io 0x0000-0x0003]
[ 0.448793] pci 0000:00:14.1: reg 0x20: [io 0xff00-0xff0f]
[ 0.448812] pci 0000:00:14.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]
[ 0.448813] pci 0000:00:14.1: legacy IDE quirk: reg 0x14: [io 0x03f6]
[ 0.448814] pci 0000:00:14.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]
[ 0.448815] pci 0000:00:14.1: legacy IDE quirk: reg 0x1c: [io 0x0376]
[ 0.448928] pci 0000:00:14.3: [1002:439d] type 00 class 0x060100
[ 0.449081] pci 0000:00:14.4: [1002:4384] type 01 class 0x060401
[ 0.449211] pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310
[ 0.449228] pci 0000:00:14.5: reg 0x10: [mem 0xf7efa000-0xf7efafff]
[ 0.449372] pci 0000:00:18.0: [1022:1600] type 00 class 0x060000
[ 0.449452] pci 0000:00:18.1: [1022:1601] type 00 class 0x060000
[ 0.449525] pci 0000:00:18.2: [1022:1602] type 00 class 0x060000
[ 0.449600] pci 0000:00:18.3: [1022:1603] type 00 class 0x060000
[ 0.449679] pci 0000:00:18.4: [1022:1604] type 00 class 0x060000
[ 0.449752] pci 0000:00:18.5: [1022:1605] type 00 class 0x060000
[ 0.449866] pci 0000:01:00.0: [1002:67df] type 00 class 0x030000
[ 0.449889] pci 0000:01:00.0: reg 0x10: [mem 0xd0000000-0xdfffffff
64bit pref]
[ 0.449898] pci 0000:01:00.0: reg 0x18: [mem 0xcfe00000-0xcfffffff
64bit pref]
[ 0.449904] pci 0000:01:00.0: reg 0x20: [io 0xb000-0xb0ff]
[ 0.449910] pci 0000:01:00.0: reg 0x24: [mem 0xf7fc0000-0xf7ffffff]
[ 0.449916] pci 0000:01:00.0: reg 0x30: [mem 0xf7fa0000-0xf7fbffff pref]
[ 0.449921] pci 0000:01:00.0: enabling Extended Tags
[ 0.449978] pci 0000:01:00.0: supports D1 D2
[ 0.449979] pci 0000:01:00.0: PME# supported from D1 D2 D3hot D3cold
[ 0.450028] pci 0000:01:00.0: 64.000 Gb/s available PCIe bandwidth,
limited by 5.0 GT/s PCIe x16 link at 0000:00:02.0 (capable of 126.016
Gb/s with 8.0 GT/s PCIe x16 link)
[ 0.450070] pci 0000:01:00.1: [1002:aaf0] type 00 class 0x040300
[ 0.450089] pci 0000:01:00.1: reg 0x10: [mem 0xf7f9c000-0xf7f9ffff 64bit]
[ 0.450118] pci 0000:01:00.1: enabling Extended Tags
[ 0.450159] pci 0000:01:00.1: supports D1 D2
[ 0.450246] pci 0000:00:02.0: PCI bridge to [bus 01]
[ 0.450249] pci 0000:00:02.0: bridge window [io 0xb000-0xbfff]
[ 0.450251] pci 0000:00:02.0: bridge window [mem 0xf7f00000-0xf7ffffff]
[ 0.450254] pci 0000:00:02.0: bridge window [mem
0xcfe00000-0xdfffffff 64bit pref]
[ 0.450294] pci 0000:02:00.0: [1102:000b] type 00 class 0x040300
[ 0.450322] pci 0000:02:00.0: reg 0x10: [mem 0xfe9f0000-0xfe9fffff 64bit]
[ 0.450336] pci 0000:02:00.0: reg 0x18: [mem 0xfe600000-0xfe7fffff 64bit]
[ 0.450350] pci 0000:02:00.0: reg 0x20: [mem 0xf8000000-0xfbffffff 64bit]
[ 0.462027] pci 0000:00:06.0: PCI bridge to [bus 02]
[ 0.462031] pci 0000:00:06.0: bridge window [mem 0xf8000000-0xfe9fffff]
[ 0.462075] pci 0000:03:00.0: [1b21:0612] type 00 class 0x010601
[ 0.462091] pci 0000:03:00.0: reg 0x10: [io 0xd800-0xd807]
[ 0.462098] pci 0000:03:00.0: reg 0x14: [io 0xd400-0xd403]
[ 0.462105] pci 0000:03:00.0: reg 0x18: [io 0xd000-0xd007]
[ 0.462112] pci 0000:03:00.0: reg 0x1c: [io 0xc800-0xc803]
[ 0.462119] pci 0000:03:00.0: reg 0x20: [io 0xc400-0xc41f]
[ 0.462126] pci 0000:03:00.0: reg 0x24: [mem 0xfeaffc00-0xfeaffdff]
[ 0.462237] pci 0000:00:07.0: PCI bridge to [bus 03]
[ 0.462240] pci 0000:00:07.0: bridge window [io 0xc000-0xdfff]
[ 0.462242] pci 0000:00:07.0: bridge window [mem 0xfea00000-0xfeafffff]
[ 0.462281] pci 0000:04:00.0: [1b6f:7052] type 00 class 0x0c0330
[ 0.462305] pci 0000:04:00.0: reg 0x10: [mem 0xfebf8000-0xfebfffff 64bit]
[ 0.462348] pci 0000:04:00.0: enabling Extended Tags
[ 0.462398] pci 0000:04:00.0: supports D1 D2
[ 0.462399] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.462475] pci 0000:00:09.0: PCI bridge to [bus 04]
[ 0.462478] pci 0000:00:09.0: bridge window [mem 0xfeb00000-0xfebfffff]
[ 0.462521] pci 0000:05:00.0: [10ec:8168] type 00 class 0x020000
[ 0.462542] pci 0000:05:00.0: reg 0x10: [io 0xe800-0xe8ff]
[ 0.462561] pci 0000:05:00.0: reg 0x18: [mem 0xf6fff000-0xf6ffffff
64bit pref]
[ 0.462573] pci 0000:05:00.0: reg 0x20: [mem 0xf6ff8000-0xf6ffbfff
64bit pref]
[ 0.462643] pci 0000:05:00.0: supports D1 D2
[ 0.462644] pci 0000:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 0.462736] pci 0000:00:0a.0: PCI bridge to [bus 05]
[ 0.462739] pci 0000:00:0a.0: bridge window [io 0xe000-0xefff]
[ 0.462743] pci 0000:00:0a.0: bridge window [mem
0xf6f00000-0xf6ffffff 64bit pref]
[ 0.462753] pci_bus 0000:06: extended config space not accessible
[ 0.462812] pci 0000:00:14.4: PCI bridge to [bus 06] (subtractive decode)
[ 0.462820] pci 0000:00:14.4: bridge window [io 0x0000-0x0cf7
window] (subtractive decode)
[ 0.462822] pci 0000:00:14.4: bridge window [io 0x0d00-0xffff
window] (subtractive decode)
[ 0.462823] pci 0000:00:14.4: bridge window [mem
0x000a0000-0x000bffff window] (subtractive decode)
[ 0.462824] pci 0000:00:14.4: bridge window [mem
0x000d0000-0x000dffff window] (subtractive decode)
[ 0.462825] pci 0000:00:14.4: bridge window [mem
0xc8000000-0xdfffffff window] (subtractive decode)
[ 0.462826] pci 0000:00:14.4: bridge window [mem
0xf0000000-0xfebfffff window] (subtractive decode)
[ 0.463774] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 10 11 12 14
15) *0, disabled.
[ 0.463834] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 11 12 14
15) *0, disabled.
[ 0.463894] ACPI: PCI Interrupt Link [LNKC] (IRQs 10 12 14 15) *0, disabled.
[ 0.463953] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 14
15) *0, disabled.
[ 0.464012] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 10 11 12 14 15)
*0, disabled.
[ 0.464070] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 10 11 12 14 15)
*0, disabled.
[ 0.464128] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 10 11 12 14 15)
*0, disabled.
[ 0.464185] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14
15) *0, disabled.
[ 0.464349] iommu: Default domain type: Passthrough
[ 0.464349] pci 0000:01:00.0: vgaarb: setting as boot VGA device
[ 0.464349] pci 0000:01:00.0: vgaarb: VGA device added:
decodes=io+mem,owns=io+mem,locks=none
[ 0.464349] pci 0000:01:00.0: vgaarb: bridge control possible
[ 0.464349] vgaarb: loaded
[ 0.464349] SCSI subsystem initialized
[ 0.464349] libata version 3.00 loaded.
[ 0.464349] pps_core: LinuxPPS API ver. 1 registered
[ 0.464349] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti
Hola :)
On Mon, Jul 20, 2020 at 12:47 PM Carlos E. R.
On 20/07/2020 12.30, Rafa Griman wrote:
Hola :)
On Mon, Jul 20, 2020 at 9:45 AM Carlos E. R.
wrote: [...] He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
Eso es lo que me da rabia ... es como lo de systemd ... te obligan a usarlo. En casa ya he migrado un portátil a Gentoo que me permite elegir entre openrc y systemd ... No entiendo la "oligación" cuando es FLOSS y precisamente la F de Free viene a significar que puedes elegir ...
Bueno, el systemd no me va mal a mí. Ni bien ni mal. Sigo el camino de mínima resistencia. Cuando hay alguna cosa que no funciona, entonces me cabreo, pero si no, pues no me molesto en cambiar de distro. Prefiero lo que entiendo y estoy cómodo.
No soy anti-systemd, que no se me malinterprete. Lo que pasa es que no lo necesito y es que toma control de todo ... es como un mini OS. Sí, ya ... es modular y puedes instalar lo que quieras ... una porra. Prueba a desinstalar cosas del systemd y verás ... Si lo compilas tú a pelo sí, decides lo que entra y lo que no, pero en una distro hecha ... Lo que digo es que me den la opción de usarlo o no. Hay casos en los que va bien y no lo veo mal. Pero que te lo fuercen porque sí ...
El Leap no me gusta: conforme el decimal de la versión se agranda se va volviendo más obsoleta. Y en algunas aplicaciones como el Shotwell, que por ser parte de gnome es core y no lo actualizan, y se nota.
Pero el TW me gusta menos.
Yo uso el TW porque el equipo tiene una CPU AMD moderna y si no estás a la última ... hay cosas que no te van a funcionar o recibes errores y es un rollo. Claro que al ser TW ... corres el peligro de que algunas cosas dejen de funcionar. Hace 1 mes me dejó de funcionar el NVMe ... gracios a Dios era cosa del kernel y pude arrancar con el kernel anterior. Luego lo solucionaron.
Ahora RHEL 8 ... ha quitado KDE del repo oficial ...
Contro.
Sip, en teoría lo puedes instalar mediante EPEL Playground. Pero es lo que digo: ellos deciden y te aguantas. Si deciden que el editor por defecto es nano y la shell es sh ... pues es lo que hay. Mañana te dicen que sólo soportan AMD o sólo soportan NVIDIA ... Ya, estoy exagerando, pero es para que se entienda. Tampoco pido que soporten todo o que puedas elegir entre 50 opciones. Lo que digo es que tengas al menos 2 para elegir.
Esta semana migro el otro portátil a Gentoo o ArtixLinux y el PC lo mismo. No entiendo porqué tengo que usar lo que SUSE o Red Hat deciden que es lo mejor para ti. No NECESITO systemd. Igual que elijo my DE, mi navegador, mi cliente de correo, editor de textos, ...
Si Gentoo, que tiene muuuucha menos gente "en plantilla" lo puede hacer (otras distros tbn) ... y NO tienen el presupuesto de SUSE ni Red Hat ...
A lo mejor tienen menos voluntarios. Es que lo dijeron, si hay voluntarios para seguir con initd, que lo hagan, no hay problema. Lo mismo que hay un grupo que mantiene el KDE3.
El Gnome ahora necesita systemd.
Sí, eso es una decisión que forzó el pollo ese de Systemd. Eso es otra cosa que no entiendo: algunas dependencias forzadas. GNOME ha estado años sin systemd ... de pronto no funciona si no tienes systemd. Ya, ya me sé la respuesta marketiniana y de PR: es que systemd es mejor y te hace la vida más fácil, bla, bla, ... Que se lo cuenten a otro, que yo ya tengo algo de experiencia en esto de Linux y lo he vivido desde "el principio".
Sí, estoy protestando porque nos metimos en esto del FLOSS para tener una libre elección ... No me extraña que la gente se vaya a MacOS (que no me gusta nada), pero por lo menos no les venden esa falsa "libertad".
El mundillo de Linux se está llenando de muchas tonterías últimamente (MHO). En otro portátil tengo FreeBSD y estoy encantado. Hacía mucho que no lo usaba ... y la verdad es que me va muy bien.
Je. ¿Te has enterado de la trifulca en el kernel por lo del lenguaje inclusivo?
Bueno ... no me saques el tema ... Estoy que trino con eso. Mucho hablar, pero el término robot se sigue usando y nadie se ha quejado ... y resulta que robot básicamente equivale a esclavo. Dentro de poco no podremos jugar al ajedrez o a las damas. Lo más cachondo es que los términos que han decido utilizar tampoco es que sean muy "correctos": main/subordinate controller/worker leader/follower director/performer La verdad es que son muy parecidos esos términos a master/slave ... Como siempre, MHO, Rafa -- 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
Hola :)
On Mon, Jul 20, 2020 at 1:24 PM Juan Erbes
El lun., 20 jul. 2020 a las 5:01, Rafa Griman (
) escribió:
[...]
¡No me digas que tienes Snapper desactivado!
Sip 0:) Es uqe no uso btrfs ... requiere/requería mucho espacio y hago instalaciones minimalistas 0:) [...]
Yo no actualicé a la última versión de Tumbleweed, porque leí que firefox elimina los bookmarks.
Eso no me ha pasado. Se han mantenido.
Parece que este fin de semana fue un día fatídico para la informática: https://www.baenegocios.com/negocios/Hackearon-los-servidores-de-Telecom-202...
xD Y que lo digas!!! Estaba intentando arreglar el desaguisado y CloudFlare se va ... Imagínate mi cara cuando no tengo Internet !!! Meno mal que me olí algo y cambié los servidores de DNS 0;) [...]
Suerte,
Gracias !! Al final lo resolví instalando una versión anterior del firmware y del microcódigo. Rafa -- 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., 20 jul. 2020 a las 18:02, Rafa Griman
(
Hola :)
On Mon, Jul 20, 2020 at 1:24 PM Juan Erbes
wrote: El lun., 20 jul. 2020 a las 5:01, Rafa Griman (
) escribió: [...]
¡No me digas que tienes Snapper desactivado!
Sip 0:) Es uqe no uso btrfs ... requiere/requería mucho espacio y hago instalaciones minimalistas 0:)
[...]
Yo no actualicé a la última versión de Tumbleweed, porque leí que firefox elimina los bookmarks.
Eso no me ha pasado. Se han mantenido.
Parece que este fin de semana fue un día fatídico para la informática: https://www.baenegocios.com/negocios/Hackearon-los-servidores-de-Telecom-202...
xD Y que lo digas!!! Estaba intentando arreglar el desaguisado y CloudFlare se va ... Imagínate mi cara cuando no tengo Internet !!! Meno mal que me olí algo y cambié los servidores de DNS 0;)
[...]
Suerte,
Gracias !! Al final lo resolví instalando una versión anterior del firmware y del microcódigo.
Si, justamente estaba viendo eso, que en la última actualización hay varios paquetes kernel-firmware, entre ellos kernel-firmware-amdgpu. En mi caso, como no tengo la gpu integrada en el micro, tal vez no afecte, pero por las dudas voy a esperar hasta el próximo fin de semana. ¿Informaste del fallo en la nueva Bugzilla? https://bugzilla.opensuse.org/index.cgi https://idp-portal-info.suse.com/ Saludos, 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
Hola :)
On Tue, Jul 21, 2020 at 12:04 AM Juan Erbes
El lun., 20 jul. 2020 a las 18:02, Rafa Griman (
) escribió:
[...]
Gracias !! Al final lo resolví instalando una versión anterior del firmware y del microcódigo.
Si, justamente estaba viendo eso, que en la última actualización hay varios paquetes kernel-firmware, entre ellos kernel-firmware-amdgpu.
En mi caso, como no tengo la gpu integrada en el micro, tal vez no afecte, pero por las dudas voy a esperar hasta el próximo fin de semana.
¿Informaste del fallo en la nueva Bugzilla? https://bugzilla.opensuse.org/index.cgi
Se me han adelantado: https://bugzilla.opensuse.org/show_bug.cgi?id=1174278 Por lo que cuentan, afecta a Picasso solamente. El paquete afectado es: kernel-firmware-amdgpu. Lo han parcheado y dicen que se ha arreglado ... a la espera de que el parche llegue a TW y a todos lados. Gracias !! Rafa -- 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 7/20/20 10:45 AM, Carlos E. R. wrote>
On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona.
La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional.
Vaya.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs. Yo ni siquiera conocía la opción de rollback the YUM, así que no estoy al tanto de ninguna conversación/decisión sobre implementar (o no) tal cosa en zypper. Gracias. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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 21/07/2020 10.12, Ancor Gonzalez Sosa wrote:
On 7/20/20 10:45 AM, Carlos E. R. wrote>
On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona.
La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional.
Vaya.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto. También se habló de "features" nuevas que sólo funcionan con btrfs, pero ahora no caigo en cuales son. Tendría que hacer una búsqueda exhaustiva para encontrar las conversaciones. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 7/21/20 11:59 AM, Carlos E. R. wrote:
On 21/07/2020 10.12, Ancor Gonzalez Sosa wrote:
On 7/20/20 10:45 AM, Carlos E. R. wrote>
On Monday, 2020-07-20 at 09:00 +0100, Rafa Griman wrote:
El viernes actualicé mi Tumbleweed y ahora la GPU no da señal, Los ventiladores se ponen a girar muchísimo, no hay señal de vídeo, el portátil se recaliente y tengo que apagar pulsando el botón de encendido ya que ninguna combinación de teclas funciona.
La única manera de que funcione es utilizando la opción de "nomodeset" en el GRUB2. Todas las demás opciones de amdgpu.[algo] no funcionan. Y asé que eso desactiva el KMS, pero es la única manera que tengo de tener un equipo medianamente funcional.
Vaya.
He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*). Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-) Saludos (*) Sería más correcto decir que puede usar snapper (que no sólo funciona con btrfs, también puede apoyarse en snapshots de LVM). -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección. En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK. Gracias a Dios, existe rpm -Uvh --last que te indica cuáles fueron los últimos paquetes instalados (es lo que usé yo). Y luego, manualmente, instalé los paquetes anteriores. Si rpm incluye esa opción ... zypper podría hacer uso de ella, por ejemplo. Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper. Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada". Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad. Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): - por complejidad a la hora de recuperar datos cuando un disco (o más de uno) falla. Si usas LVM ... tienes otra capa de abstracción adicional. Igual que si usas mdadm, HW RAID, ... He tenido que (intentar) recuperar (grandes volúmenes de) datos de GPFS, XFS, BeeGFS, ext2, ext3 y ext4. Con y sin HW RAID, mdadm y/o LVM. - por la "necesidad" de asignar tanto espacio a la partición / para que btrfs haga los snapshots (50 GB, IIRC, no sé si lo habrán cambiado ahora). He tenido que trabajar en entornos HPC en los que el sistema de ficheros se monta en RAM y cuanto más pequeño el FS, mejor. Tbn he estado en entornos HPC con OS instalado en disco, pero se instala lo mínimo para tener más espacio para scratch local y/o tmp. - puede haber sistemas de ficheros que me ofrecen mejor rendimiento (por ejemplo) para lo que se está haciendo. Otras personas estarán encantadas con btrfs y me alegro mucho por ellos. No estoy en contra de btrfs (en otro hilo decía que en Linux lo prefiero a tener que usar ZFS porque btrfs está en el kernel). De hecho, si soportase el equivalente a Z1, Z2 y Z3 de ZFS ... no lo dudaría en absoluto para directorios como /home. AFAIK, el equivalente a Z1, Z2 y Z3 de ZFS aún no se considera "production ready" y puedes perder datos. Corregidme si me equivoco.
(*) Sería más correcto decir que puede usar snapper (que no sólo funciona con btrfs, también puede apoyarse en snapshots de LVM).
As always, MHO ... Rafa -- 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 Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion. Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no? La idea de snapper + btrfs es que no se necesita tener una base de datos de rpms antiguos (local o en repositorio), y ademas queda generalizado para binarios y para ficheros de configuracion. Puedes recuperar el estado completo de un sistema, no solo la version de un paquete. Es este ultimo punto, tener una ya solucion generalizada external al gestor de paquetes, es lo que dificulta el argumento de implementar otra solucion que tecnicamente seria inferior.
En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK.
Implementar una bd de versiones paquetes en zypper podria tener sentido. Tener algo como "zypper history" seria util.
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
https://github.com/openSUSE/zypper (GPLv2) Se pueden enviar PR.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Uhm MicroOS funciona con btrfs en sistemas ARM. Se hace rollback automatico en cuanto se encuentra algun problema.
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...).
Uau, Rafa, estas muy confundido. Free/libre no se refiere a la libertad de elegir nada. Es la libertad que se le da al usuario de inspeccionar, modificar y distribuir el codigo fuente alterado. En ese sentido, zypper esta en github bajo GPLv2. Es C++, y ya hay gente ejercitando la libertad que ofrece FLOSS: https://github.com/openSUSE/zypper/pulls -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
El mar., 21 jul. 2020 a las 8:27, Rafa Griman (
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK.
Gracias a Dios, existe rpm -Uvh --last que te indica cuáles fueron los últimos paquetes instalados (es lo que usé yo). Y luego, manualmente, instalé los paquetes anteriores. Si rpm incluye esa opción ... zypper podría hacer uso de ella, por ejemplo.
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad.
Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): - por complejidad a la hora de recuperar datos cuando un disco (o más de uno) falla. Si usas LVM ... tienes otra capa de abstracción adicional. Igual que si usas mdadm, HW RAID, ... He tenido que (intentar) recuperar (grandes volúmenes de) datos de GPFS, XFS, BeeGFS, ext2, ext3 y ext4. Con y sin HW RAID, mdadm y/o LVM. - por la "necesidad" de asignar tanto espacio a la partición / para que btrfs haga los snapshots (50 GB, IIRC, no sé si lo habrán cambiado ahora). He tenido que trabajar en entornos HPC en los que el sistema de ficheros se monta en RAM y cuanto más pequeño el FS, mejor. Tbn he estado en entornos HPC con OS instalado en disco, pero se instala lo mínimo para tener más espacio para scratch local y/o tmp. - puede haber sistemas de ficheros que me ofrecen mejor rendimiento (por ejemplo) para lo que se está haciendo.
Otras personas estarán encantadas con btrfs y me alegro mucho por ellos. No estoy en contra de btrfs (en otro hilo decía que en Linux lo prefiero a tener que usar ZFS porque btrfs está en el kernel). De hecho, si soportase el equivalente a Z1, Z2 y Z3 de ZFS ... no lo dudaría en absoluto para directorios como /home. AFAIK, el equivalente a Z1, Z2 y Z3 de ZFS aún no se considera "production ready" y puedes perder datos. Corregidme si me equivoco.
(*) Sería más correcto decir que puede usar snapper (que no sólo funciona con btrfs, también puede apoyarse en snapshots de LVM).
Un par de aclaraciones con respecto a los Snapshots y BTRFS: 1- Aunque se tenga el FS de sistema en BTRFS, se DEBE activar la creación de los snapshots manualmente. 2- Se puede utilizar en particiones de menos de 50 GB, pero se DEBEN BORRAR LOS SNAPSHOTS MAS VIEJOS, desde Yast -> Miscelanea -> Instantáneas del sistema de archivos. La opción más práctica, es setear el número máximo de snapshots o instantáneas: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... 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 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Admito que lo dije con cierta ironía.
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion.
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/ Y está el paquete "tumbleweed-cli" para facilitarlo.
La idea de snapper + btrfs es que no se necesita tener una base de datos de rpms antiguos (local o en repositorio), y ademas queda generalizado para binarios y para ficheros de configuracion. Puedes recuperar el estado completo de un sistema, no solo la version de un paquete.
Es este ultimo punto, tener una ya solucion generalizada external al gestor de paquetes, es lo que dificulta el argumento de implementar otra solucion que tecnicamente seria inferior.
No es inferior, es distinta. Por ejemplo, ocupa mucho menos espacio aunque tengas que guardar los paquetes antiguos en local. También se puede tener ese histórico en un servidor local de la intranet sirviendo a cientos de máquinas.
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...).
Uau, Rafa, estas muy confundido. Free/libre no se refiere a la libertad de elegir nada. Es la libertad que se le da al usuario de inspeccionar, modificar y distribuir el codigo fuente alterado.
Difiero. En Linux siempre tuvimos la libertad de elección. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Wenas Ñ=
On Tue, Jul 21, 2020 at 1:05 PM Alberto Planas Dominguez
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion.
Todo lo contrario ! Se agradecen opiniones de todo el mundo, faltaría más ! MHO: no es una "discusión".
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
No, los descarga de las repos.
La idea de snapper + btrfs es que no se necesita tener una base de datos de rpms antiguos (local o en repositorio), y ademas queda generalizado para binarios y para ficheros de configuracion. Puedes recuperar el estado completo de un sistema, no solo la version de un paquete.
Totalmente de acuerdo. Yo lo he simplificado para mi caso en concreto: un paquete falla y hace que mi equipo no se pueda usar. Te puedo contar los tickets que tenemos de: "No sé qué ha pasado, pero me ha desaparecido el directorio $HOME/superimportante. Pero yo no he borrado nada." Gracias a los snapshots que ofrecen NetApp y ZFS se les recuperan los datos y todos contentos. Hoy en día (AFAIK), no se recomienda usar btrfs con el equivalente a Z1, Z2, y Z3 de ZFS (o RAID 5 ó 6). Por eso usamos NetApp y/o ZFS. Y sí, conozco otros sistemas operativos que hacen algo similar a lo que propone SUSE: FreeNAS/TrueNAS. Y no, zypper no es la única herramienta de gestión de paquetes que no soporta rollbacks.
Es este ultimo punto, tener una ya solucion generalizada external al gestor de paquetes, es lo que dificulta el argumento de implementar otra solucion que tecnicamente seria inferior.
MHO es que no es "inferior": tuve un problema concreto y me hubiera venido muy bien poder hacer un rollback. En este caso fue en un portátil. Hace unos meses fue en un clúster de cómputo en el que un yum update actualizó Python y los científicos no podían ejecutar sus trabajos. Hice un rollback y pudieron continuar. OJO! No digo que yum sea mejor, sólo expongo una situación que he vivido. Tampoco digo que no me guste zypper ni SUSE. Que no haya malentendidos.
En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK.
Implementar una bd de versiones paquetes en zypper podria tener sentido. Tener algo como "zypper history" seria util.
Exacto, es lo que digo: sería útil.
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
https://github.com/openSUSE/zypper (GPLv2)
Se pueden enviar PR.
Ya, y sé que hay gente que lo ha comentado/pedido/solicitado (no me acuerdo si en foros, listas de correo, ...). Como decía Carlos en un correo anterior, él también lo ha visto, pero no se acuerda dónde.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Uhm MicroOS funciona con btrfs en sistemas ARM. Se hace rollback automatico en cuanto se encuentra algun problema.
Cierto, I stand corrected. Como decía en un correo anterior: agradezco este tipo de información porque no sé si las cosas han cambiado o no (hace un tiempo que no miro btrfs en detalle). Lo mismo digo con el tema de RAID 5 ó 6 (Z1, Z2 y Z3 de ZFS), ya que trabajas para SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene clientes usándolo? ¿En qué entornos lo están usando los clientes? ...
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...).
Uau, Rafa, estas muy confundido. Free/libre no se refiere a la libertad de elegir nada. Es la libertad que se le da al usuario de inspeccionar, modificar y distribuir el codigo fuente alterado.
Sí, las 3 libertades que te otorga/ofrece/garantiza la licencia GPL. Ya la conozco, llevo con Linux desde 1995 ;) Aunque no esté implícito en la licencia GPL, muchos de los que empezamos (hace mucho tiempo) en el mundillo FLOSS, fue por la posibilidad (libertad) de elegir. Te pongo un caso concreto. SUSE fué la primera distro en dar soporte oficial a XFS, JFS y resierfs, mucho antes que cualquier otra distro (ahora que lo pienso, no sé si Slackware tbn ofrecía soporte para otros fs) y eso a la gente le encantaba: podían elegir el sistema de ficheros en función de los datos que iba a almacenar (rendimiento, journaling, ...). Esto es un ejemplo concreto relacionado con sistemas de ficheros. En este caso concreto que yo he expuesto (una actualización hizo que mi equipo no se pudiera utilizar), si quiero rollback, la única opción que tengo es usar btrfs o LVM. No hay otra opción. OJO ! No digo que sea malo, no estoy señalando con dedo acusador. Sólo digo que sería interesante/útil tener la opción de rollback dentro de zypper ... me habría ahorrado mucho tiempo (y hubiese evitado este hilo xD) Que la opción de snapshots de btrfs es mucho más completa ... sí, es cierto ... pero no necesito todo lo que ofrece btrfs (caso particular mío), como siempre, pongo lo de MHO. Hablo de mi caso concreto. Como he dicho en el correo anterior: no estoy en contra de btrfs y lo usaré en el trabajo en el momento que se me convenzca que su equivalente a Z1, Z2 y Z3 es estable y "production ready". Y, creeme, tienes cientos de Exabytes de usuarios de Lustre y BeeGFS que lo usarían también con tal de quitarse el ZFS que ponen por debajo. Así que vuelvo a lanzar la pregunta a SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene SUSE clientes usándolo? ¿En qué entornos lo están usando los clientes? ...
En ese sentido, zypper esta en github bajo GPLv2. Es C++, y ya hay gente ejercitando la libertad que ofrece FLOSS:
Ya, ya sé que es FLOSS, igual que YaST ;) MHO, Rafa -- 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
Wenas :)
On Tue, Jul 21, 2020 at 1:13 PM Juan Erbes
Un par de aclaraciones con respecto a los Snapshots y BTRFS:
1- Aunque se tenga el FS de sistema en BTRFS, se DEBE activar la creación de los snapshots manualmente.
2- Se puede utilizar en particiones de menos de 50 GB, pero se DEBEN BORRAR LOS SNAPSHOTS MAS VIEJOS, desde Yast -> Miscelanea -> Instantáneas del sistema de archivos.
La opción más práctica, es setear el número máximo de snapshots o instantáneas: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref...
Muchas gracias Juan, es a lo que me refería. Todos estos trucos/consejos/novedades/ ... los agradezco porque hace mucho que no me meto en bttrfs. Rafa -- 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 7/21/20 2:50 PM, Rafa Griman wrote:
Wenas Ñ=
[...]
Como he dicho en el correo anterior: no estoy en contra de btrfs y lo usaré en el trabajo en el momento que se me convenzca que su equivalente a Z1, Z2 y Z3 es estable y "production ready". Y, creeme, tienes cientos de Exabytes de usuarios de Lustre y BeeGFS que lo usarían también con tal de quitarse el ZFS que ponen por debajo. Así que vuelvo a lanzar la pregunta a SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene SUSE clientes usándolo? ¿En qué entornos lo están usando los clientes?
No. SUSE no lo considera listo para producción y por eso no lo ofrecemos en YaST, por ejemplo. Si un cliente lo usa, es bajo su propia responsabilidad Saludos. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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., 21 jul. 2020 a las 9:58, Carlos E. R.
(
On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] > No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Admito que lo dije con cierta ironía.
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion.
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Rafa, no nos dijiste nada del "sistema boombatower"..... Iba a preguntar, pero se lo pregunté a Google, y entre otras cosas, me devolvió esto: https://github.com/boombatower/tumbleweed-cli https://www.drupal.org/u/boombatower https://chrome.google.com/webstore/detail/boombatower-tts/ooolbnjollfnjcobam... https://www.reddit.com/r/openSUSE/comments/femkkq/how_reputable_or_accurate_... http://download.opensuse.org/repositories/home:/boombatower:/steamtricks/ope... 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 21/07/2020 15.10, Juan Erbes wrote:
El mar., 21 jul. 2020 a las 9:58, Carlos E. R. (<>) escribió:
On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Perdon por entrar en la discusion.
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Rafa, no nos dijiste nada del "sistema boombatower".....
No, porque se lo dije yo a él ;-) Y puse los enlaces que tienes que mirar. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Tuesday, July 21, 2020 2:45:06 PM CEST Carlos E. R. wrote:
On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Solo comentar que el historico de paquetes de boombatower no esta soportado oficialmente, y que las limitaciones son claras (solo tienes una ventana de tiempo) : ( -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
Hola :)
On Tue, Jul 21, 2020 at 2:10 PM Ancor Gonzalez Sosa
On 7/21/20 2:50 PM, Rafa Griman wrote:
Wenas Ñ=
[...]
Como he dicho en el correo anterior: no estoy en contra de btrfs y lo usaré en el trabajo en el momento que se me convenzca que su equivalente a Z1, Z2 y Z3 es estable y "production ready". Y, creeme, tienes cientos de Exabytes de usuarios de Lustre y BeeGFS que lo usarían también con tal de quitarse el ZFS que ponen por debajo. Así que vuelvo a lanzar la pregunta a SUSE: ¿considera SUSE que el equivalente a RAID 5 y 6 de btrfs está listo para producción? ¿Tiene SUSE clientes usándolo? ¿En qué entornos lo están usando los clientes?
No. SUSE no lo considera listo para producción y por eso no lo ofrecemos en YaST, por ejemplo. Si un cliente lo usa, es bajo su propia responsabilidad
OK, muchas gracias. Para mi trabajo, mientras SUSE, u otra distro, no lo soporten ... btrfs no es una opción válida y tendré/tendremos que seguir usando ZFS/NetApp. Y creeme ... tengo muchas ganas de deshacerme de NetApp. Contra ZFS no tengo nada, salvo que no está incluido en el kernel (por temas de licencias) y es muy molesto tener que instalarlo y actualizar, ... igual que NVIDIA. Rafa -- 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
Hola :)
On Tue, Jul 21, 2020 at 2:11 PM Juan Erbes
El mar., 21 jul. 2020 a las 9:58, Carlos E. R. (
) escribió: On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] >> No quieren hacerlo, precisamente para que uses btrfs. > > ¿Tienes algún enlace donde se explique eso? Es decir, que los > desarrolladores de zypper se niegan a desarrollar esa funcionalidad > para > forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Admito que lo dije con cierta ironía.
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion.
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Rafa, no nos dijiste nada del "sistema boombatower".....
Al final lo hice "amanuense": - ver los paquetes que se actualizaron - descargar manualmente la versión anterior de los paquetes - instalar la versión anterior No llegué a usar boombatower porque me funcionó el método manual. Sí lo tengo en el todo list para probarlo porque me parece muy interesante. Perdona la confusión ;) HTH Rafa -- 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
Hola :)
On Tue, Jul 21, 2020 at 2:17 PM Alberto Planas Dominguez
On Tuesday, July 21, 2020 2:45:06 PM CEST Carlos E. R. wrote:
On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Solo comentar que el historico de paquetes de boombatower no esta soportado oficialmente, y que las limitaciones son claras (solo tienes una ventana de tiempo) : (
Gracias por la info, es bueno saberlo :) Rafa -- 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 21/07/2020 15.23, Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 2:17 PM Alberto Planas Dominguez
wrote: On Tuesday, July 21, 2020 2:45:06 PM CEST Carlos E. R. wrote:
On 21/07/2020 14.05, Alberto Planas Dominguez wrote:
On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no?
Pero es que ya están. Rafa hizo un rollback manual aprovechando el sistema boombatower y http://download.opensuse.org/history/
Y está el paquete "tumbleweed-cli" para facilitarlo.
Solo comentar que el historico de paquetes de boombatower no esta soportado oficialmente, y que las limitaciones son claras (solo tienes una ventana de tiempo) : (
Gracias por la info, es bueno saberlo :)
No estará soportado oficialmente, pero hay mucha gente que lo usa. http://download.opensuse.org/history/ creo que sí está en nuestra red, no es externo. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 7/21/20 1:27 PM, Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. [...]
En la práctica, eso es básicamente cierto. Pero mi comentario no trataba de apuntar tanto a cuáles son las consecuencias en la práctica, sino a la supuesta intencionalidad que la frase original atribuía a los desarrolladores de zypper. Como ya Carlos aclaró, lo decía con cierta sorna. ;-)
[...]
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
No exactamente. Zypper es un proyecto de software libre. Que SUSE no le pague a alguien de su plantilla para desarrollar una característica concreta, no significa que SUSE esté decidiendo que esa característica no se implemente. Simplemente está decidiendo no pagarla de su bolsillo.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería
No tengo ni idea de cómo de difícil será de implementar, pero sin duda implica dedicar ciertos recursos: horas de trabajo de los desarrolladores, pruebas y verificación, esfuerzo de documentación, dificultar el mantenimiento de zypper para el futuro al tener más cosas que tener en cuenta.... Aunque no llegue a la categoría de hercúleo, si que te aseguro que hay una cierta tendencia a subestimar el esfuerzo y las consecuencias de estas cosas. Los recursos de SUSE son más limitados de lo que algunos puedan pensar. Así que el uso de esos recursos a menudo se concentra en cosas distintas de las que nos gustaría a algunos usuarios.
una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Cuestión de usar esos argumentos para intentar convencer a: a) alguien que se lie la manta a la cabeza y lo implemente b) los desarrolladores de SUSE (o sus jefes) para que lo hagan como parte de su trabajo en la empresa.
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en
Al igual que apuntó Alberto, no creo que ese sea el significado de "libertad" en el contexto del software libre. En absoluto.
este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad.
Asumiendo que FLOSS significa flexibilidad (que ya digo que discrepo). Lo cierto es que sí tienes cierta flexibilidad: a) usar openSUSE con btrfs + snapper + zypper b) usar openSUSE con LVM + snapper + zypper c) usar openSUSE con otro sistema de archivos + dnf (yum) d) usar una distribución que esté más alineada con tu caso de uso ...
Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío. Saludos -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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., 21 jul. 2020 a las 10:36, Ancor Gonzalez Sosa
(
On 7/21/20 1:27 PM, Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. [...]
En la práctica, eso es básicamente cierto. Pero mi comentario no trataba de apuntar tanto a cuáles son las consecuencias en la práctica, sino a la supuesta intencionalidad que la frase original atribuía a los desarrolladores de zypper. Como ya Carlos aclaró, lo decía con cierta sorna. ;-)
[...]
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
No exactamente. Zypper es un proyecto de software libre. Que SUSE no le pague a alguien de su plantilla para desarrollar una característica concreta, no significa que SUSE esté decidiendo que esa característica no se implemente. Simplemente está decidiendo no pagarla de su bolsillo.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería
No tengo ni idea de cómo de difícil será de implementar, pero sin duda implica dedicar ciertos recursos: horas de trabajo de los desarrolladores, pruebas y verificación, esfuerzo de documentación, dificultar el mantenimiento de zypper para el futuro al tener más cosas que tener en cuenta.... Aunque no llegue a la categoría de hercúleo, si que te aseguro que hay una cierta tendencia a subestimar el esfuerzo y las consecuencias de estas cosas.
Los recursos de SUSE son más limitados de lo que algunos puedan pensar. Así que el uso de esos recursos a menudo se concentra en cosas distintas de las que nos gustaría a algunos usuarios.
una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Cuestión de usar esos argumentos para intentar convencer a:
a) alguien que se lie la manta a la cabeza y lo implemente b) los desarrolladores de SUSE (o sus jefes) para que lo hagan como parte de su trabajo en la empresa.
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en
Al igual que apuntó Alberto, no creo que ese sea el significado de "libertad" en el contexto del software libre. En absoluto.
este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad.
Asumiendo que FLOSS significa flexibilidad (que ya digo que discrepo). Lo cierto es que sí tienes cierta flexibilidad:
a) usar openSUSE con btrfs + snapper + zypper b) usar openSUSE con LVM + snapper + zypper c) usar openSUSE con otro sistema de archivos + dnf (yum) d) usar una distribución que esté más alineada con tu caso de uso ...
Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
¿Porque no duermes 100% tranquilo con btrfs en un sistema en producción? Saludos, 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
On 7/21/20 4:22 PM, Juan Erbes wrote:
El mar., 21 jul. 2020 a las 10:36, Ancor Gonzalez Sosa (
) escribió: [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
¿Porque no duermes 100% tranquilo con btrfs en un sistema en producción?
Cuestiones puramente subjetivas. En lo que respecta a sistemas de ficheros soy MUY conservador, casi paranoico. Y Btrfs es bastante innovador en varios aspectos. Algo que seguramente es una ventaja en realidad... pero que a mí me inquieta un poco. Saludos -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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
Hola :)
On Tue, Jul 21, 2020 at 2:36 PM Ancor Gonzalez Sosa
On 7/21/20 1:27 PM, Rafa Griman wrote:
Hola :)
[...]
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. [...]
En la práctica, eso es básicamente cierto. Pero mi comentario no trataba de apuntar tanto a cuáles son las consecuencias en la práctica, sino a la supuesta intencionalidad que la frase original atribuía a los desarrolladores de zypper. Como ya Carlos aclaró, lo decía con cierta sorna. ;-)
Ya, ya :)
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
No exactamente. Zypper es un proyecto de software libre. Que SUSE no le pague a alguien de su plantilla para desarrollar una característica concreta, no significa que SUSE esté decidiendo que esa característica no se implemente. Simplemente está decidiendo no pagarla de su bolsillo.
Por eso usé las doble comillas ;) Y estoy 100% de acuerdo, SUSE dice que no lo va a pagar de su bolsillo y, como digo, tiene todo el derecho a opinar y actuar de esa manera. La estrategia de SUSE es basarse en btrfs-LVM y sus snapshots.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería
No tengo ni idea de cómo de difícil será de implementar, pero sin duda implica dedicar ciertos recursos: horas de trabajo de los desarrolladores, pruebas y verificación, esfuerzo de documentación, dificultar el mantenimiento de zypper para el futuro al tener más cosas que tener en cuenta.... Aunque no llegue a la categoría de hercúleo, si que te aseguro que hay una cierta tendencia a subestimar el esfuerzo y las consecuencias de estas cosas.
Tranquilo, que no subestimo el esfuerzo (económico, Humano y en tiempo) que puede suponer un desarrollo. Como mencioné antes, llevo desde 1995 en el mundillo FLOSS y he trabajado en alguna empresa de FLOSS y desde hace 15 años me dedico a HPC así que sé lo que supone desarrollar, optimizar, depurar, validar, ... Y eso que no soy yo quien desarrolla el SW 0;) Cuando dije que no me parece hercúleo, a lo que me refería es que ya está YUM como ejemplo, rpm tiene alguna opción útil en la que se puede basar zypper, ... Es decir, no es empezar completamente desde 0 y todo lo que ello supone: diseño, análisis, ... Y no, no propongo "copiar y pegar" ;)
Los recursos de SUSE son más limitados de lo que algunos puedan pensar. Así que el uso de esos recursos a menudo se concentra en cosas distintas de las que nos gustaría a algunos usuarios.
Me hago una idea de los recursos que tiene SUSE, creeme ;) Y estoy de acuerdo en que hay que destinar esos recursos (económicos, Humanos y de tiempo) hacia la visión, misión y estrategia de SUSE. Por eso mismo digo que es MHO y que sería útil. En ningún momento he dicho que SUSE _DEBA_ implementar rollback en zypper 0;)
una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Cuestión de usar esos argumentos para intentar convencer a:
a) alguien que se lie la manta a la cabeza y lo implemente
Claro, por eso no he dicho que SUSE deba ser la que lo implemente ni que dba implementarse, sino que sería útil. Y, por cierto, sé que SUSE es mucho (o era) mucho más abierta a colaboraciones/aportaciones de externos (particulares o empresas) que Red Hat. Por eso, por ejemplo, SUSE incluyó y soportó XFS (y Ceph) antes que Red Hat ... muuucho antes que Red Hat ... Pena que Red Hat contratase a todos los desarrolladores de XFS y comprase InkTank ...
b) los desarrolladores de SUSE (o sus jefes) para que lo hagan como parte de su trabajo en la empresa.
SUSE tiene cosas más importantes que hacer que implementar rollback, sinceramente. Como dicen los gringos, simplemente era "wishful thinking". Por eso, cuando he hablado con gente de SUSE ... ni lo he sacado ;)
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en
Al igual que apuntó Alberto, no creo que ese sea el significado de "libertad" en el contexto del software libre. En absoluto.
Ya, lo dije en un correo anterior y Carlos también. En el "manifiesto" inicial de Stallman no viene implícito (ni en la licencia GPL, LGPL o cualquier otra considerada FLOSS) ni en ningún otro documento. Me expresé mal 0:) A lo que me refiero es que esas 3 libertades dan lugar indirectamente a la libertad de elegir ... ya que la libertad de hacer un fork puede dar lugar a una segunda alternativa. vi, vim, nvi, ... vienen a la mente como ejemplos muy simplones o que GNOME se empezase a desarrollar porque Qt no era GPL o que exista systemd porque SystemV init estaba anticuado y carecía de algunas características ... ¿Significa eso que SUSE (u otra distro) _DEBA_ ofrecer _TODAS_ las alternativas? No. Y, una vez más, esto es MHO ... sería útil/interesante que incluyese algunas (wishful thinking). Obviamente, eso es decisión de SUSE basado en sus prioridades (visión, misión, estrategia, inversores, clientes, ...). Simplemente estaba dando mi opinión, que se puede ignorar y todos tan contentos ;)
este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...). Y, como dije en un correo anterior: no espero tener TODAS las opciones, pero por lo menos más de una ... aka cierta flexibilidad.
Asumiendo que FLOSS significa flexibilidad (que ya digo que discrepo). Lo cierto es que sí tienes cierta flexibilidad:
a) usar openSUSE con btrfs + snapper + zypper b) usar openSUSE con LVM + snapper + zypper c) usar openSUSE con otro sistema de archivos + dnf (yum)
Exacto, es lo mismo que he dicho antes. Ya he comentado que LVM supone una capa adicional si tienes que entrar a recuperar datos (y lo he tenido que hacer muchas veces). En cuanto a las ventajas que tiene LVM: - agrandar espacio en disco: los únicos sistemas de almacenamiento que he tenido que "agrandar" han sido BeeGFS, Lustre, GPFS y ZFS ... Ninguno de ellos usa LVM (bueno, ZFS tiene un gestor de volúmenes intrínseco). El disco local es para un OS "pelao" que "no crece" y si falla, metes otro y reinstalas. La otra utilidad del disco local es scratch local. - snapshots: no se suelen hacer snapshots de esos sistemas de ficheros ;) Para $HOME, como suele estar en ZFS o NetApp ... te lo hacen ellos. Así que los snapshots de LVM no los necesito, el disco local es para un OS "pelao". - mirroring (~RAID1) para el OS del nodo: no lo necesito, prefiero dedicar ese segundo disco a scratch local. Si el disco del OS casca, lo cambio, reinstalo y a seguir "moliendo números" Si hablas con gente que gestiona SAP, Oracle, PostgreSQL, ... es otra historia. En mi trabajo anterior tenía que gestionar varios PostgreSQL muy críticos (para la OMS), obviamente, ahí sí que propongo RAID1 (ó 10, según el crecimiento de la BBD), snapshots, múltiples copias, backups, redundancia, HA, load balancing y copias en papel si hace falta xD
d) usar una distribución que esté más alineada con tu caso de uso
Por desgracia ... Digo por desgracia porque la distro de SUSE me gusta mucho y llevo muuuuuucho tiempo usándola. Por desgracia, tengo que gestionar clusters con CentOS y también he tenido que gestionarlos con Ubuntu. No odio esas distros, pero sinceramente, prefiero SUSE. NOTA: los clústers llevan CentOS/Ubuntu por otras razones, no porque no pueda hacer rollback ... no vaya a haber malas interpretaciones ;) En mi casa también estoy empezando a migrar algunos equipos a otras distros. ¿Significa eso que odio SUSE o que la detesto o que me vaya a dar de baja de las listas? No. ¿Voy a quitar SUSE de todos mis equipos en casa? No. El de mi mujer seguirá con SUSE por la facilidad de uso, YaST, ... En ese caso, veo útil NetworkManager y systemd y todas esas cosas "automatizadas", "plug'n'pray", ... Pero para mis equipos personales no necesito esas cosa así que buscaré alguna distro que me permita elegir. En el portátil del trabajo, pues sí seguiré con Tumbleweed lo más seguro. BTW, una de mis cuñadas está muy contenta con SUSE desde el 2007 (IIRC) y no la voy a migrar a otra distro ;) Y mi suegra también.
Razones (técnicas) por las que digo que no quiero usar btrfs o LVM (esto son experiencias personales, YMMV): [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
Entonces comprenderás mi situación, especialmente cuando hablamos de datos MUY sensibles. Como tú, también me fío de LVM (lleva muchos años y está muy probado), pero no me vale para lo que yo hago ... bueno, para lo que hacen mis usuarios. HTH y MHO, Rafa -- 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 Tue, Jul 21, 2020 at 4:35 PM Ancor Gonzalez Sosa
On 7/21/20 4:22 PM, Juan Erbes wrote:
El mar., 21 jul. 2020 a las 10:36, Ancor Gonzalez Sosa (
) escribió: [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
¿Porque no duermes 100% tranquilo con btrfs en un sistema en producción?
Cuestiones puramente subjetivas. En lo que respecta a sistemas de ficheros soy MUY conservador, casi paranoico. Y Btrfs es bastante innovador en varios aspectos. Algo que seguramente es una ventaja en realidad... pero que a mí me inquieta un poco.
Me alegra saber que no soy el único paranoico en cuanto a sistemas de ficheros 0;) Rafa -- 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 21/07/2020 19.07, Rafa Griman wrote:
On Tue, Jul 21, 2020 at 4:35 PM Ancor Gonzalez Sosa
wrote: On 7/21/20 4:22 PM, Juan Erbes wrote:
El mar., 21 jul. 2020 a las 10:36, Ancor Gonzalez Sosa (
) escribió: [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
¿Porque no duermes 100% tranquilo con btrfs en un sistema en producción?
Cuestiones puramente subjetivas. En lo que respecta a sistemas de ficheros soy MUY conservador, casi paranoico. Y Btrfs es bastante innovador en varios aspectos. Algo que seguramente es una ventaja en realidad... pero que a mí me inquieta un poco.
Me alegra saber que no soy el único paranoico en cuanto a sistemas de ficheros 0;)
A mi me pasa igual :-) hace ya mucho, mucho tiempo, tenía el sistema puesto con reiserfs. SUSE lo apoyaba y era la elección por defecto. Un día comentaron un bug. Se podía crear dos ficheros con nombres distintos, pero el sistema creía que eran el mismo nombre, y se armaba el taco. Yo quise probarlo... ... Y tuve que reformatear la partición. Cosas como esas tienen un efecto despertador. Que conste que he tenido fallos catastróficos en todos los sistemas. Empezando con MsDOS en disquetes, extX, reiserfs, xfs, ntfs... y btrfs. De hecho, yo descubrí por mi cuenta una manera de petar un btrfs. Simplemente tenía una partición de pruebas, pequeña, en un sistema virtual, y empecé a crear ficheros pequeños por miles y miles, a ver que pasaba. Que petó y colgó el sistema. Todos petaban de alguna u otra forma, con suerte dando un error de disco lleno. Excepto reiserfs, que seguía tan campante con un millón de ficheros en un sólo directorio. El xfs aguantó mucho. Dicho todo eso, tengo un disco para copias de seguridad con rsync que está formateado con btrfs y compresión, porque es el único sistema de ficheros comprimido que tenemos en el kernel. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
El mar., 21 jul. 2020 a las 14:07, Rafa Griman
(
On Tue, Jul 21, 2020 at 4:35 PM Ancor Gonzalez Sosa
wrote: On 7/21/20 4:22 PM, Juan Erbes wrote:
El mar., 21 jul. 2020 a las 10:36, Ancor Gonzalez Sosa (
) escribió: [...]
Sinceramente, yo tampoco duermo 100% tranquilo con btrfs en un sistema en producción. Por otro lado, de LVM sí que me fío.
¿Porque no duermes 100% tranquilo con btrfs en un sistema en producción?
Cuestiones puramente subjetivas. En lo que respecta a sistemas de ficheros soy MUY conservador, casi paranoico. Y Btrfs es bastante innovador en varios aspectos. Algo que seguramente es una ventaja en realidad... pero que a mí me inquieta un poco.
Me alegra saber que no soy el único paranoico en cuanto a sistemas de ficheros 0;)
En lo personal, la única experiencia negativa con BTRFS, en un disco duro en el que comenzaron a aparecer sectores defectuosos, el sistema se destruyó solo. Buscando una comparativa, encontré esto: https://blog.pythian.com/btrfs-performance-compared-lvmext4-regards-database... 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 20/07/2020 22.56, Rafa Griman wrote:
Hola :)
On Mon, Jul 20, 2020 at 12:47 PM Carlos E. R.
wrote: On 20/07/2020 12.30, Rafa Griman wrote:
Hola :)
On Mon, Jul 20, 2020 at 9:45 AM Carlos E. R.
wrote: [...] He mirado en el YaST y no me lista versiones anteriores de esos paquetes y no uso btrfs para hacer rollback ... La verdad es que YUM trae la opción de rollback y es maravilloso (MHO). Estaría bien que Zypper lo incluyese para evitar forzar/obligar al usuario a depender de un sistema de ficheros para eso ...
No quieren hacerlo, precisamente para que uses btrfs.
Eso es lo que me da rabia ... es como lo de systemd ... te obligan a usarlo. En casa ya he migrado un portátil a Gentoo que me permite elegir entre openrc y systemd ... No entiendo la "oligación" cuando es FLOSS y precisamente la F de Free viene a significar que puedes elegir ...
Bueno, el systemd no me va mal a mí. Ni bien ni mal. Sigo el camino de mínima resistencia. Cuando hay alguna cosa que no funciona, entonces me cabreo, pero si no, pues no me molesto en cambiar de distro. Prefiero lo que entiendo y estoy cómodo.
No soy anti-systemd, que no se me malinterprete. Lo que pasa es que no lo necesito y es que toma control de todo ... es como un mini OS. Sí, ya ... es modular y puedes instalar lo que quieras ... una porra. Prueba a desinstalar cosas del systemd y verás ... Si lo compilas tú a pelo sí, decides lo que entra y lo que no, pero en una distro hecha ...
Eso si.
Lo que digo es que me den la opción de usarlo o no. Hay casos en los que va bien y no lo veo mal. Pero que te lo fuercen porque sí ...
El Leap no me gusta: conforme el decimal de la versión se agranda se va volviendo más obsoleta. Y en algunas aplicaciones como el Shotwell, que por ser parte de gnome es core y no lo actualizan, y se nota.
Pero el TW me gusta menos.
Yo uso el TW porque el equipo tiene una CPU AMD moderna y si no estás a la última ... hay cosas que no te van a funcionar o recibes errores y es un rollo. Claro que al ser TW ... corres el peligro de que algunas cosas dejen de funcionar. Hace 1 mes me dejó de funcionar el NVMe ... gracios a Dios era cosa del kernel y pude arrancar con el kernel anterior. Luego lo solucionaron.
Pues tienes que mirar si te conviene instalar el tubleweed-cli ese. Te da dos meses de snapshots, mas o menos.
Ahora RHEL 8 ... ha quitado KDE del repo oficial ...
Contro.
Sip, en teoría lo puedes instalar mediante EPEL Playground. Pero es lo que digo: ellos deciden y te aguantas. Si deciden que el editor por defecto es nano y la shell es sh ... pues es lo que hay. Mañana te dicen que sólo soportan AMD o sólo soportan NVIDIA ... Ya, estoy exagerando, pero es para que se entienda.
Tampoco pido que soporten todo o que puedas elegir entre 50 opciones. Lo que digo es que tengas al menos 2 para elegir.
Me da la impresión que en openSUSE tenemos más cosas a elegir. Desde luego entornos de escritorio, sí. Si pensaran quitar el KDE se armaba la gorda.
Esta semana migro el otro portátil a Gentoo o ArtixLinux y el PC lo mismo. No entiendo porqué tengo que usar lo que SUSE o Red Hat deciden que es lo mejor para ti. No NECESITO systemd. Igual que elijo my DE, mi navegador, mi cliente de correo, editor de textos, ...
Si Gentoo, que tiene muuuucha menos gente "en plantilla" lo puede hacer (otras distros tbn) ... y NO tienen el presupuesto de SUSE ni Red Hat ...
A lo mejor tienen menos voluntarios. Es que lo dijeron, si hay voluntarios para seguir con initd, que lo hagan, no hay problema. Lo mismo que hay un grupo que mantiene el KDE3.
El Gnome ahora necesita systemd.
Sí, eso es una decisión que forzó el pollo ese de Systemd. Eso es otra cosa que no entiendo: algunas dependencias forzadas. GNOME ha estado años sin systemd ... de pronto no funciona si no tienes systemd. Ya, ya me sé la respuesta marketiniana y de PR: es que systemd es mejor y te hace la vida más fácil, bla, bla, ... Que se lo cuenten a otro, que yo ya tengo algo de experiencia en esto de Linux y lo he vivido desde "el principio".
Je. Yo no uso Gnome, sino XFCE, pero me afecta.
Sí, estoy protestando porque nos metimos en esto del FLOSS para tener una libre elección ... No me extraña que la gente se vaya a MacOS (que no me gusta nada), pero por lo menos no les venden esa falsa "libertad".
El mundillo de Linux se está llenando de muchas tonterías últimamente (MHO). En otro portátil tengo FreeBSD y estoy encantado. Hacía mucho que no lo usaba ... y la verdad es que me va muy bien.
Je. ¿Te has enterado de la trifulca en el kernel por lo del lenguaje inclusivo?
Bueno ... no me saques el tema ... Estoy que trino con eso. Mucho hablar, pero el término robot se sigue usando y nadie se ha quejado ... y resulta que robot básicamente equivale a esclavo. Dentro de poco no podremos jugar al ajedrez o a las damas.
Lo más cachondo es que los términos que han decido utilizar tampoco es que sean muy "correctos": main/subordinate controller/worker leader/follower director/performer
Yo ni siquiera me he puesto a leer los hilos sobre el tema... en openSUSE no ha salido. Lo he visto de refilón.
La verdad es que son muy parecidos esos términos a master/slave ...
Como siempre, MHO,
Yo no tengo opinión todavía al respecto. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
participants (6)
-
Alberto Planas Dominguez
-
Ancor Gonzalez Sosa
-
Carlos E. R.
-
Carlos E.R.
-
Juan Erbes
-
Rafa Griman