Re: Desktop "locking".
From: Cindy Sue Causey Date: Thu, 16 Dec 2021 11:04:06 -0500 > There must be a way to track down what's invoking that button's image. Yes, identifying an entity in software ought to be straightforward but isn't always. Good practice in software engineering isn't recognized as in more traditional disciplines. =8~| The window with green button could easily show a package name or program name. "green-phantom" or whatever. > ... I plugged the image into Google's image search. I had high > hopes that would find something, but it said nope, nothing matches. It > did identify the image as a dot and said: > ... Likely Google will find the citation in debian-user before January. Regards, ... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W
Re:[solved] Broken libc6 running Sid (multiarch sytem)
On 12/19/21 18:12, Mark Allums wrote: On 12/19/2021 2:30 AM, Andrei POPESCU wrote: On Du, 19 dec 21, 07:24:56, Tim Woodall wrote: On Sat, 18 Dec 2021, Mark Allums wrote: Preparing to unpack .../libc6_2.33-1_amd64.deb ... Unpacking libc6:amd64 (2.33-1) over (2.34-0experimental1) ... dpkg: error processing archive /var/cache/apt/archives/libc6_2.33-1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/doc/libc6/NEWS.gz', which is different from other instances of package libc6:amd64 I'd delete that file and try again. (move it to the side if it's something you might want to consult) According to my understanding of the manpage it should work with an added '--force-overwrite'. Kind regards, Andrei Thanks. I'll try that soonest. I'll let everybody know. Mark Allums It worked, with lots of warnings. I did overlook the option --force-overwrite in the man page. Once I got the main libc6 squared away, I ran the interactive Aptitude and let the solver correct the other libc6-related packages, and also removed lintian, as I am not a package maintainer. Everything is now cleared up. I am running Bookworm, with some Sid packages (or Sid with some Bookworm packages, if you prefer.) I do occasionally install a new NVIDIA driver or kernel from experimental, and I currently have installed gcc-12 for the heck of it. If I depended on this machine for a main system (aka production), I of course wouldn't do this. I installed the new libc6 as a lark, but since it is an essential package and since I am not a maintainer, I should not have done so. Thanks Andrei, for your perusal of the man page on my behalf. Mark Allums
Re: kfilereplace
Muchas gracias Camaleón! Regexxer es una buena alternativa a kfilereplace. Ademas, queda perfectamente integrado en Mate. Gracias de nuevo! Y un saludo a tod@s! El vie, 17 dic 2021 a las 18:14, Jose Ab bA () escribió: > Hola Amig@s! > > Hace algun tiempo que quiero usar kfilereplace en bullseye, pero no > consigo instalarlo desde los repositorios oficiales. > > Sabeis que ha pasado con este paquete? > > Alguna manera "segura" de instarlo? ...me refiero a, algun repositorio de > confianza. > > Alguna otra aplicacion que lo sustituya en los repositorios oficiales, > para Mate Desktop por ejemplo? > > Gracias por vuestro tiempo de antemano. > > Y un saludo! >
dvorak keymap misconfigured in bullseye
I installed release 11.2 for amd64. In the installer, I asked for the Dvorak keymap and XFCE desktop. After a successful install, I used Applications Menu > Settings > Keyboard and then > Variants to select the "Classic" Dvorak keymap. The change was not effective, even after rebooting; the default Dvorak keymap is still in effect. I attempted to switch to English (US), but that too was ineffective. And now the Variant tab brings up the ADD menu. -- How should one chase a thousand, and two put ten thousand to flight, except their Rock had sold them, and the Lord had shut them up? - Deuteronomy 32:30
Re: Broken libc6 running Sid (multiarch sytem)
On 12/19/2021 2:30 AM, Andrei POPESCU wrote: On Du, 19 dec 21, 07:24:56, Tim Woodall wrote: On Sat, 18 Dec 2021, Mark Allums wrote: Preparing to unpack .../libc6_2.33-1_amd64.deb ... Unpacking libc6:amd64 (2.33-1) over (2.34-0experimental1) ... dpkg: error processing archive /var/cache/apt/archives/libc6_2.33-1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/doc/libc6/NEWS.gz', which is different from other instances of package libc6:amd64 I'd delete that file and try again. (move it to the side if it's something you might want to consult) According to my understanding of the manpage it should work with an added '--force-overwrite'. Kind regards, Andrei Thanks. I'll try that soonest. I'll let everybody know. Mark Allums
Re: osinfo-query os missing debian Bullseye
On Mon, 20 Dec 2021 at 04:36, Dan Ritter wrote:
> john doe wrote:
> > As far as I can tell, the command 'osinfo-query os' does not
> > support/list 'debian11'.
> > I need to fire up a Bullseye VM what is the best way forward?
> What does osinfo-query have to do with installing a VM?
I expect it will be something like seen here:
https://wiki.debian.org/KVM?highlight=%28os-variant%29
'virt-install' takes an '--os-variant' argument. The known
values of that argument are queried by an 'osinfo-query'
command.
$ osinfo-query os | awk -e '/debian/ {print $1}'
debian1.1
debian1.2
debian1.3
debian10
debian2.0
debian2.1
debian2.2
debian3
debian3.1
debian4
debian5
debian6
debian7
debian8
debian9
debiantesting
$ cat /etc/debian_version
11.2
$ dpkg -S osinfo-query
libosinfo-bin: /usr/bin/osinfo-query
libosinfo-bin: /usr/share/man/man1/osinfo-query.1.gz
$ apt list --installed libosinfo-bin
Listing... Done
libosinfo-bin/stable,now 1.8.0-1 amd64 [installed]
I just use '--os-variant debiantesting' until someone
gives better advice.
Re: 8 -> 9 update changing things
Roy J. Tellason, Sr. wrote: > On Sunday 19 December 2021 03:18:46 am Andrei POPESCU wrote: > > On Sb, 18 dec 21, 11:24:34, Roy J. Tellason, Sr. wrote: > > > > > > There remains the sound issue in the virtualbox. Could it be that > > > Debian isn't running PulseAudio but something else? That would > > > account for the guest OS not being able to talk to it... > > > > As far as I'm aware there is no default sound server in Debian, it's > > whatever the corresponding Desktop Environment depends on. Usually this > > is PulseAudio, but it seems PipeWire is becoming more popular. > > Well, sound on the Debian side of things works, as in playing youtube > videos and such. It doesn't work in the Slackware virtualbox, which is > apparently trying to connect to Pulseaudio. Going through the Xfce > application menus just now I see very little that would tell me what it is > that's actually running here, so I figure I probably need to typs something > on the command line in a terminal, but I don't know what. > > One thing that shows up in the Xfce application menu under multimedia is > "Pulseaudio Volume Control". When I invoke this a small window pops up, > with the text "Establishing connection to Pulseaudio. Please wait" and then > nothing happens, even if I let it sit there for quite a while. > > Suggestions as to where I might look for the problem? In general, that message means that even if there is a copy of the pulseaudio daemon running, it is not running with the right userid and the X11 session you are running in doesn't know about it. Run "pulseaudio --start" and try again. -dsr-
Re: Risc-V [OT: Firefox ESR EOL]
On 2021-12-19 3:13 a.m., Andrei POPESCU wrote: > On Sb, 18 dec 21, 14:22:58, David Newman wrote: >> On Dec 18, 2021, at 12:44, Nicholas Geovanis wrote: >>> >>> > On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU > wrote: > On Jo, 09 dec 21, 23:24:11, Marco Möller wrote: >> >> It's a pity that Debian cannot be flexible to offer more secure and >> already >> available binary versions of software for the assumed many users only >> caring >> for installing a binary from the official Debian repository on some very > ARM64 is likely to see *more* (not less) use in desktops and laptops, and RISC V might also be an option in the future. >>> >>> >>> Maybe I missed something. Why RISC V? >> >> RISC V is open-source hardware, free of encumbrances from commercial >> licenses and fees. Would you have some suggestion if I'd like to try out a Risc-V board ? Would be interested in building a test system on this architectures. Do you have some links for buying already built board (and possibly that would include some type of graphic hardware if it's possible). Something like a Raspberry Pi but with a Risc-V chipset ? Thanks > > As well as free from embargoes, so it might be very interesting for chip > makers in countries affected by such. > > It's also quite promising in the performance per watt area and > performance per square mm, even compared to ARM (which is already better > than x86 chips). > > Kind regards, > Andrei > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development OpenPGP_signature Description: OpenPGP digital signature
Re: pulseaudio ne démarre plus: segfault in libasound.so.2.0.0
Le dimanche 19 décembre 2021 à 16:11 +0100, dstc a écrit : > > prière de le désabonner à la liste, svp, > > je l'ai déjà demandé à plusieurs endroits visiblement sans succès. Bonjour, De même que vous ne voudriez pas que l'un de ceux qui fréquentent cette liste de diffusion (de simples utilisateurs, tout comme vous) puisse se présenter au guichet de votre banque en se faisant passer pour vous et vider votre compte en banque, Debian a mis en place une sécurité qui évite que quelqu'un d'autre que vous ne vous désabonne à votre place. Veuillez lire attentivement le petit chapitre "abonnement et désabonnement" (jusqu'au titre "code de conduite" exclu) de la page sur les listes de diffusion du site web Debian: https://www.debian.org/MailingLists/index.fr.html#subunsub qui vous précisera les étapes à suivre si vous souhaitez que vos tentatives de désabonnement soient couronnées de succès Merci :-)
Re: 8 -> 9 update changing things
On Sunday 19 December 2021 03:18:46 am Andrei POPESCU wrote: > On Sb, 18 dec 21, 11:24:34, Roy J. Tellason, Sr. wrote: > > > > There remains the sound issue in the virtualbox. Could it be that > > Debian isn't running PulseAudio but something else? That would > > account for the guest OS not being able to talk to it... > > As far as I'm aware there is no default sound server in Debian, it's > whatever the corresponding Desktop Environment depends on. Usually this > is PulseAudio, but it seems PipeWire is becoming more popular. Well, sound on the Debian side of things works, as in playing youtube videos and such. It doesn't work in the Slackware virtualbox, which is apparently trying to connect to Pulseaudio. Going through the Xfce application menus just now I see very little that would tell me what it is that's actually running here, so I figure I probably need to typs something on the command line in a terminal, but I don't know what. One thing that shows up in the Xfce application menu under multimedia is "Pulseaudio Volume Control". When I invoke this a small window pops up, with the text "Establishing connection to Pulseaudio. Please wait" and then nothing happens, even if I let it sit there for quite a while. Suggestions as to where I might look for the problem? -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: Salida audio en mini PC
El 2021-12-19 a las 18:18 +0100, Josu Lazkano escribió: > El dom, 19 dic 2021 a las 13:42, Camaleón () escribió: > > > El 2021-12-19 a las 12:07 +0100, Josu Lazkano escribió: > > > > > Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para > > > reproducir música, lo tengo sin interfaz gráfico, en modo servidor. > > > > > > Pero no acierto a hacer un test: > > > > > > $ speaker-test -D default -c 8 > > > speaker-test 1.2.4 > > > > > > Playback device is default > > > Stream parameters are 48000Hz, S16_LE, 8 channels > > > Using 16 octaves of pink noise > > > Rate set to 48000Hz (requested 48000Hz) > > > Buffer size range from 96 to 204768 > > > Period size range from 48 to 102384 > > > Using max buffer size 204768 > > > Periods = 4 > > > Unable to set hw params for playback: Argumento inválido > > > Setting of hwparams failed: Argumento inválido > > > > (...) > > > > Dale un vistado a la página de MythTV donde explican bastante bien cómo > > probar con esa utilidad y cómo pasarle los parámetros adecuados, aunque > > me temo que el éxito de tu misión va a ser una cuestión de prueba-error > > :-): > > > > Using ALSA's speaker-test utility > > https://www.mythtv.org/wiki/Using_ALSA%27s_speaker-test_utility > > > Se me ha escapado el correo antes de tiempo... sigo: > > $ speaker-test > > speaker-test 1.2.4 > > El dispositivo de reproducción es default > Los parámetros del flujo son 48000Hz, S16_LE, 1 canales > Usando 16 octavas de ruido rosa > Frecuencia establecida a 48000Hz (se solicitó 48000Hz) > El rango del tamaño del buffer va desde 192 hasta 2097152 > El rango del tamaño del perído va desde 64 hasta 699051 > Utilizando el tamaño máximo de buffer 2097152 > Periodos = 4 > fue establecido period_size = 524288 > fue establecido buffer_size = 2097152 > 0 - Frontal izquierdo > ^CTiempo por período = 10,933915 > > Pero parece que el mini PC este no asigna bien el dispositivo por defecto, > o al menos me casca si no le pongo un dispositivo: > > $ speaker-test > > speaker-test 1.2.4 > > Playback device is default > Stream parameters are 48000Hz, S16_LE, 1 channels > Using 16 octaves of pink noise > Rate set to 48000Hz (requested 48000Hz) > Buffer size range from 96 to 204768 > Period size range from 48 to 102384 > Using max buffer size 204768 > Periods = 4 > Unable to set hw params for playback: Argumento inválido > Setting of hwparams failed: Argumento inválido > > No se que poner en el parámetro -D, he probado con diferentes opciones, > pero todos dan error. > > Me gustaría probar a instalar Buster con escritorio, pero tengo bastantes > servicios corriendo y no puedo formatearlo. > > ¿Se os ocurre qué más puedo probar? Compara el contenido del archivo .asoundrc en ambos equipos, y en cualquier caso, prueba a renombrarlo en el minipc para que ALSA no lo tome, quizá tengas definidia alguna configuración que le dé problemas a la utilidad speaker-test. También puedes buscar por el error que te saca cuando lo ejecutas sin parámetros, por si te diea alguna pista del problema: https://www.google.com/search?q=speaker-test+unable+to+set+hw+params+for+playback+invalid+argument Saludos, -- Camaleón
Re: Salida audio en mini PC
En tantos años de usar debian con openbox nunca tuve problemas con el audio, ni con el sonido trasero o el del panel frontal, siempre lo manejé con alsamixer desde la consola, el icono de la barra solo lo tenia para subir y bajar el volumen, este año armé un desktop nuevo y si tuve problemas con el sonido en openbox, de plano no escuchaba nada o solo un ruido como de interferencia, en algún sitio leí que para resolver sin tanto alboroto lo mejor era instalar pulseaudio, eso hice y en mi caso funcionó perfecto, aunque igual se puede ajustar por alsamixer algunas cosas como el volumen del micrófono, lo que instalo de alsa es: alsa-oss alsa-tools alsa-utils y del pulseadio solo me aparece instalado: pulseaudio pulseaudio-utils su pueden instalar algunos otros módulos de pulseaudio pero con eso ya me funciona, creo existen paquetes para poder configurar pulseaudio desde la consola al estilo alsamixer pero no he probado, y encontré esta pagina que quizas te pueda ayudar/interesar http://davidegironi.blogspot.com/2019/10/linux-mint-on-z83-f-intel-atom-x5-z8350.html#.Yb9jUnVBwkk para terminar yo tengo openbox con solo lo que necesito y de entrada solo carga en memoria según htop unos 450mb +/- eso si no abras firefox o chrome porque se van al chancho los mb, esos dos trastes cargan más mb en memoria que el mismo sistema completo :) El dom, 19 dic 2021 a las 8:08, Josu Lazkano () escribió: > Hola a todos, > > Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para > reproducir música, lo tengo sin interfaz gráfico, en modo servidor. > > Pero no acierto a hacer un test: > > $ speaker-test -D default -c 8 > speaker-test 1.2.4 > > Playback device is default > Stream parameters are 48000Hz, S16_LE, 8 channels > Using 16 octaves of pink noise > Rate set to 48000Hz (requested 48000Hz) > Buffer size range from 96 to 204768 > Period size range from 48 to 102384 > Using max buffer size 204768 > Periods = 4 > Unable to set hw params for playback: Argumento inválido > Setting of hwparams failed: Argumento inválido > > Esta es la info de mi tarjeta: > > $ aplay -l > List of PLAYBACK Hardware Devices > card 0: bytcrrt5651 [bytcr-rt5651], device 0: Audio (*) [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: bytcrrt5651 [bytcr-rt5651], device 1: Deep-Buffer Audio (*) [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Audio [Intel HDMI/DP LPE Audio], device 0: HdmiLpeAudio [Intel > HDMI/DP LPE Audi] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Audio [Intel HDMI/DP LPE Audio], device 1: HdmiLpeAudio [Intel > HDMI/DP LPE Audi] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: Audio [Intel HDMI/DP LPE Audio], device 2: HdmiLpeAudio [Intel > HDMI/DP LPE Audi] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > $ aplay -L > null > Discard all samples (playback) or generate zero samples (capture) > hw:CARD=bytcrrt5651,DEV=0 > bytcr-rt5651, > Direct hardware device without any conversions > hw:CARD=bytcrrt5651,DEV=1 > bytcr-rt5651, > Direct hardware device without any conversions > plughw:CARD=bytcrrt5651,DEV=0 > bytcr-rt5651, > Hardware device with all software conversions > plughw:CARD=bytcrrt5651,DEV=1 > bytcr-rt5651, > Hardware device with all software conversions > default:CARD=bytcrrt5651 > bytcr-rt5651, > Default Audio Device > sysdefault:CARD=bytcrrt5651 > bytcr-rt5651, > Default Audio Device > dmix:CARD=bytcrrt5651,DEV=0 > bytcr-rt5651, > Direct sample mixing device > dmix:CARD=bytcrrt5651,DEV=1 > bytcr-rt5651, > Direct sample mixing device > hw:CARD=Audio,DEV=0 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Direct hardware device without any conversions > hw:CARD=Audio,DEV=1 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Direct hardware device without any conversions > hw:CARD=Audio,DEV=2 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Direct hardware device without any conversions > plughw:CARD=Audio,DEV=0 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Hardware device with all software conversions > plughw:CARD=Audio,DEV=1 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Hardware device with all software conversions > plughw:CARD=Audio,DEV=2 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Hardware device with all software conversions > default:CARD=Audio > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Default Audio Device > sysdefault:CARD=Audio > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > Default Audio Device > hdmi:CARD=Audio,DEV=0 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > HDMI Audio Output > hdmi:CARD=Audio,DEV=1 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > HDMI Audio Output > hdmi:CARD=Audio,DEV=2 > Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi > HDMI Audio Output > dmix:CARD=Audio,DEV=0 > Intel HDMI/DP LPE Audio, Intel
Re: osinfo-query os missing debian Bullseye
john doe wrote: > As far as I can tell, the command 'osinfo-query os' does not > support/list 'debian11'. > > I need to fire up a Bullseye VM what is the best way forward? What does osinfo-query have to do with installing a VM? Pick a VM technology: kvm is built-in, but there are other choices. libvirtd can manage most of them. You can get a complete VM image to run, or build one via debootstrap or another tool. What are you trying to do? -dsr-
Re: Salida audio en mini PC
El dom, 19 dic 2021 a las 13:42, Camaleón () escribió: > El 2021-12-19 a las 12:07 +0100, Josu Lazkano escribió: > > > Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para > > reproducir música, lo tengo sin interfaz gráfico, en modo servidor. > > > > Pero no acierto a hacer un test: > > > > $ speaker-test -D default -c 8 > > speaker-test 1.2.4 > > > > Playback device is default > > Stream parameters are 48000Hz, S16_LE, 8 channels > > Using 16 octaves of pink noise > > Rate set to 48000Hz (requested 48000Hz) > > Buffer size range from 96 to 204768 > > Period size range from 48 to 102384 > > Using max buffer size 204768 > > Periods = 4 > > Unable to set hw params for playback: Argumento inválido > > Setting of hwparams failed: Argumento inválido > > (...) > > Dale un vistado a la página de MythTV donde explican bastante bien cómo > probar con esa utilidad y cómo pasarle los parámetros adecuados, aunque > me temo que el éxito de tu misión va a ser una cuestión de prueba-error > :-): > > Using ALSA's speaker-test utility > https://www.mythtv.org/wiki/Using_ALSA%27s_speaker-test_utility > > Saludos, > > -- > Camaleón > > Se me ha escapado el correo antes de tiempo... sigo: $ speaker-test speaker-test 1.2.4 El dispositivo de reproducción es default Los parámetros del flujo son 48000Hz, S16_LE, 1 canales Usando 16 octavas de ruido rosa Frecuencia establecida a 48000Hz (se solicitó 48000Hz) El rango del tamaño del buffer va desde 192 hasta 2097152 El rango del tamaño del perído va desde 64 hasta 699051 Utilizando el tamaño máximo de buffer 2097152 Periodos = 4 fue establecido period_size = 524288 fue establecido buffer_size = 2097152 0 - Frontal izquierdo ^CTiempo por período = 10,933915 Pero parece que el mini PC este no asigna bien el dispositivo por defecto, o al menos me casca si no le pongo un dispositivo: $ speaker-test speaker-test 1.2.4 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 204768 Period size range from 48 to 102384 Using max buffer size 204768 Periods = 4 Unable to set hw params for playback: Argumento inválido Setting of hwparams failed: Argumento inválido No se que poner en el parámetro -D, he probado con diferentes opciones, pero todos dan error. Me gustaría probar a instalar Buster con escritorio, pero tengo bastantes servicios corriendo y no puedo formatearlo. ¿Se os ocurre qué más puedo probar? Gracias y un saludo. -- Josu Lazkano
Re: Salida audio en mini PC
El dom, 19 dic 2021 a las 13:42, Camaleón () escribió: > El 2021-12-19 a las 12:07 +0100, Josu Lazkano escribió: > > > Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para > > reproducir música, lo tengo sin interfaz gráfico, en modo servidor. > > > > Pero no acierto a hacer un test: > > > > $ speaker-test -D default -c 8 > > speaker-test 1.2.4 > > > > Playback device is default > > Stream parameters are 48000Hz, S16_LE, 8 channels > > Using 16 octaves of pink noise > > Rate set to 48000Hz (requested 48000Hz) > > Buffer size range from 96 to 204768 > > Period size range from 48 to 102384 > > Using max buffer size 204768 > > Periods = 4 > > Unable to set hw params for playback: Argumento inválido > > Setting of hwparams failed: Argumento inválido > > (...) > > Dale un vistado a la página de MythTV donde explican bastante bien cómo > probar con esa utilidad y cómo pasarle los parámetros adecuados, aunque > me temo que el éxito de tu misión va a ser una cuestión de prueba-error > :-): > > Using ALSA's speaker-test utility > https://www.mythtv.org/wiki/Using_ALSA%27s_speaker-test_utility > > Saludos, > > -- > Camaleón > > Gracias Camaleón, No doy con la tecla. He probado con mi PC de escritorio y funciona perfecto, suena un ruido por los alatavoces: -- Josu Lazkano
osinfo-query os missing debian Bullseye
Debians, As far as I can tell, the command 'osinfo-query os' does not support/list 'debian11'. I need to fire up a Bullseye VM what is the best way forward? P.S. Host and guest are Bullseye. -- John Doe
Re: pulseaudio ne démarre plus: segfault in libasound.so.2.0.0
Le 19/07/21 à 09:46, Fab a écrit : hello la liste, aujourd'hui, pulseaudio ne démarre plus: $ pulseaudio --start E: [pulseaudio] main.c: Échec lors du démarrage du démon. # tail -f /var/log/syslog Jul 19 09:43:23 FR-PORT kernel: [ 1235.497202] pulseaudio[5969]: segfault at 21d ip 7fd30fc9bcba sp 7fff0c48a870 error 4 in libasound.so.2.0.0[7fd30fc76000+8d000] J'ai essayé en démarrant sur 2 noyaux différents: 4.19.37-6 et 5.10.40-1 Je suis sur bullseye mis à jour avec xfce4 comme bureau. Avant de rechercher plus loin, rencontrez-vous le même soucis ? merki ;) f. prière de le désabonner à la liste, svp, je l'ai déjà demandé à plusieurs endroits visiblement sans succès.
Re: GRUB really slow to boot
On Sun, 19 Dec 2021, Greg Wooledge wrote: On Sun, Dec 19, 2021 at 07:19:40AM +, Tim Woodall wrote: Check if the kernel log jumps from 1/1/70 to today as it boots. That would point to the RTC being bad when the kernel first starts. Not sure which log I'd need to look at for this information. dmesg only reports time in relative seconds from the kernel's boot. This is the sort of thing I meant (this is a rpi which doesn't have an RTC at all so this is expected) - I've just rebooted to show this: This is from daemon.log but any log should do. Dec 19 14:52:42 rpi4-minimal haveged: haveged: Stopping due to signal 15 Jan 1 00:00:23 rpi4-minimal haveged: haveged starting up ... Jan 1 00:00:23 rpi4-minimal ntpd[1522]: Listening on routing socket on fd #24 for interface updates Jan 1 00:00:23 rpi4-minimal ntpd[1522]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jan 1 00:00:23 rpi4-minimal ntpd[1522]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jan 1 01:00:27 rpi4-minimal dbus-daemon[1664]: [session uid=103 pid=1659] Activating service name='org.xfce.Xfconf' requested by ':1.1' (uid=103 pid=1645 comm="x-window-manager ") Jan 1 01:00:27 rpi4-minimal dbus-daemon[1664]: [session uid=103 pid=1659] Successfully activated service 'org.xfce.Xfconf' Dec 19 14:53:40 rpi4-minimal dhclient[1176]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 The clock corrects itself when ntp starts. I'm not exactly clear why the clock jumps by an hour first but I don't really care... /var/log/kern.log.1 shows this: Dec 18 09:58:48 unicorn kernel: [6031224.812397] xor: automatically using best c hecksumming function avx Dec 18 09:58:48 unicorn kernel: [6031224.944868] Btrfs loaded, crc32c=crc32c-int el Dec 18 11:17:28 unicorn kernel: [0.00] microcode: microcode updated earl y to revision 0xea, date = 2021-01-05 Dec 18 11:17:28 unicorn kernel: [0.00] Linux version 5.10.0-10-amd64 (de bian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08) Of course, the human-readable timestamps on the left come from syslog, which is a userspace process that is launched after the clock is initialized from whatever sources (not sure exactly when NTP kicks in). Looks to me at first glance that the clock was right - so scratch my guess that it could be a dead battery on the motherboard. Tim.
Re: GRUB really slow to boot
On 18/12/2021 16:08, Greg Wooledge wrote:
Today I rebooted my machine for the first time in quite a while, after
the kernel update that was released along with Debian 11.2.
When it reached the GRUB screen, I pressed Enter, and nothing happened
as far as I could see. I was initially worried that it had stopped
seeing my USB keyboard (a thing that I've experienced with GRUB and
certain USB slots on certain machines in the past). This keyboard
plugged into this same USB slot had worked in previous versions of GRUB
on this machine, though.
The next thing I observed was that after 5 seconds, it still hadn't
booted, nor had the coundown ("will automatically boot in 5s" or whatever)
advanced. It appeared to be hung.
I waited a bit longer, and the 5s changed to 4s. It just took a really
long time (like 15+ seconds for each second on the timer).
Eventually, after a minute or two, the system booted. Everything is
working normally now, post-GRUB.
Has anyone experienced this, or does anyone have ideas about how to
prevent it happening again? I am not interested in trial and error
for this, because it's far too annoying and disruptive. But if there
are well-known ideas about things I could try (e.g. "grub 2.04 is known
to have bugs on Intel motherboards, revert to 2.03") then I'm game.
Not a definitive answer here, but to me, this sounds like the sort of
behaviour a program would have when having to process lots of
interrupts. You say that pressing Enter does nothing and that the
countdown happens really slowly. Imagine you had a stuck key - something
which was repeatedly sending keypresses to GRUB, but which weren't
triggering the "cancel timer" branch. Something like CTRL or Shift,
maybe. Or an ACPI key etc.
I see that you say you're not interested in trial-and-error and I can
understand that. If you can, try using a different keyboard. Or just
unplug the keyboard entirely (You may need to configure your BIOS to
allow booting without the keyboard or just allow the BIOS enough time to
see the keyboard and THEN unplug it before GRUB sees it).
https://sources.debian.org/src/grub2/2.04-20/grub-core/normal/menu.c/#L601
seems to be the loop of code that GRUB executes while waiting for a key.
I can see some functions there that, if not written carefully, COULD
take some time to return.
OpenPGP_signature
Description: OpenPGP digital signature
Re: GRUB really slow to boot
Looks like the fix is this: # If you need to disable # gfxpayload=keep on your system, just add this line (uncommented) to # /etc/default/grub: # # GRUB_GFXPAYLOAD_LINUX=text So, try just adding the above, then run "update-grub" to activate the change. The problem seems to be some GPU cards have faulty UEFI graphics, and switching grub to "text" mode works around the problem. There is even a set of already blacklisted GPUs in this file: /boot/grub/gfxblacklist.txt
Re: GRUB really slow to boot
On Sun, Dec 19, 2021 at 02:17:17PM -, Curt wrote: > Did we see /etc/default/grub? Could this resolution bug lead to a > resolution via a new resolution for the New Year? > > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/480159 > > 11 years old, but still extant. I've used GRUB interactively on this machine with this monitor before, without running into that issue. I mentioned that in my original post. This is the first time I've ever experienced this symptom on this machine, which is what really has me confused. Here's my /etc/default/grub: # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` #GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Uncomment to disable generation of recovery mode menu entries #GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1"
Re: GRUB really slow to boot
On Sun, Dec 19, 2021 at 07:19:40AM +, Tim Woodall wrote: > Check if the kernel log jumps from 1/1/70 to today as it boots. That > would point to the RTC being bad when the kernel first starts. Not sure which log I'd need to look at for this information. dmesg only reports time in relative seconds from the kernel's boot. /var/log/kern.log.1 shows this: Dec 18 09:58:48 unicorn kernel: [6031224.812397] xor: automatically using best c hecksumming function avx Dec 18 09:58:48 unicorn kernel: [6031224.944868] Btrfs loaded, crc32c=crc32c-int el Dec 18 11:17:28 unicorn kernel: [0.00] microcode: microcode updated earl y to revision 0xea, date = 2021-01-05 Dec 18 11:17:28 unicorn kernel: [0.00] Linux version 5.10.0-10-amd64 (de bian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08) Of course, the human-readable timestamps on the left come from syslog, which is a userspace process that is launched after the clock is initialized from whatever sources (not sure exactly when NTP kicks in). The one-hour jump is, I think, an artifact of daylight saving time ending between my last two boots. The 09:58 lines are from the syslog which was initialized while I was on daylight saving time (in October), and the 11:17 lines are from the syslog that was launched on standard time in December. I see similar time shenanigans in the output of last: greg pts/5:pts/0:S.1 Sat Dec 18 10:18 still logged in greg pts/4:pts/0:S.0 Sat Dec 18 10:18 still logged in greg tty1 Sat Dec 18 11:17 still logged in reboot system boot 5.10.0-10-amd64 Sat Dec 18 06:17 still running tester tty2 Mon Nov 22 11:18 - 11:18 (00:00) greg pts/12 :pts/2:S.8 Sat Oct 9 15:39 - 10:14 (69+19:35) The "reboot" line shows 6:17 which might be accurate UTC. The line immediately above that is 11:17 (5-hour offset for US/Eastern), and the line above that is 10:18 (a weird one-hour jump backward which I can only guess is somehow related to daylight saving time).
Konqueror geeft ongedocumenteerde fout bij starten
Hallo, Een klant wil graag KDE-plasma, maar ik heb daar wat minder verstand van. Wat me opvalt is dat Konqueror een storende fout geeft als je het start. Het zou een ongedocumenteerde fout zijn, het heeft wellicht te maken met de standaard pagina bij het opstarten (%u). Kent iemand hier dit probleem, of nog beter een oplossing? Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: GRUB really slow to boot
On 2021-12-18, Greg Wooledge wrote: > On Sat, Dec 18, 2021 at 11:42:23PM +, James Dutton wrote: >> Disk looks OK to me. >> Next, check no USB devices are connected while it boots. >> Disable "quiet" boot mode, so you can see all the boot up messages. >> This will give you an idea where it is going slow. > > "quiet" is a kernel parameter. It's passed to the kernel. It does > nothing until the kernel is executed, as far as I understand things. > > The symptoms I experienced were BEFORE the kernel was executed. During > GRUB itself. While sitting at the GRUB menu. > > Once the kernel started running, everything was within normal expectations. > > Did we see /etc/default/grub? Could this resolution bug lead to a resolution via a new resolution for the New Year? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/480159 11 years old, but still extant.
Re: GRUB really slow to boot
On Sun, Dec 19, 2021 at 12:54:04PM +, James Dutton wrote:
> One question, does it boot faster if you just press enter at the grub
> menu, and don't wait for the counter?
On Sat, Dec 18, 2021 at 11:08:37AM -0500, Greg Wooledge wrote:
[...]
> When it reached the GRUB screen, I pressed Enter, and nothing happened
> as far as I could see. I was initially worried that it had stopped
> seeing my USB keyboard (a thing that I've experienced with GRUB and
> certain USB slots on certain machines in the past). This keyboard
> plugged into this same USB slot had worked in previous versions of GRUB
> on this machine, though.
>
> The next thing I observed was that after 5 seconds, it still hadn't
> booted, nor had the coundown ("will automatically boot in 5s" or whatever)
> advanced. It appeared to be hung.
>
> I waited a bit longer, and the 5s changed to 4s. It just took a really
> long time (like 15+ seconds for each second on the timer).
>
> Eventually, after a minute or two, the system booted. Everything is
> working normally now, post-GRUB.
[...]
Re: GRUB really slow to boot
On Sat, 18 Dec 2021 at 23:54, Greg Wooledge wrote: > The symptoms I experienced were BEFORE the kernel was executed. During > GRUB itself. While sitting at the GRUB menu. > > Once the kernel started running, everything was within normal expectations. > Sounds like a race condition or infinite loop in grub somewhere. I have seen articles about it that describe it as a slow display in grub. No solutions though. I suggest you take this up with the grub developers. There might be a debug mode for grub, so that you can help track down the problem for them. One question, does it boot faster if you just press enter at the grub menu, and don't wait for the counter?
Re: SSH tunnel valt weg
Op 19-12-2021 om 11:07 schreef Geert Stappers: On Sun, Dec 19, 2021 at 12:26:29AM +0100, Paul van der Vlis wrote: Hallo, Ik gebruik vaak SSH tunnels en sinds een paar dagen (nog voor de point release) vallen die tunnels na enige tijd weg. De belangrijke foutmelding is volgens mij deze (aan de server kant): ssh_dispatch_run_fatal: Connection from 45.95.238.187 port 56446: message authentication code incorrect Onderaan heb ik nog wat meer log geplakt, maar volgens mij is dat niet zo interessant en is dit de belangrijke melding. De logs aan de client kant heb ik helemaal onderaan geplakt, maar ik kan er niet veel mee. Wat me opvalt is dat hij een pakket "type 1" stuurt, en daarna valt de verbinding weg (de sessie was al even open): debug3: send packet: type 1 Iemand een idee waarom die verbindingen wegvallen? Verbindingen kunnen wegvallen, herstel gewoon de verbinding. Doe je voordeel met `autossh`. |$ apt show autossh 2> /dev/null | sed --silent -e '/^Description/,$p' |Description: Automatically restart SSH sessions and tunnels | autossh is a program to start an instance of ssh and monitor it, restarting it | as necessary should it die or stop passing traffic. The idea is from rstunnel | (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done | using a loop of port forwardings. It backs off on the rate of connection | attempts when experiencing rapid failures such as connection refused. Een interessante applicatie! Toch denk ik dat er ook iets mis is wat gerepareerd kan worden. Eerder had ik dit probleem namelijk niet. Groet, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Re: Salida audio en mini PC
El 2021-12-19 a las 12:07 +0100, Josu Lazkano escribió: > Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para > reproducir música, lo tengo sin interfaz gráfico, en modo servidor. > > Pero no acierto a hacer un test: > > $ speaker-test -D default -c 8 > speaker-test 1.2.4 > > Playback device is default > Stream parameters are 48000Hz, S16_LE, 8 channels > Using 16 octaves of pink noise > Rate set to 48000Hz (requested 48000Hz) > Buffer size range from 96 to 204768 > Period size range from 48 to 102384 > Using max buffer size 204768 > Periods = 4 > Unable to set hw params for playback: Argumento inválido > Setting of hwparams failed: Argumento inválido (...) Dale un vistado a la página de MythTV donde explican bastante bien cómo probar con esa utilidad y cómo pasarle los parámetros adecuados, aunque me temo que el éxito de tu misión va a ser una cuestión de prueba-error :-): Using ALSA's speaker-test utility https://www.mythtv.org/wiki/Using_ALSA%27s_speaker-test_utility Saludos, -- Camaleón
Re: GRUB really slow to boot
On Sat 18 Dec 2021 at 11:08:37 -0500, Greg Wooledge wrote:
> Today I rebooted my machine for the first time in quite a while, after
> the kernel update that was released along with Debian 11.2.
>
> When it reached the GRUB screen, I pressed Enter, and nothing happened
> as far as I could see. I was initially worried that it had stopped
> seeing my USB keyboard (a thing that I've experienced with GRUB and
> certain USB slots on certain machines in the past). This keyboard
> plugged into this same USB slot had worked in previous versions of GRUB
> on this machine, though.
>
> The next thing I observed was that after 5 seconds, it still hadn't
> booted, nor had the coundown ("will automatically boot in 5s" or whatever)
> advanced. It appeared to be hung.
>
> I waited a bit longer, and the 5s changed to 4s. It just took a really
> long time (like 15+ seconds for each second on the timer).
>
> Eventually, after a minute or two, the system booted. Everything is
> working normally now, post-GRUB.
Some of my machines are booted with
set timeout=5
menuentry 'Debian bullseye on 5740' {
linux /vmlinuz root=LABEL=5740 ro quiet
initrd /initrd.img
}
Perhaps you could try with this; maybe "root=/dev/sdaX" is more
convenient. Also test with /vmlinuz.old and /initrd.img.old.
Remove the first line to simplify the file.
--
Brian.
Salida audio en mini PC
Hola a todos, Tengo un mini PC (Z83II) corriendo Debian Buster, quiero usarlo para reproducir música, lo tengo sin interfaz gráfico, en modo servidor. Pero no acierto a hacer un test: $ speaker-test -D default -c 8 speaker-test 1.2.4 Playback device is default Stream parameters are 48000Hz, S16_LE, 8 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 96 to 204768 Period size range from 48 to 102384 Using max buffer size 204768 Periods = 4 Unable to set hw params for playback: Argumento inválido Setting of hwparams failed: Argumento inválido Esta es la info de mi tarjeta: $ aplay -l List of PLAYBACK Hardware Devices card 0: bytcrrt5651 [bytcr-rt5651], device 0: Audio (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: bytcrrt5651 [bytcr-rt5651], device 1: Deep-Buffer Audio (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Audio [Intel HDMI/DP LPE Audio], device 0: HdmiLpeAudio [Intel HDMI/DP LPE Audi] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Audio [Intel HDMI/DP LPE Audio], device 1: HdmiLpeAudio [Intel HDMI/DP LPE Audi] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Audio [Intel HDMI/DP LPE Audio], device 2: HdmiLpeAudio [Intel HDMI/DP LPE Audi] Subdevices: 1/1 Subdevice #0: subdevice #0 $ aplay -L null Discard all samples (playback) or generate zero samples (capture) hw:CARD=bytcrrt5651,DEV=0 bytcr-rt5651, Direct hardware device without any conversions hw:CARD=bytcrrt5651,DEV=1 bytcr-rt5651, Direct hardware device without any conversions plughw:CARD=bytcrrt5651,DEV=0 bytcr-rt5651, Hardware device with all software conversions plughw:CARD=bytcrrt5651,DEV=1 bytcr-rt5651, Hardware device with all software conversions default:CARD=bytcrrt5651 bytcr-rt5651, Default Audio Device sysdefault:CARD=bytcrrt5651 bytcr-rt5651, Default Audio Device dmix:CARD=bytcrrt5651,DEV=0 bytcr-rt5651, Direct sample mixing device dmix:CARD=bytcrrt5651,DEV=1 bytcr-rt5651, Direct sample mixing device hw:CARD=Audio,DEV=0 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct hardware device without any conversions hw:CARD=Audio,DEV=1 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct hardware device without any conversions hw:CARD=Audio,DEV=2 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct hardware device without any conversions plughw:CARD=Audio,DEV=0 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Hardware device with all software conversions plughw:CARD=Audio,DEV=1 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Hardware device with all software conversions plughw:CARD=Audio,DEV=2 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Hardware device with all software conversions default:CARD=Audio Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Default Audio Device sysdefault:CARD=Audio Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Default Audio Device hdmi:CARD=Audio,DEV=0 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi HDMI Audio Output hdmi:CARD=Audio,DEV=1 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi HDMI Audio Output hdmi:CARD=Audio,DEV=2 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi HDMI Audio Output dmix:CARD=Audio,DEV=0 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct sample mixing device dmix:CARD=Audio,DEV=1 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct sample mixing device dmix:CARD=Audio,DEV=2 Intel HDMI/DP LPE Audio, Intel HDMI/DP LPE Audi Direct sample mixing device El sonido lo quiero sacar por el conector jack que dispone el mini PC. ¿Estoy haciendo algo mal? Sin interfaz gráfica no se como poder configurar el sonido. Un saludo y gracias por todo. -- Josu Lazkano
Re: SSH tunnel valt weg
On Sun, Dec 19, 2021 at 12:26:29AM +0100, Paul van der Vlis wrote: > Hallo, > > Ik gebruik vaak SSH tunnels en sinds een paar dagen (nog voor de point > release) vallen die tunnels na enige tijd weg. De belangrijke foutmelding is > volgens mij deze (aan de server kant): > > ssh_dispatch_run_fatal: Connection from 45.95.238.187 port 56446: message > authentication code incorrect > > Onderaan heb ik nog wat meer log geplakt, maar volgens mij is dat niet zo > interessant en is dit de belangrijke melding. > > De logs aan de client kant heb ik helemaal onderaan geplakt, maar ik kan er > niet veel mee. Wat me opvalt is dat hij een pakket "type 1" stuurt, en > daarna valt de verbinding weg (de sessie was al even open): > debug3: send packet: type 1 > > Iemand een idee waarom die verbindingen wegvallen? > Verbindingen kunnen wegvallen, herstel gewoon de verbinding. Doe je voordeel met `autossh`. |$ apt show autossh 2> /dev/null | sed --silent -e '/^Description/,$p' |Description: Automatically restart SSH sessions and tunnels | autossh is a program to start an instance of ssh and monitor it, restarting it | as necessary should it die or stop passing traffic. The idea is from rstunnel | (Reliable SSH Tunnel), but implemented in C. Connection monitoring is done | using a loop of port forwardings. It backs off on the rate of connection | attempts when experiencing rapid failures such as connection refused. Groeten Geert Stappers -- Silence is hard to parse
Re: le changement de stable a oldstable bloque les mises a jour automatiques
Le Wed, 1 Dec 2021 01:39:51 +0100, hamster a écrit : > Mais ca demande quand meme de taper la commande quand y'a un > "releaseinfo-change" et tant que cette commande n'est pas tapée, les > mises a jour de sécurité ne se font pas. La démarche su passage en old-stable est certainement trop "geek". Ceci dit ça a pour moi un sens de ne pas laisser, sans une démarche volontaire, les utilisateur continuer à utiliser une old-stable comme si c'était une stable. La maintenance n'est pas du tout la même ! Après ça reste une excellente idée d'améliorer le saut de version majeure, en fonction des différentes configurations rencontrées : Qui administre le système ? Le saut de version majeure n'est anodin sur aucun OS (les "rollings" diffusent les problèmes au long du temps). Typiquement mettre "stable" dans la sources.list fait la mise à jour majeure automatiquement, mais expose au risque que tout ne se passe pas bien. C'est une excellente idée donc d'améliorer le système, mais c'est quand même mieux quand le processus est supervisé par quelqu'un de compétent...
Re: Need Support on Debian10 Linux Kernel UpgradeA
On Fri, 17 Dec 2021, Balasubramanian Ravuthan wrote: Hi Dan, Thanks for your reply. We need few more information. 1. Debian 10 Buster is not released with Linux Kernel 5.10 ; That means We cant upgrade Kernel 5.10 with Debian 10? - Please confirm. As Dan says, it's in backports. I've been running a rpi buster with backports kernel for ages with no issues. 2. 3. In order to upgrade Linux Kernel to 5.10 means we have to install Debian 11 BullsEye. Please Confirm. Of course not. It's certainly one option but by no means the only one. The kernel is probably one of the easiest parts to replace with different versions as most of userspace doesn't much care. 4. 5. What will be the impact for upgrading Debian 10 with Kernel 4.19 to Debian 11 with Kernel 5.10. This is impossible to answer. I've had two headaches on the systems I've upgraded so far : bracketed paste in bash (how to revert to old behaviour posted to this very list) and amd64 xen hypervisor not powering off on shutdown (most recent version now has this fixed)
Re: IPv4 specific issue with USB tethering between my Debian laptop and my phone
On Sun, 19 Dec 2021, didier gaumet wrote: Le samedi 18 d?cembre 2021 ? 23:52 +0100, Vincent Lefevre a ?crit?: [...] I haven't tried wireshark on the other end. I wonder whether there is a replacement tool that doesn't need an X11 connection, to just do the capture of the packets. [...] Hello Vincent, perhaps tshark (tshark package) would do? https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html Missed this. tcpdump is my tool of choice for this. I don't even use wireshark for capture when I'll be capturing packets on the host I'll be viewing them on.
Re: Acquisition VHS to usb : august vgb350 : pas de peripherique video
On 18/12/2021 17:09, Greg wrote: kernel: em28xx 3-2:1.0: No AC97 audio processor kernel: usb 3-2: Decoder not found kernel: em28xx 3-2:1.0: failed to create media graph Tu peux activer les infos de debug (cf modinfo) pour avoir des infos supplémentaires. -- Fabien
Re: Broken libc6 running Sid (multiarch sytem)
On Du, 19 dec 21, 07:24:56, Tim Woodall wrote: > On Sat, 18 Dec 2021, Mark Allums wrote: > > > > Preparing to unpack .../libc6_2.33-1_amd64.deb ... > > Unpacking libc6:amd64 (2.33-1) over (2.34-0experimental1) ... > > dpkg: error processing archive > > /var/cache/apt/archives/libc6_2.33-1_amd64.deb (--unpack): > > trying to overwrite shared '/usr/share/doc/libc6/NEWS.gz', which is > > different from other instances of package libc6:amd64 > > I'd delete that file and try again. (move it to the side if it's > something you might want to consult) According to my understanding of the manpage it should work with an added '--force-overwrite'. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: 8 -> 9 update changing things
On Sb, 18 dec 21, 11:24:34, Roy J. Tellason, Sr. wrote: > > There remains the sound issue in the virtualbox. Could it be that > Debian isn't running PulseAudio but something else? That would > account for the guest OS not being able to talk to it... As far as I'm aware there is no default sound server in Debian, it's whatever the corresponding Desktop Environment depends on. Usually this is PulseAudio, but it seems PipeWire is becoming more popular. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Firefox ESR EOL
On Sb, 18 dec 21, 14:22:58, David Newman wrote: > On Dec 18, 2021, at 12:44, Nicholas Geovanis wrote: > > > > > >>> On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU > >>> wrote: > >>> On Jo, 09 dec 21, 23:24:11, Marco Möller wrote: > >>> > > >>> > It's a pity that Debian cannot be flexible to offer more secure and > >>> > already > >>> > available binary versions of software for the assumed many users only > >>> > caring > >>> > for installing a binary from the official Debian repository on some very > >>> > >> ARM64 is likely to see *more* (not less) use in desktops and laptops, > >> and RISC V might also be an option in the future. > > > > > > Maybe I missed something. Why RISC V? > > RISC V is open-source hardware, free of encumbrances from commercial licenses > and fees. As well as free from embargoes, so it might be very interesting for chip makers in countries affected by such. It's also quite promising in the performance per watt area and performance per square mm, even compared to ARM (which is already better than x86 chips). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: IPv4 specific issue with USB tethering between my Debian laptop and my phone
Le samedi 18 décembre 2021 à 23:52 +0100, Vincent Lefevre a écrit : [...] > I haven't tried wireshark on the other end. I wonder whether there > is a replacement tool that doesn't need an X11 connection, to just > do the capture of the packets. [...] Hello Vincent, perhaps tshark (tshark package) would do? https://www.wireshark.org/docs/wsug_html_chunked/AppToolstshark.html
