openSUSE Users (Español) August 2017

users-es@lists.opensuse.org

11 participants
11 discussions

[opensuse-es] Desfragmentación de volumenes XFS
by Juan Erbes 18 Apr '22

18 Apr '22

Sabiendo que la partición /home tenía ciertas inconsistencias, que había reparado a lo bruto con el comando: xfs_repair -L /dev/sdb2 Sabía que debía desfragmentarla, consulté y había contestado Carlos al respecto. Parte de la información, fue util, para ver el porcentage de fragmentación: xfs_db -c frag -r /dev/sdb2 Basado en la inercia de que con otros sistemas uno debe realizar la desfragmentación con la partición desmontada, motivo por el cual arranque con el DVD de instalación en modo "Rescue" (rescate), y ejecuté primero el comando citado, el cual me arrojó una fragmentación del 47.4% (adjunto captura de pantalla). Pero no encontré la forma de ejecutar el comando de desfragmentación xfs_fsr. Opté por iniciar normalmente el sistema, y me acordé del comando man, para ver como ejecutar el comando en cuestión, y allí me entero de que el volumen o partición puede estar montado, PERO NO MUEVE LOS ARCHIVOS ABIERTOS EN MEMORIA. Ver: man xfs_fsr Inicié la desfragmentación con el comando: xfs_fsr -vdg Despues de poco mas de una hora, vi que había terminado de desfragmentar la unidad de 1.8 TB, que tiene alrededor de 1 TB ocupado. Para ver como quedó, ejecuté: xfs_db -c frag -r /dev/sdb2 actual 309339, ideal 308055, fragmentation factor 0,42% Ojo! No se debería utilizar en unidades SSD. Aqui va parte del texto del manual: (en consola man xfs_fsr) When invoked with no arguments xfs_fsr reorganizes all regular files in all mounted filesystems. xfs_fsr makes many cycles over /etc/mtab each time making a single pass over each XFS filesystem. Each pass goes through and selects files that have the largest number of extents. It attempts to defragment the top 10% of these files on each pass. It runs for up to two hours after which it records the filesystem where it left off, so it can start there the next time. This information is stored in the file /var/tmp/.fsrlast_xfs. If the information found here is somehow inconsistent or out of date it is ignored and reorganization starts at the beginning of the first filesystem found in /etc/mtab. xfs_fsr can be called with one or more arguments naming filesystems (block device name), and files to reorganize. In this mode xfs_fsr does not read or write /var/tmp/.fsrlast_xfs nor does it run for a fixed time interval. It makes one pass through each specified regular file and all regular files in each specified filesystem. A command line name referring to a symbolic link (except to a file system device), FIFO, or UNIX domain socket generates a warning message, but is otherwise ignored. While traversing the filesystem these types of files are silently skipped. FILES /etc/mtab contains default list of filesystems to reorganize. /var/tmp/.fsrlast_xfs records the state where reorganization left off. SEE ALSO xfs_fsr(8), mkfs.xfs(8), xfs_ncheck(8), xfs(5). NOTES xfs_fsr improves the layout of extents for each file by copying the entire file to a temporary location and then interchanging the data extents of the target and temporary files in an atomic man- ner. This method requires that enough free disk space be available to copy any given file and that the space be less fragmented than the original file. It also requires the owner of the file to have enough remaining filespace quota to do the copy on systems running quotas. xfs_fsr generates a warning message if space is not sufficient to improve the target file. A temporary file used in improving a file given on the command line is created in the same parent directory of the target file and is prefixed by the string '.fsr'. The temporary files used in improving an entire XFS device are stored in a directory at the root of the target device and use the same naming scheme. The temporary files are unlinked upon creation so data will not be read- able by any other process. xfs_fsr does not operate on files that are currently mapped in memory. A 'file busy' error can be seen for these files if the verbose flag (-v) is set. -- 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/

6 29

[opensuse-es] tumbleweed o leap?
by miguel gmail 15 Dec '17

15 Dec '17

Buenos días, tengo una opensuse 11.x instalada de la que estoy tan contento que ni me planteaba tocarla, pero hay un paquete que me gustaría probar su última versión (Darktable 2.0.5, creo, me valdría cualquier 2.x.x). Y tengo dudas de qué es más conveniente para mí, si Leap o Tumbleweed... y a cuál de las dos es más sencilla de actualizar desde mi 11.x (tan satisfecho estoy con ella que ni sé qué versión exacta tengo instalada) Cuáles son vuestras opiones, recomendaciones y experiencias propias? No tengo muchos requisitos, la verdad... solo seguir usando diversos sw de revelado de imágenes raws (darktable, photivo, rawtherapee...), cosas como chrome. También tengo mil particiones 'legacy' que bajo ningún concepto puedo perder, como /home, /datos, /old-linux... Imagino que el proceso de actualización ya es lo suficientemente maduro como para no preocuparme demasiado :-) Gracias mil por vuestras reflexiones. s2, M.Calero -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

8 55

[opensuse-es] systemd-coredump usando todos los cpu al 100%
by H. Gabriel Máculus 17 Aug '17

17 Aug '17

Estimados en la reciente actualizacion de opensuse 42.3 empece a tener el problema que systemd-coredump usa todos los procesadores al 100%, obviamente se trata de un bug, la unica solucion que encontre es: # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # # Entries in this file show the compile time defaults. # You can change settings by editing this file. # Defaults can be restored by simply deleting this file. # # See coredump.conf(5) for details. [Coredump] #Storage=external Storage=none #Compress=yes #ProcessSizeMax=2G #ExternalSizeMax=2G #JournalSizeMax=767M #MaxUse= #KeepFree= agregar la linea Storage=none espero le sirva si a alguien le pasa, espero tener pronto una mejor solucion a esto. -- H. Gabriel Máculus http://twitter.com/gabrielix - https://prism-break.org/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

4 3

[opensuse-es] Consumo de los chismes en standby
by Carlos E. R. 16 Aug '17

16 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.11.1404290118140.18405(a)minas-tirith.valinor> Hola: Se habla de lo mucho que gastan los chismes que dejamos encendidos en "standby". Pues me he comprado un chisme para ver donde estoy yo gastando más electricidad. Bueno, pues mi armario de chismes en standby gasta unos 25 watios. ¿Mucho? Pues la verdad es que no, porque tengo: Un SAI en activo. Dos SAIs en standby. La base del teléfono inalámbrico de la casa. Un sistema grabador multimedia en standby. Un televisor en standby. El router, si está activo, parece añadir unos 5 watios. Algunos pilotitos de neón de las regletas. Y me parece que me olvido algo, ahora no estoy en casa. No me parece tanto consummo... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlNe46MACgkQja8UbcUWM1wGLwD9FOZT151fXhoqfN5X/GwUcNZS hpC5tQDDyju9QedTKW0A/jOe9kRaoQOJ/S4+LKnyTLDGsVkuYhzRImuYFDnI6kaN =SrfM -----END PGP SIGNATURE-----

8 20

[opensuse-es] AMD confirma problema con Ryzen en Linux
by Carlos Ayala 12 Aug '17

12 Aug '17

Saludos esto salió en /. AMD Confirms Linux 'Performance Marginality Problem' On Ryzen ( https://linux.slashdot.org/story/17/08/07/2056245/amd-confirms-linux-perfor… ) AMD a reconocido oficialmente que usuarios de Ryzen experimentan problemas de segmentación en Linux cuando se ejecutan varios procesos de compilación. Lo describen como "problema de rendimiento marginal" (performance marginality problem) que afecta a algunos usuarios de Ryzen y solo en Linux. AMD confirmó que los procesadores Threadripper y Epyc no están afectados; resolveran los problemas con cada uno de los usuarios y los productos futuros tendrán una mejor prueba/validación con Linux. [...] Michael Larabel escribe via Phoronix: "COn los problemas de segmentación de Ryzen en Linux ocurren con varias cargas de trabajo de compilación en paralelo -- ciertamente no las cargas de trabajo usuales para usuarios de Linux a menos que ejecuten scrips como ryzen-text/kill-ryzen[...]". Estar pendientes al respecto. ;) -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

3 4

Re: [opensuse-es] systemd-coredump usando todos los cpu al 100%
by Carlos E. R. 11 Aug '17

11 Aug '17

On 2017-08-09 17:56, H. Gabriel Máculus wrote: > El 9 de agosto de 2017, 10:44, Carlos E. R. <> escribió: >> On 2017-08-09 05:56, H. Gabriel Máculus wrote: Acuérdate de escribir a la lista, no en privado. ... >> A ver, esa solución es mala. El problema no es coredump, el problema es >> que alguna otra aplicación te está petando. coredump unicamente recoge >> los restos. >> > Claro que es mala pero el problema si es coredump porque ninguna > aplicacion se cierra, se dispara coredump y ocupa todos los > procesadores de mi notebook causando sobrecalentamiento y dejando el > sistema casi inusable. > > >> ¿Que aplicación es la que te peta? >> Si no lo sabes, está en el log. Por ejemplo: >> >> journalctl | grep coredump >> >> > Aug 04 09:39:08 linux-5yjr systemd-coredump[17475]: Removed old > coredump core.kded5.1000.cf012abed7f64377809cf39b9dd255e7.13549.1501850341000000.xz. > Aug 04 09:39:08 linux-5yjr systemd-coredump[17475]: Process 13549 > (kded5) of user 1000 dumped core. > Failed to get journal fields: Bad message Pues ahí o tienes: es kded5 el que está reventando. > > >> >> Y por cierto, lo que ocupa la CPU del proceso systemd-coredump es la >> compresión, que también se puede desactivar - pero te llena el disco. >> > o sea con compresion te liquida el cpu y sin compresion te liquida el > disco, menuda basura el systemd Joer, y dale. Lo haga quien lo haga, el kernel está detectando que hay un programa que ha petado. Ha recogido la basura para su estudio y se la ha pasado al systemd, quien se limita a decírtelo y a guardarla durante una semana, y luego la borrará. No confundas al mensajero con el culpable. Es como si el coche se te para en mitad de la autovía, y le pitas a la grúa por estorbar. Lo que has hecho es decirle al sistema que tire el coche al barranco y que se olvide. > podria ser que se corrompe el log y eso causa la falla en coredump? No hay ninguna falla en coredump. Tienes una falla gorda en kded5. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

4 5

Re: [opensuse-es] systemd-coredump usando todos los cpu al 100%
by Carlos E. R. 10 Aug '17

10 Aug '17

On 2017-08-10 04:54, H. Gabriel Máculus wrote: > El 9 de agosto de 2017, 21:37, Carlos E. R. <> escribió: >>> la solucion fue eliminar los logs dañados y todo volvio a la >>> normalidad, voy a tratar de reproducirlo para reportarlo creo que es >>> mejor que discutir con un creyente. >> >> Y te mandarán a freir monas, y eso que yo no soy creyente. >> >> Te aconsejo que no discutas con ellos sobre systemd. El otro dia >> expulsaron a dos de las listas, foros, irc, de todo, por hacerlo, y a >> perpetuidad. >> >> >> Y en este caso, no tienes razón. A mi no me gusta systemd, prefiero >> initd, pero en este caso no hay problema con systemd. El problema viene >> de otro/otros procesos que provocan esos síntomas en systemd. >> >> > Estoy seguro porque el log termina ahi y era el archivo corrupto el > que le causaba la falla. > > Cuando te digo que systemd-coredump no puede lidiar con archivos corruptos > > kde no existe mas y no hay ningun proceso "petando" porque lo deje en > modo texto y el coredump sigue igual. > no se porque tanta persistencia y tanta testarudez en no creer ni una > palabra de lo que te digo y elegir ponerte > a discutir sobre un proceso que no ves en una maquina que no conoces > con una persona que vive en otro continente > sera solo por el afan de discutir o buscar quedar bien con una > audiencia que lee? No muestras evidencias. Es muy conocido que systemd comprime los coredumps, que son capturados por el kernel cuando se cae una aplicación. Y que el hecho de comprimir ficheros gigantescos ocupa la cpu al 100% durante un rato. Y si se caen varias aplicaciones seguidas, o la misma varias veces, tienes al systemd-coredump ocupado durante un buen rato. Y que por supuesto, puedes decidir no guardar los coredumps con lo que el problema _parece_ resuelto. Pero insisto, lo que tienes que buscar es qué aplicación es la que está petando, me quieras creer o no. Si da la casualidad que el journal está corrupto (a mi no me gusta nada el sistema de journal del system, me parece horrible) eso no tiene nada que ver con el problema. systemd-coredump no lo usa, solo manda escribir una linea o dos, lo mismo que miles de procesos en el sistema. Puñetera manía de culpar al systemd de todo incluso cuando es inocente. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

1 0

[opensuse-es] Se vuelve a calentar el mercado de microprocesadores
by Juan Erbes 10 Aug '17

10 Aug '17

A dos años de finalizado el acuerdo de licencias cruzadas entre intel y AMD https://www.kitguru.net/components/cpu/anton-shilov/amd-clarifies-cross-lic… Por primera vez en unos diez años, Intel se vio obligado a responder a AMD, en este caso al anunciar Xeons reutilizado como Core i9 con hasta 18 núcleos. https://www.redsharknews.com/technology/item/4793-why-amd’s-ryzen-threadrip… -- 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(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 1

[opensuse-es] Aviso al actualizar
by Josep 09 Aug '17

09 Aug '17

Hola, Tengo el driver propietario de Nvidia instal·lado por razones que no vienen al caso. I tengo puesto las actualizaciones pertinentes. Hoy al intentar actualizar mediante zypper obtengo: # zypper up Loading repository data... Reading installed packages... The following 3 NEW packages are going to be installed: libx265-130 noto-coloremoji-fonts noto-emoji-fonts The following 5 applications are going to be REMOVED: Audacity K3b "KDE Connect" Kdenlive "VLC Media player" The following 116 packages are going to be upgraded: GraphicsMagick MPlayer audacity audacity-lang btrfsmaintenance catdoc chromedriver chromium dracut dracut-tools dvdrip ffmpeg gmplayer gpac gstreamer-0_10-plugins-bad gstreamer-0_10-plugins-bad-lang gstreamer-0_10-plugins-ugly gstreamer-0_10-plugins-ugly-lang gstreamer-0_10-plugins-ugly-orig-addon handbrake-cli handbrake-gtk handbrake-gtk-lang icoutils iptables k3b k3b-lang kdeconnect-kde kdeconnect-kde-lang kdenlive libGraphicsMagick-Q16-3 libGraphicsMagick3-config libLLVM libLLVM-32bit libXi6 libXi6-32bit libXvnc1 liba52-0 libavcodec56 libavcodec57 libavdevice56 libavdevice57 libavfilter5 libavfilter6 libavformat56 libavformat57 libavresample2 libavresample3 libavutil54 libavutil55 libgpac6 libgstbasecamerabinsrc-0_10-23 libgstbasevideo-0_10-23 libgstcodecparsers-0_10-23 libgstphotography-0_10-23 libgstsignalprocessor-0_10-23 libgstvdp-0_10-23 libical1 libiptc0 libjasper1 libjasper1-32bit libmpg123-0 libopenshot-audio3 libopenshot1 libpoppler-glib8 libpoppler-qt4-4 libpoppler-qt5-1 libpoppler60 libpostproc53 libpostproc54 libprocps3 libswresample1 libswresample2 libswscale3 libswscale4 libsystemd0 libsystemd0-32bit libudev1 libudev1-32bit libvlc5 libvlccore8 libxtables10 nvidia-computeG03 nvidia-gfxG03-kmp-default nvidia-glG03 nvidia-uvm-gfxG03-kmp-default oce openshot-qt oxygen5-icon-theme oxygen5-icon-theme-large perl-Bootloader perl-Bootloader-YAML poppler-tools procps python3-openshot release-notes-openSUSE smartmontools systemd systemd-32bit systemd-bash-completion systemd-logger systemd-sysvinit tigervnc transcode ucode-intel udev virtualbox-guest-kmp-default vlc vlc-codec-gstreamer vlc-codecs vlc-lang vlc-noX vlc-qt x11-video-nvidiaG03 xorg-x11-Xvnc xtables-plugins youtube-dl 116 packages to upgrade, 3 new. Overall download size: 356.5 MiB. Already cached: 0 B. After the operation, additional 13.8 MiB will be used. Continue? [y/n/...? shows all options] (y): y Retrieving package nvidia-gfxG03-kmp-default-340.102_k4.4.27_2-18.1.x86_64 (1/119), 3.6 MiB ( 28.0 MiB unpacked) Retrieving: nvidia-gfxG03-kmp-default-340.102_k4.4.27_2-18.1.x86_64.rpm .........................[done] Warning: Digest verification failed for file 'nvidia-gfxG03-kmp-default-340.102_k4.4.27_2-18.1.x86_64.rpm' [/var/cache/zypp/packages/download.nvidia.com-leap/x86_64/nvidia-gfxG03-kmp-default-340.102_k4.4.27_2-18.1.x86_64.rpm] expected d9844df9a3ffa3c110d16c447293a633ca4e71013c52e3c14011145742f1bfa0 but got cef17e27677f0e66bd0b00d48f66d94479699fd4aebe1929d62d2425457715b9 Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise. However if you made certain that the file with checksum 'cef1..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file. Unblock or discard? [cef1/...? shows all options] (discard): Entiendo que Nvidia debe haber cambiado el código de verificación y que por tanto desbloqueando el paquete... no tiene por que corromperse o comprometerse el sistema. Estoy en lo cierto? Teneis algun sugerimiento? Gracias de antemano -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

2 2

[opensuse-es] Gravit Designer - Software para diseño vectorial
by Carlos Ayala 08 Aug '17

08 Aug '17

Saludos lo acabo de encontrar en twitter. Envato creo un tutorial al respecto y estaba con el temor de que solo fuera Windows y MacOS, pero sorpresa que tiene un paquete para linux y otras plataformas... de repente una chromebook se vuelve deseable. Aquí el enlace: https://www.designer.io/ -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe(a)opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help(a)opensuse.org

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

openSUSE Users (Español) August 2017