Re: Instalar Kodi Leia 18.6
El 2020-12-26 a las 19:22 -0300, Pablo Fernandez escribió: > Estimados, buenas tardes. > > Estoy usando Debian 10 y tengo problemas con la instalación de Kodi 18.9 > (5:18.9-dmo0+deb10u1). > > Me esta arrojando el siguiente error al iniciar. > > " gdb not installed, can't get stack trace" . > > Aclaro que para instalarlo tuve que agregar el source list "deb > http://www.deb-multimedia.org buster main non-free " , ya que si instalaba > por apt la ultima versión era Kodi 17.6 . ¿Y necesitas esa versión concreta por algún motivo? Quizá en la lista de debian multimedia te puedan echar una mano: http://www.deb-multimedia.org/lurker/list/dmo-discussion.en.html > Desde ya agradezco sus valiosos aportes. ¿Y cuál es el problema, exactamente? Si puedes enviar a la lista el error que te aparece, mejor, porque ese mensaje lo que me da entender es que la aplicación se ha cerrado o que tiene algún problema que ha generado una traza de depuración pero que no podrás analizar la depuración de errores si no instalas el paquete correspondiente (gdb), normalmente lo usan los desarrolladores. Saludos, -- Camaleón
Re: No GRUB with brand-new GPU
On 2020-12-26 18:44 -0500, The Wanderer wrote: > On 2020-12-26 at 18:28, Felix Miata wrote: > >> I suggest a good place to start would be to goto /etc/default/grub >> and switch from whichever mode is employed to the other, either plain >> text to graphical, or vice versa, then regenerate grub.cfg and try >> booting. > > That's a good suggestion, except I don't see any way to do that in the > /etc/default/grub I have. > > The closest thing I see is > > # Uncomment to disable graphical terminal (grub-pc only) > #GRUB_TERMINAL=console > > but that says it's for grub-pc only, i.e. the "legacy" version of grub, > whereas I'm running grub2. No, grub-pc is not the legacy version of grub, it is grub2 for legacy computers without EFI. The version of grub2 for modern UEFI systems is grub-efi-amd64 which uses the framebuffer set up by the system's firmware (hence, no traditional text mode). Cheers, Sven
Re: No GRUB with brand-new GPU
On Sb, 26 dec 20, 17:19:32, The Wanderer wrote: > > With the new GPU in place, I get video output during POST and in the > BIOS (yes, this machine is old enough that it doesn't have a UEFI) > without problems. That demonstrates that the GPU isn't dead on arrival, > and that signal is getting through to the monitor on a basic level. At this apoint you might want to query your monitor for the resolution used, might be helpful in case you want to configure grub with a known working resolution (as per other suggestions). > However, as soon as the machine tries to hand over control to the > bootloader, I get a hard freeze; the screen goes black (albeit I think > still with backlight), the keyboard light toggle keys stop responding, > and the GRUB menu never appears. Waiting a long time doesn't change > anything; even after roughly half an hour of waiting, pressing the Power > button once (no press-and-hold) shuts the system off immediately, which > indicates that the system hasn't progressed much (if at all) past early > boot. Maybe changing some BIOS setting could help. The suggestion to try a live image is also good. As far as I know the Debian Installer is using very basic VGA graphics, for maximum compatibility, so result might be different than a full live system. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: No GRUB with brand-new GPU
On Sat 26 Dec 2020 at 17:19:32 (-0500), The Wanderer wrote: > I have for some years been running Debian with an older model of AMD GPU > (Radeon HD 6870) for graphics. > > I recently purchased a relatively recent model of GPU (Radeon RX 5700 > XT), and today swapped it in and attempted to boot with it. > Any suggestions for what to try? Did you take the old card out and then reboot and save the CMOS settings? Then put the new card in and ditto? (I have in the long distant past had trouble swapping/moving cards around when making too many changes in one step.) OTOH this could be just a cargo-cult suggestion. Cheers, David.
Re: acpi bios error: could not resolve symbol in Tuxedo Aura 15
Hello Rainer! I assume bios just doesn't support some functions that kernel is trying to query. You could try to update bios, if possible. But as you say you don't see any real problems, maybe it's better not to fix something that is working already. I get similar messages on boot (Debian Buster), but in fact everything works perfectly. вс, 27 дек. 2020 г. в 04:48, Rainer Dorsch : > > Hi, > > I have a Tuxedo Aura 15 and after installing Debian bullseye, I see during > boot a few > > acpi bios error: could not resolve symbol > > messages. > > See https://nc.d5x.de/s/3BYL8Fg88Xb5GRJ for a "screenshot". > > Does anybody understand what these messages want to tell me (so far I did not > see anything not working). > > Any hint is welcome. > > Thanks > Rainer > > Full machine data: > > rd@aura:~$ inxi -F > System:Host: aura Kernel: 5.9.0-5-amd64 x86_64 bits: 64 Console: tty 3 > Distro: Debian GNU/Linux bullseye/sid > Machine: Type: Laptop System: TUXEDO product: TUXEDO Aura 15 Gen1 v: N/A > serial: > Mobo: TUXEDO s model: AURA1501 serial: UEFI: > INSYDE v: 1.07.03RTR2 date: 11/13/2020 > Battery: ID-1: BAT0 charge: 20.4 Wh condition: 50.3/48.3 Wh (104%) > CPU: Info: 8-Core model: AMD Ryzen 7 4700U with Radeon Graphics bits: 64 > type: MCP L2 cache: 4 MiB > Speed: 1398 MHz min/max: 1400/2000 MHz Core speeds (MHz): 1: 1398 2: > 1396 3: 1397 4: 1397 5: 1401 6: 1399 7: 1397 > 8: 1396 > Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: > kernel > Device-2: Acer BisonCam NB Pro type: USB driver: uvcvideo > Display: server: X.org 1.20.10 driver: amdgpu,ati unloaded: > fbdev,modesetting,vesa tty: 293x80 > Message: Advanced graphics data unavailable in console. Try -G -- > display > Audio: Device-1: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel > Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/ > Renoir Audio Processor driver: N/A > Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio driver: > snd_hda_intel > Sound Server: ALSA v: k5.9.0-5-amd64 > Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet > driver: r8169 > IF: enp2s0 state: down mac: 80:fa:5b:8a:20:da > Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi > IF: wlo1 state: up mac: 78:2b:46:2a:e2:48 > Drives:Local Storage: total: 465.76 GiB used: 6.07 GiB (1.3%) > ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 500GB > size: 465.76 GiB > Partition: ID-1: / size: 447.02 GiB used: 5.94 GiB (1.3%) fs: btrfs dev: /dev/ > dm-0 > ID-2: /boot size: 473.5 MiB used: 124.1 MiB (26.2%) fs: ext2 dev: / > dev/nvme0n1p2 > ID-3: /boot/efi size: 511 MiB used: 8.4 MiB (1.7%) fs: vfat dev: / > dev/nvme0n1p1 > Swap: ID-1: swap-1 type: partition size: 17.73 GiB used: 0 KiB (0.0%) > dev: /dev/dm-1 > Sensors: System Temperatures: cpu: 24.1 C mobo: N/A gpu: amdgpu temp: 23.0 C > Fan Speeds (RPM): N/A > Info: Processes: 283 Uptime: 8h 24m Memory: 30.81 GiB used: 1.35 GiB > (4.4%) Init: systemd runlevel: 5 Shell: Bash > inxi: 3.2.01 > rd@aura:~$ > > > > > -- > Rainer Dorsch > http://bokomoko.de/ > >
Re: No GRUB with brand-new GPU
On 2020-12-26 at 19:50, Tony Rowe wrote: > On Sat, Dec 26, 2020 at 05:19:32PM -0500, The Wanderer wrote: > >> With the new GPU in place, I get video output during POST and in >> the BIOS (yes, this machine is old enough that it doesn't have a >> UEFI) > > Since you did not mention it (or anyone else, I think), did you check > that your bios version is up to date? It's almost certainly as up-to-date as it gets. This is a Sabertooth X58 motherboard, and is no longer receiving BIOS updates; its most recent available BIOS update is dated 2012, and since I have a copy of the downloadable file for that update in one of my archive directories with a timestamp from 2014, if it's not long-since installed I'd be rather surprised. Honestly I'd like to run on a newer motherboard, but it hasn't been worth trying to dig up one that's newer enough and has as many ports (primarily SATA ports) as I need and still supports the CPU socket of the existing CPU. Eventually I'll build a new system, but that's been being postponed for some years now. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
On Sat, Dec 26, 2020 at 05:19:32PM -0500, The Wanderer wrote: > With the new GPU in place, I get video output during POST and in the > BIOS (yes, this machine is old enough that it doesn't have a UEFI) Since you did not mention it (or anyone else, I think), did you check that your bios version is up to date? Tony > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw >
Re: No GRUB with brand-new GPU
On 2020-12-26 at 19:49, Linux-Fan wrote: > The Wanderer writes: > >> On 2020-12-26 at 18:50, Linux-Fan wrote: >>> Curious, what machine does not do UEFI yet but still benefits >>> from large GPUs such as the RX 5700? >> >> One I built from parts back when the 6870 was still in the sweet >> spot of price vs. performance, with then-outsize specs in other >> regards, including what was at the time the top-end non-server CPU >> in the world. It's fallen well behind that standard, but is still >> far from the bottleneck in my system. >> >> The motivation for the GPU upgrade is that the card I have seems to >> be literally the last model made that doesn't support the required >> baseline for a game I've seen recommended. Based on the most >> recent Linux-including reviews as of the time I made the choice, >> the 5700 seems to be the current best option in terms of price vs. >> (performance / future-proofing). > > OK, that makes sense. I just wanted to ask because I was once in a > similar situation. I had upgraded my venerable HP Z400 (Xeon W3550 -- > not the fastet at the time) by adding a Radeon RX 570 to replace the > previous Nvidia GTX 570 card and had... zero performance improvement > in gaming because without me noticing this in other application > contexts/earlier, the CPU had become the bottleneck :( Reasonable. In my case, I have a Core i7 990x Extreme, which cost me $1050 brand-new; it may turn out to be the bottleneck with the new GPU, but the resulting performance should still be better than what I've got, and at least the game should actually be willing to *launch*. Thanks for the input, regardless of whether it winds up helping. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
The Wanderer writes: On 2020-12-26 at 18:50, Linux-Fan wrote: > Georgi Naplatanov writes: > >> On 12/27/20 12:19 AM, The Wanderer wrote: >> > I have for some years been running Debian with an older model of AMD GPU >> > (Radeon HD 6870) for graphics. >> > >> > I recently purchased a relatively recent model of GPU (Radeon RX 5700 >> > XT), and today swapped it in and attempted to boot with it. >> > With the new GPU in place, I get video output during POST and in the >> > BIOS (yes, this machine is old enough that it doesn't have a UEFI) >> > without problems. That demonstrates that the GPU isn't dead on arrival, >> > and that signal is getting through to the monitor on a basic level. > > Curious, what machine does not do UEFI yet but still benefits from large > GPUs such as the RX 5700? One I built from parts back when the 6870 was still in the sweet spot of price vs. performance, with then-outsize specs in other regards, including what was at the time the top-end non-server CPU in the world. It's fallen well behind that standard, but is still far from the bottleneck in my system. The motivation for the GPU upgrade is that the card I have seems to be literally the last model made that doesn't support the required baseline for a game I've seen recommended. Based on the most recent Linux-including reviews as of the time I made the choice, the 5700 seems to be the current best option in terms of price vs. (performance / future-proofing). OK, that makes sense. I just wanted to ask because I was once in a similar situation. I had upgraded my venerable HP Z400 (Xeon W3550 -- not the fastet at the time) by adding a Radeon RX 570 to replace the previous Nvidia GTX 570 card and had... zero performance improvement in gaming because without me noticing this in other application contexts/earlier, the CPU had become the bottleneck :( >> > Any suggestions for what to try? [...] All of those are part of what I expected to have to wrangle post-boot in order to get things working. (I'm running Debian testing, for what that's worth, so the kernel and so forth should already be new enough.) [...] I am out of ideas on this... By my terminology, a Debian installer *is* a (special case of a) live-boot environment. Which is not to say it would necessarily have been my choice to test this, but it might. [...] I just wanted to point the installer out, because it might be more easily available (already existent on a medium?) and hence the easier test to do. Unlike many other live systems, its terminal-based UI may help rule out X11 problems (although as noted, they are obviously not the issue at hand...) HTH Linux-Fan öö pgpm_ct7zMEtr.pgp Description: PGP signature
acpi bios error: could not resolve symbol in Tuxedo Aura 15
Hi, I have a Tuxedo Aura 15 and after installing Debian bullseye, I see during boot a few acpi bios error: could not resolve symbol messages. See https://nc.d5x.de/s/3BYL8Fg88Xb5GRJ for a "screenshot". Does anybody understand what these messages want to tell me (so far I did not see anything not working). Any hint is welcome. Thanks Rainer Full machine data: rd@aura:~$ inxi -F System:Host: aura Kernel: 5.9.0-5-amd64 x86_64 bits: 64 Console: tty 3 Distro: Debian GNU/Linux bullseye/sid Machine: Type: Laptop System: TUXEDO product: TUXEDO Aura 15 Gen1 v: N/A serial: Mobo: TUXEDO s model: AURA1501 serial: UEFI: INSYDE v: 1.07.03RTR2 date: 11/13/2020 Battery: ID-1: BAT0 charge: 20.4 Wh condition: 50.3/48.3 Wh (104%) CPU: Info: 8-Core model: AMD Ryzen 7 4700U with Radeon Graphics bits: 64 type: MCP L2 cache: 4 MiB Speed: 1398 MHz min/max: 1400/2000 MHz Core speeds (MHz): 1: 1398 2: 1396 3: 1397 4: 1397 5: 1401 6: 1399 7: 1397 8: 1396 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Device-2: Acer BisonCam NB Pro type: USB driver: uvcvideo Display: server: X.org 1.20.10 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa tty: 293x80 Message: Advanced graphics data unavailable in console. Try -G -- display Audio: Device-1: Advanced Micro Devices [AMD/ATI] driver: snd_hda_intel Device-2: Advanced Micro Devices [AMD] Raven/Raven2/FireFlight/ Renoir Audio Processor driver: N/A Device-3: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel Sound Server: ALSA v: k5.9.0-5-amd64 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp2s0 state: down mac: 80:fa:5b:8a:20:da Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi IF: wlo1 state: up mac: 78:2b:46:2a:e2:48 Drives:Local Storage: total: 465.76 GiB used: 6.07 GiB (1.3%) ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 500GB size: 465.76 GiB Partition: ID-1: / size: 447.02 GiB used: 5.94 GiB (1.3%) fs: btrfs dev: /dev/ dm-0 ID-2: /boot size: 473.5 MiB used: 124.1 MiB (26.2%) fs: ext2 dev: / dev/nvme0n1p2 ID-3: /boot/efi size: 511 MiB used: 8.4 MiB (1.7%) fs: vfat dev: / dev/nvme0n1p1 Swap: ID-1: swap-1 type: partition size: 17.73 GiB used: 0 KiB (0.0%) dev: /dev/dm-1 Sensors: System Temperatures: cpu: 24.1 C mobo: N/A gpu: amdgpu temp: 23.0 C Fan Speeds (RPM): N/A Info: Processes: 283 Uptime: 8h 24m Memory: 30.81 GiB used: 1.35 GiB (4.4%) Init: systemd runlevel: 5 Shell: Bash inxi: 3.2.01 rd@aura:~$ -- Rainer Dorsch http://bokomoko.de/
Re: No GRUB with brand-new GPU
The Wanderer composed on 2020-12-26 18:44 (UTC-0500): > Felix Miata wrote: >> I suggest a good place to start would be to goto /etc/default/grub >> and switch from whichever mode is employed to the other, either plain >> text to graphical, or vice versa, then regenerate grub.cfg and try >> booting. > That's a good suggestion, except I don't see any way to do that in the > /etc/default/grub I have. > The closest thing I see is > # Uncomment to disable graphical terminal (grub-pc only) > #GRUB_TERMINAL=console > but that says it's for grub-pc only, i.e. the "legacy" version of grub, > whereas I'm running grub2. I know it says grub-pc only, but all mine are uncommented. And, all mine are on UEFI installations. All my legacy BIOS installations boot from a custom partition with Grub Legacy, which is used to boot every installation on the disk. It may be that what it really means is: not arm*, not sparc, not mips, not ppc > A bit of Googling suggests that > # 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 Mine all are GRUB_GFXMODE="auto", but I have no AMD anything newer than about 6 years old. > also supports a value of 'text' rather than a FOOxBAR resolution, but I > don't see that documented anywhere yet. I think what you can do is create /etc/grub.d/05_do-text containing: cat
Re: No GRUB with brand-new GPU
On 2020-12-26 at 18:50, Linux-Fan wrote: > Georgi Naplatanov writes: > >> On 12/27/20 12:19 AM, The Wanderer wrote: >> > I have for some years been running Debian with an older model of AMD GPU >> > (Radeon HD 6870) for graphics. >> > >> > I recently purchased a relatively recent model of GPU (Radeon RX 5700 >> > XT), and today swapped it in and attempted to boot with it. >> > With the new GPU in place, I get video output during POST and in the >> > BIOS (yes, this machine is old enough that it doesn't have a UEFI) >> > without problems. That demonstrates that the GPU isn't dead on arrival, >> > and that signal is getting through to the monitor on a basic level. > > Curious, what machine does not do UEFI yet but still benefits from large > GPUs such as the RX 5700? One I built from parts back when the 6870 was still in the sweet spot of price vs. performance, with then-outsize specs in other regards, including what was at the time the top-end non-server CPU in the world. It's fallen well behind that standard, but is still far from the bottleneck in my system. The motivation for the GPU upgrade is that the card I have seems to be literally the last model made that doesn't support the required baseline for a game I've seen recommended. Based on the most recent Linux-including reviews as of the time I made the choice, the 5700 seems to be the current best option in terms of price vs. (performance / future-proofing). >> > Any suggestions for what to try? > I have a RadeonPro W5500 which is also too new, to be supported on Debian > stable out of the box. What I did to get it running for basic 2D > graphics (enough for me most of the time) was to install the following > packages from debian-backports: > > * linux-image-5.8.0-0.bpo.2-amd64 > * firmware-amd-graphics > > Additionally, I tried to enable amdgpu in xorg.conf, although I am not sure > whether that is actually needed: > > $ cat /etc/X11/xorg.conf > Section "Device" > Identifier "AMD" > Driver "amdgpu" > EndSection > > This system is using UEFI to boot and I do not recall having the same issue > (black screen) even before, though. All of those are part of what I expected to have to wrangle post-boot in order to get things working. (I'm running Debian testing, for what that's worth, so the kernel and so forth should already be new enough.) > Here are some other suggestions: > > As you mentioned GRUB not loading correctly, could there perhaps be an > explicit graphics resolution configuration entry? I do not have any special > configuration enabled there: > > $ grep -E '(GFXMODE|TERMINAL)' /etc/default/grub > #GRUB_TERMINAL=console > #GRUB_GFXMODE=640x480 Doesn't seem so; the output I get from that command is identical. > Apart from a live system, it could already be helpful to boot a Debian > installer to see if it can load a Linux if GRUB is not invovled. If that > works (i.e. presents language selection screen), checking with a live system > seems to be a reasonable next step. By my terminology, a Debian installer *is* a (special case of a) live-boot environment. Which is not to say it would necessarily have been my choice to test this, but it might. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
Georgi Naplatanov writes: On 12/27/20 12:19 AM, The Wanderer wrote: > I have for some years been running Debian with an older model of AMD GPU > (Radeon HD 6870) for graphics. > > I recently purchased a relatively recent model of GPU (Radeon RX 5700 > XT), and today swapped it in and attempted to boot with it. [...] > With the new GPU in place, I get video output during POST and in the > BIOS (yes, this machine is old enough that it doesn't have a UEFI) > without problems. That demonstrates that the GPU isn't dead on arrival, > and that signal is getting through to the monitor on a basic level. Curious, what machine does not do UEFI yet but still benefits from large GPUs such as the RX 5700? [...] > Any suggestions for what to try? [...] I'm not a hardware expert but I found the following on Internet: - the interface for this card is PCI-Express 4.0 and I guess that your old computer doesn't support that PCIe 4.0 is backwards-compatible (down to at least PCIe 3.0, possibly further). - BIOS Support - Dual UEFI - I'm not sure what this means but is it possible this card not to be supported by non-UEFI systems ? (Unsure on this) [...] I have a RadeonPro W5500 which is also too new, to be supported on Debian stable out of the box. What I did to get it running for basic 2D graphics (enough for me most of the time) was to install the following packages from debian-backports: * linux-image-5.8.0-0.bpo.2-amd64 * firmware-amd-graphics Additionally, I tried to enable amdgpu in xorg.conf, although I am not sure whether that is actually needed: $ cat /etc/X11/xorg.conf Section "Device" Identifier "AMD" Driver "amdgpu" EndSection This system is using UEFI to boot and I do not recall having the same issue (black screen) even before, though. Here are some other suggestions: As you mentioned GRUB not loading correctly, could there perhaps be an explicit graphics resolution configuration entry? I do not have any special configuration enabled there: $ grep -E '(GFXMODE|TERMINAL)' /etc/default/grub #GRUB_TERMINAL=console #GRUB_GFXMODE=640x480 Apart from a live system, it could already be helpful to boot a Debian installer to see if it can load a Linux if GRUB is not invovled. If that works (i.e. presents language selection screen), checking with a live system seems to be a reasonable next step. If you need the 3D accelleration performance (why buy an RX 5700 if not?), I'd suggest to setup a Debian testing environment for that. I managed to get some (fast enough for me) 3D accelleration working by creating a Debian sid chroot (testing did not have some dependencies I needed) and I can use it by logging in through TTY2 -> chroot -> startx. BUT: Please note that this setup is brittle -- dual-boot or testing-only configurations can be expected to run _more stable_ in this scenario :) HTH Linux-Fan öö pgpUgcLw5pUVE.pgp Description: PGP signature
Re: No GRUB with brand-new GPU
On 2020-12-26 at 18:28, Felix Miata wrote: > I suggest a good place to start would be to goto /etc/default/grub > and switch from whichever mode is employed to the other, either plain > text to graphical, or vice versa, then regenerate grub.cfg and try > booting. That's a good suggestion, except I don't see any way to do that in the /etc/default/grub I have. The closest thing I see is # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console but that says it's for grub-pc only, i.e. the "legacy" version of grub, whereas I'm running grub2. A bit of Googling suggests that # 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 also supports a value of 'text' rather than a FOOxBAR resolution, but I don't see that documented anywhere yet. I don't expect such a change to be particularly risky, but I imagine if I do somehow fail to boot after making it (e.g. if I specify a setting that isn't actually supported), the solution would involve a live-boot environment and possibly chrooting into the installed system. > While in /etc/default/grub, if splash=silent is included, either > remove it, or switch to splash=verbose. It isn't. From the little I've read up on regarding this in the meantime, I'd expect this splash setting to be only regarding the post-GRUB-menu boot process, which is beyond the point I've reached. For what it's worth, I've long since intentionally disabled all "quiet" boot settings I'm aware of. > If the switch itself doesn't help, then try graphical after selecting > some specific mode you know your display supports. I use > video=1440x900 on cmdline most of the time for the vttys even when > the display's native is 1920x1080, 1920x1200 or 2560x1440. I'm not even getting to the GRUB command line; the hang is happening before GRUB displays anything at all. I may try specifying a resolution such as this to GRUB_GFXMODE, but I'm not entirely certain that's relevant to the behavior I'm seeing, although it would be plausible for it to be so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: No GRUB with brand-new GPU
The Wanderer composed on 2020-12-26 17:19 (UTC-0500): ... I suggest a good place to start would be to goto /etc/default/grub and switch from whichever mode is employed to the other, either plain text to graphical, or vice versa, then regenerate grub.cfg and try booting. While in /etc/default/grub, if splash=silent is included, either remove it, or switch to splash=verbose. If the switch itself doesn't help, then try graphical after selecting some specific mode you know your display supports. I use video=1440x900 on cmdline most of the time for the vttys even when the display's native is 1920x1080, 1920x1200 or 2560x1440. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: No GRUB with brand-new GPU
On 2020-12-26 at 17:33, Georgi Naplatanov wrote: > On 12/27/20 12:19 AM, The Wanderer wrote: > >> I have for some years been running Debian with an older model of AMD GPU >> (Radeon HD 6870) for graphics. >> >> I recently purchased a relatively recent model of GPU (Radeon RX 5700 >> XT), and today swapped it in and attempted to boot with it. >> With the new GPU in place, I get video output during POST and in the >> BIOS (yes, this machine is old enough that it doesn't have a UEFI) >> without problems. That demonstrates that the GPU isn't dead on arrival, >> and that signal is getting through to the monitor on a basic level. >> >> However, as soon as the machine tries to hand over control to the >> bootloader, I get a hard freeze; the screen goes black (albeit I think >> still with backlight), the keyboard light toggle keys stop responding, >> and the GRUB menu never appears. Waiting a long time doesn't change >> anything; even after roughly half an hour of waiting, pressing the Power >> button once (no press-and-hold) shuts the system off immediately, which >> indicates that the system hasn't progressed much (if at all) past early >> boot. > Hi, > > I'm not a hardware expert but I found the following on Internet: > > - the interface for this card is PCI-Express 4.0 and I guess that your > old computer doesn't support that > > - BIOS Support - Dual UEFI - I'm not sure what this means but is it > possible this card not to be supported by non-UEFI systems ? I'd consider these plausible enough to pursue, except for the fact that (as noted above) I do get display output just fine during POST and in the BIOS. If the slot interface weren't compatible, I'd expect to not get any video output from the system at all. "Dual UEFI" I don't remember seeing in regard to this device; I'm not sure what it'd mean for a GPU. It's normally something I expect to see for a motherboard, where it would mean that the device supports having two different UEFIs in place at once, so you can flash a new one and still have the old one to fall back to if the new one fails. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Mon, 21 Dec 2020 15:45:37 + "Andrew M.A. Cater" wrote: > > > Well, that's a good start :) The test suite we used to test for > stable release CDs is here: > https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Buster_r7?highlight=%28testing%29%7C%28cd%29%7C%2810.7%29 First test subject. IBM ThinkPad R51, product name 1836Q4U. Installed via debian-bullseye-DI-alpha3-i386-netinst.iso. Expert install via text using a RW-CD. Language and keyboard are US English. File systems are all ext4, on top of LVM. Desktop: XFCE Running expert install. Usability note: It would be nice if the option to show a password in clear was above the widget for entering the password. That way one could select it or not with less tabbing. Bug??: DI incorrectly detected this machine as having EFI. Bug!!: I tried loading the firmware for the wifi if. DI asked all the right questions, and I gave it all the right answers. But it never connected. The dhcp server never got a request, and on the target hardware, ethtool-lite reported "carrier down". Graphics are slow but serviceable. Mozilla and LibreOffice are pathetically slow but usable in a pinch. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: No GRUB with brand-new GPU
On 12/27/20 12:19 AM, The Wanderer wrote: > I have for some years been running Debian with an older model of AMD GPU > (Radeon HD 6870) for graphics. > > I recently purchased a relatively recent model of GPU (Radeon RX 5700 > XT), and today swapped it in and attempted to boot with it. > > I was expecting to get no graphics support (e.g., X, et cetera) until > after adjusting some combination of installed driver- and > firmware-related packages, module-blacklist settings, boot-time options, > initrd state, GRUB configuration, and possibly other (again, e.g., X) > config files. I'm generally fine with wrangling that, and based on my > pre-swap research, was expecting to be able to get up and running with > the new GPU today. > > What I got, instead, was not even that far. > > With the new GPU in place, I get video output during POST and in the > BIOS (yes, this machine is old enough that it doesn't have a UEFI) > without problems. That demonstrates that the GPU isn't dead on arrival, > and that signal is getting through to the monitor on a basic level. > > However, as soon as the machine tries to hand over control to the > bootloader, I get a hard freeze; the screen goes black (albeit I think > still with backlight), the keyboard light toggle keys stop responding, > and the GRUB menu never appears. Waiting a long time doesn't change > anything; even after roughly half an hour of waiting, pressing the Power > button once (no press-and-hold) shuts the system off immediately, which > indicates that the system hasn't progressed much (if at all) past early > boot. > > Thus far, Google has not been helpful. I find plenty about black screens > after GRUB, but very little about before GRUB and after POST, and what > little I find is from other distros - some Ubuntu (earlier versions, > mostly 2010-era), some Arch, some RHEL - which don't necessarily handle > either graphics drivers or GRUB in a way that will let their directions > reliably translate to Debian. > > > Any suggestions for what to try? > > I'm back up now with the old GPU, since researching this on my > smartphone was going nowhere. I've dug into /etc/grub* and /boot/ > looking for anything which seemed related, with no promising hits yet. > > Barring other discoveries, my current next step is to dig up a suitably > recent Debian-based live-boot environment, boot to that, and see what it > does. If it gives me usable graphics, I want to see what it's doing at > bootloader time, and what parts I might be able to transpose into my > primary install. > > However, given that live-boot setups don't always handle the early parts > of boot the same way as hard-drive installs do, I'm not positive this > will be fruitful. Also, given how relatively new this card is, I'm not > sure I'll be able to find a suitable environment which does work with it > to the level I need. > Hi, I'm not a hardware expert but I found the following on Internet: - the interface for this card is PCI-Express 4.0 and I guess that your old computer doesn't support that - BIOS Support - Dual UEFI - I'm not sure what this means but is it possible this card not to be supported by non-UEFI systems ? Kind regards Georgi
Re: AMD GPU Sea Islands Problem
[ Beware: User of Core 2 Duo machines talking here. ] > It might turn out to be pointless. I strongly disagree here: it's by reporting such bugs that you can show there is still interest in supporting such hardware. > Users of older hardware, particularly Southern Islands and Sea Islands > users, seem to get short shrifted with disappointing frequency > by developers. I'd find it very disappointing if hardware as recent as that would be already considered too old to support satisfactorily. I can understand that the developers may not want to spend much time improving support for that hardware, but it should at least stay about as good as it was in the past. > I'm not sure what you encountered could be termed a bug. Of course if > you don't, there's a good chance it would never be noticed by > any developer. That's why it's important to report it. Since it used to work, it's probably just an oversight. Stefan
Instalar Kodi Leia 18.6
Estimados, buenas tardes. Estoy usando Debian 10 y tengo problemas con la instalación de Kodi 18.9 (5:18.9-dmo0+deb10u1). Me esta arrojando el siguiente error al iniciar. " gdb not installed, can't get stack trace" . Aclaro que para instalarlo tuve que agregar el source list "deb http://www.deb-multimedia.org buster main non-free " , ya que si instalaba por apt la ultima versión era Kodi 17.6 . Desde ya agradezco sus valiosos aportes. Gracias. Slds.
No GRUB with brand-new GPU
I have for some years been running Debian with an older model of AMD GPU (Radeon HD 6870) for graphics. I recently purchased a relatively recent model of GPU (Radeon RX 5700 XT), and today swapped it in and attempted to boot with it. I was expecting to get no graphics support (e.g., X, et cetera) until after adjusting some combination of installed driver- and firmware-related packages, module-blacklist settings, boot-time options, initrd state, GRUB configuration, and possibly other (again, e.g., X) config files. I'm generally fine with wrangling that, and based on my pre-swap research, was expecting to be able to get up and running with the new GPU today. What I got, instead, was not even that far. With the new GPU in place, I get video output during POST and in the BIOS (yes, this machine is old enough that it doesn't have a UEFI) without problems. That demonstrates that the GPU isn't dead on arrival, and that signal is getting through to the monitor on a basic level. However, as soon as the machine tries to hand over control to the bootloader, I get a hard freeze; the screen goes black (albeit I think still with backlight), the keyboard light toggle keys stop responding, and the GRUB menu never appears. Waiting a long time doesn't change anything; even after roughly half an hour of waiting, pressing the Power button once (no press-and-hold) shuts the system off immediately, which indicates that the system hasn't progressed much (if at all) past early boot. Thus far, Google has not been helpful. I find plenty about black screens after GRUB, but very little about before GRUB and after POST, and what little I find is from other distros - some Ubuntu (earlier versions, mostly 2010-era), some Arch, some RHEL - which don't necessarily handle either graphics drivers or GRUB in a way that will let their directions reliably translate to Debian. Any suggestions for what to try? I'm back up now with the old GPU, since researching this on my smartphone was going nowhere. I've dug into /etc/grub* and /boot/ looking for anything which seemed related, with no promising hits yet. Barring other discoveries, my current next step is to dig up a suitably recent Debian-based live-boot environment, boot to that, and see what it does. If it gives me usable graphics, I want to see what it's doing at bootloader time, and what parts I might be able to transpose into my primary install. However, given that live-boot setups don't always handle the early parts of boot the same way as hard-drive installs do, I'm not positive this will be fruitful. Also, given how relatively new this card is, I'm not sure I'll be able to find a suitable environment which does work with it to the level I need. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: AMD GPU Sea Islands Problem
Guyenne Tsui composed on 2020-12-26 21:37 (UTC): > Felix Miata wrote: >> I don't remember seeing that one before. Radeon Dynamic Power Management. >> Nice you found it! > Should I file a bug? I mean it may be a problem with dpm or a > compatibility issue that users have to figure it out themselves? It might turn out to be pointless. Users of older hardware, particularly Southern Islands and Sea Islands users, seem to get short shrifted with disappointing frequency by developers. I saw some talk a while back about removing GCN1 (Southern Islands) and GCN2 (Sea Islands) support from the AMDGPU DDX. I'm not sure what you encountered could be termed a bug. Of course if you don't, there's a good chance it would never be noticed by any developer. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: AMD GPU Sea Islands Problem
On 12/26/20 8:51 PM, Felix Miata wrote: I don't remember seeing that one before. Radeon Dynamic Power Management. Nice you found it! Should I file a bug? I mean it may be a problem with dpm or a compatibility issue that users have to figure it out themselves?
Re: AMD GPU Sea Islands Problem
Guyenne Tsui composed on 2020-12-26 20:35 (UTC): > #apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati: ... > The following packages will be REMOVED: >task-desktop* task-kde-desktop* xserver-xorg-video-all* Those three are meta-packages, so nothing important would be lost. > xserver-xorg-video-amdgpu* xserver-xorg-video-ati* > 0 upgraded, 0 newly installed, 5 to remove and 1 not upgraded. ... > Anyway I solved the initial issue. Apparently, the boot parameter > `radeon.dpm=0` solved the initial issue. Apparently, on newer kernels > (testing) the boot parameter is automatically set 1 and caused issues. > However I checked xorg website and they stated dpm is compatible with > Southern Islands, but I am not sure. I don't remember seeing that one before. Radeon Dynamic Power Management. Nice you found it! -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: AMD GPU Sea Islands Problem
The issue only occurs with ditros based on Debian Testing, such as Pop!_OS. This does not occur with my Debian Stable. Anyway I solved the initial issue. Apparently, the boot parameter `radeon.dpm=0` solved the initial issue. Apparently, on newer kernels (testing) the boot parameter is automatically set 1 and caused issues. However I checked xorg website and they stated dpm is compatible with Southern Islands, but I am not sure. Should I file a bug? If so where?
Re: AMD GPU Sea Islands Problem
#apt purge xserver-xorg-video-amdgpu xserver-xorg-video-ati: Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: apper apper-data espeak-ng-data fonts-symbola gir1.2-atspi-2.0 gir1.2-wnck-3.0 hyphen-en-us kdeaccessibility kmag kmousetool kmouth libatk-adaptor libbrlapi0.8 libc-ares2 libdotconf0 libespeak-ng1 libjs-highlight.js libnode72 libpcaudio0 libqaccessibilityclient-qt5-0 libreoffice-help-common libreoffice-help-en-us libreoffice-kf5 libreoffice-plasma libreoffice-qt5 libsonic0 libstartup-notification0 libu2f-udev libwnck-3-0 libwnck-3-common mythes-en-us node-normalize.css nodejs nodejs-doc orca perl-tk policykit-1-gnome print-manager python3-brlapi python3-louis python3-pyatspi python3-speechd python3-xdg qtgstreamer-plugins-qt5 sound-icons speech-dispatcher speech-dispatcher-audio-plugins speech-dispatcher-espeak-ng x11-apps x11-session-utils xbrlapi xinit xkbset xorg Use 'sudo apt autoremove' to remove them. The following packages will be REMOVED: task-desktop* task-kde-desktop* xserver-xorg-video-all* xserver-xorg-video-amdgpu* xserver-xorg-video-ati* 0 upgraded, 0 newly installed, 5 to remove and 1 not upgraded. After this operation, 712 kB disk space will be freed. Do you want to continue? [Y/n] Anyway I solved the initial issue. Apparently, the boot parameter `radeon.dpm=0` solved the initial issue. Apparently, on newer kernels (testing) the boot parameter is automatically set 1 and caused issues. However I checked xorg website and they stated dpm is compatible with Southern Islands, but I am not sure.
Re: Script ffmpeg ?
Slt,
On m'a dit vlc, ffmppeg c'est de la merde, pourquoi ?
Sinon j'essaye d'installer NVIDIA via Modprobe, le man et le help, disent a, la
commande dit not found, c'est toi qui t'ennuit ??
La prochaine fois enleve le de la doc !
Le mercredi 23 décembre 2020 à 09:40:03 UTC+1, Marc Chantreux a écrit :
> On Tue, Dec 22, 2020 at 08:44:48PM -0800, ptilou wrote:
> > Me semble une solution mieux fonctionner ? Bien que je ne comprend pas le
> > -IX , après -n1
> > Du coup je rame
> tu sais:
>
> * tu as droit de lire le man: c'est super instructif
> * tu peux jouer avec des petits exemples. en voilà
>
> seq 20 | xargs -n5
>
> 1 2 3 4 5
> 6 7 8 9 10
> 11 12 13 14 15
> 16 17 18 19 20
>
> seq 20 | xargs -n10
>
> 1 2 3 4 5 6 7 8 9 10
> 11 12 13 14 15 16 17 18 19 20
>
> seq 5 | xargs -IX echo cette fois ca faut X
>
> cette fois ca faut 1
> cette fois ca faut 2
> cette fois ca faut 3
> cette fois ca faut 4
> cette fois ca faut 5
>
> seq 5 | xargs -IY echo cette fois ca faut Y
>
> cette fois ca faut 1
> cette fois ca faut 2
> cette fois ca faut 3
> cette fois ca faut 4
> cette fois ca faut 5
>
> apres si tu tiens absolument a tapper sur de mauvaises pratiques:
> function f_image-fusion {
> convert "$1" -resize 40% -colorspace Gray "${1%}gray.jpg"
> }
> find ton truc | while read -r i; do
> f_image_fusion "$i"
> done;
>
> marc
--
ptilou
Re: /bin/sh naar bash i.p.v. dash linken
On Sat, Dec 19, 2020 at 06:01:31PM +0100, Cecil Westerhof wrote: > Ik had helemaal niet gereageerd. :'-( > > Richard Lucassen writes: > > > On Wed, 25 Nov 2020 10:52:57 +0100 > > Cecil Westerhof wrote: > > > >> Ik heb er zelf nooit last van gehad, maar door een vraag van iemand > >> anders kwam ik erachter dat sh een link is naar dash. Is er een > >> mogelijk heid om bij installatie sh naar bash te laten verwijzen? > > > > ln -sf /bin/bash /bin/sh > > Dat kan niet na een upgrade terug worden gezet door Debian? Nope. > > zou ik zeggen, Na installatie dan. Maar verwijs in je eigen scripts > > gewoon naar /bin/bash als je bash wilt, dan ben je niet meer > > afhankelijk van het feit van hoe de /bin/sh staat. > > Ik gebruik in mijn (bash) scripts altijd (dat is meer portable): > #!/usr/bin/env bash > > Zelf heb ik het probleem dus ook niet. Liep er tegenaan in een andere > groep waar iemand er over 'klaagde'. De reden dat /bin/sh naar dash verwijst, en niet naar bash, is omdat: - dash sneller opstart, - je als je /bin/sh zegt, je alleen commando's zou mogen gebruiken die effectief door POSIX als onderdeel van de sh interface gedefinieerd is en er dus geen verschil zou mogen zijn, Het gebruik van bash-specifieke functies in een /bin/sh script is niet portable. Op elk systeem dat een andere shell gebruikt dan bash als /bin/sh zal dat niet werken. FreeBSD heeft in de default configuratie bijvoorbeeld bash zelfs niet geïnstalleerd staan. Op macOS is de default shell lang bash geweest, maar dat is nooit geüpgradet geweest toen bash naar GPLv3 gegaan is (dus de default bash op macOS is nu wel *heel* erg oud), en ze zijn daar recent op zsh overgestapt. Het "probleem" dat /bin/sh niet bash is, is dus zeker niet Debian-specifiek. Bij Debian is op een bepaald moment de symlink van bash naar dash verplaatst geweest. Dat is expliciet gelimiteerd op de versie-overgang waarbij dat aangezet is. Het is dus maar één keer, en het terugzetten is ook een ondersteunde configuratie (i.e., als je dat nodig hebt mag je het gewoon doen). -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Problems with loadlin.exe
On Sat, Dec 26, 2020 at 04:05:50PM +, shadowma...@logorroici.org wrote: > Hello everybody: > I am new to this forum, but not to GNU/Linux. I am in a Windows 10 Machine > with an AMD x64 architecture. I am unable to install from a distro image > (firmware-10.7.0-amd64-netinst.iso) because loadlin.exe is not working > anymore in my OS. I want to dual boot the computer, but I am not sure of how > to do it. I tried installing the OS from the USB. Everything was OK, but the > system didn't boot... It was weird because I solved all the problems that it > gave to me: a problem loading "uefi:db x.509 certificate (-65)" that was > fixed by disabling Fast Boot and Secure Boot (it is impossible to use Legacy > mode in new computers). There was a problem with IOMMU that was fixed > disabling it too. Now I want to try to install it from the Windows system to > avoid the weird problems it gave because of GRUB (I had GRUB already > installed and it conflict somehow with the other installed by Debian). > Please, help me!!! > Thanks in advance ;) > Reenable Secure Boot - Debian 10 should be able to boot with Secure Boot now. How was Windows installed initially - if it was installed in UEFI mode and you are attempting to boot Debian in legacy mode, it will fail and vice versa. What had you installed previously using Grub? Are you booting from a USB stick? How did you write the Debian image to the USB stick? Do you know what firmware your system is likely to need? Getting a Windows system to dual boot Debian is (relatively) straightforward but knowing the answer to some of the above questions may help us narrow down useful suggestions as to what to try next. All the very best, as ever, Andy
Problems with loadlin.exe
Hello everybody: I am new to this forum, but not to GNU/Linux. I am in a Windows 10 Machine with an AMD x64 architecture. I am unable to install from a distro image (firmware-10.7.0-amd64-netinst.iso) because loadlin.exe is not working anymore in my OS. I want to dual boot the computer, but I am not sure of how to do it. I tried installing the OS from the USB. Everything was OK, but the system didn't boot... It was weird because I solved all the problems that it gave to me: a problem loading "uefi:db x.509 certificate (-65)" that was fixed by disabling Fast Boot and Secure Boot (it is impossible to use Legacy mode in new computers). There was a problem with IOMMU that was fixed disabling it too. Now I want to try to install it from the Windows system to avoid the weird problems it gave because of GRUB (I had GRUB already installed and it conflict somehow with the other installed by Debian). Please, help me!!! Thanks in advance ;)
Re: [Hors sujet et dérive sur les licenses] Re: Possible missing firmware
Le 2020-12-26 15:16, benoit a écrit : http://www.gnu.org/distros/free-distros.html Oups il n'y a pas debian dans la liste ! Je me demande bien pourquoi ? Pourtant nonfree est clairement séparé du reste... https://www.gnu.org/distros/common-distros.html#Debian
Re: [Hors sujet et dérive sur les licenses] Re: Possible missing firmware
Le vendredi 25 décembre 2020 13:02, Bernard Schoenacker a écrit : > - Mail original - > > > De: "benoit" benoit...@protonmail.ch > > À: "liste.debian" debian-user-french@lists.debian.org > > Envoyé: Vendredi 25 Décembre 2020 12:41:20 > > Objet: Re: Possible missing firmware > > Mais pourquoi dans nonfree ? > > Les pilotes graphiques d'Intel ne sont-ils pas open source ? > > https://01.org/linuxgraphics > > bonjour, > > ne pas confondre Open Sources et Free Software > > le pourquoi du logiciel libre : > https://www.fsf.org/about/what-is-free-software > > la définition de Open Sources : > > https://opensource.org/docs/osd > > la différence entre Open Sources et Free Software : > http://www.gnu.org/philosophy/free-software-for-freedom.html > > ensuite, la distribution Debian est restrictive sur certaines > partie des logiciels et voici la raison : > https://www.debian.org/social_contract > > une autre distribution dérivée de Debian a une politique et une > démarche plus "propriétariste" peut te convenir si tu cherches > simplement à ne pas te poser les bonnes questions sur la liberté > > le discours de RMS sur le sujet : > https://www.youtube.com/watch?v=CP8CNp-vksc > > la position de la FSF: > https://www.gnu.org/philosophy/ubuntu-spyware.en.html > > désolé pour la pique, mais il faut remettre les choses en place et ne > pas se voiler la face ... > http://www.gnu.org/distros/free-distros.html Oups il n'y a pas debian dans la liste ! Je me demande bien pourquoi ? Pourtant nonfree est clairement séparé du reste... -- Benoit
Blockchain ?
Slt, Je me demande pour sécuriser quelque chose de continuelle, pourquoi ne pas utiliser le système de blockchain, par exemple t’incrementee une opération de ton fichier toutes les une heures de vidéo surveillance en utilisant l’entropie par le biais de ton fichier vidéo e au lieu d’un déplacement de la souris ? (Avec Patty et autre ... ) Donc il existe un acquêt débat qui fait blockchain ? Merci Bonne fêtes de fin d’année — Ptilou Je cherche un étudiant qui cherche un petit job ou poser mon annonce ?
Re: May I please have a block cursor in nano?
On Sb, 26 dec 20, 11:38:30, to...@tuxteam.de wrote: > > This is not 100% clear. For one, some terminal emulators do have escape > sequences to change "cursor style" on the fly (xterm [1], among others), > so a terminal-based application /could/ try to make use of that, (Neo)Vim can take advantage of such facilities, e.g. to change the cursor shape according to the mode. https://stackoverflow.com/questions/6488683/how-do-i-change-the-cursor-between-normal-and-insert-modes-in-vim Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Unsubscrible
Aguinaldo, Para se remover da lista acesse este link: https://lists.debian.org/debian-user-portuguese/ E na seção: Subscribe/Unsubscribe Informe seu endereço de e-mail e clique no botão: Unsubscribe Att Em sáb, 26 de dez de 2020 09:42, Aguinaldo Alves < aguinaldo.al...@yahoo.com.br> escreveu: > > -- > > *Aguinaldo Alves* > > Rua Rubelita, nº 363 - Jardim Santa Helena > Maringá, Paraná, Brasil - CEP: 87083-315 > > Celular: +55 (44) 9 9962-9837 > Telefone: +55 (44) 3023-1972 > > > > > >
Re: Unsubscrible
O pessoal se cadastra num grupo que só procurando muito para achar e não sabe como entrou. O que me preocupa é esse pessoal usando Uber do jeito que usa e-mail e sendo deixado numa cidade vizinha. "Mãe, não sei como o Uber me largou aqui, vem me buscar" Jack Pogorelsky Jr. Engenheiro Mecânico Tel: (51) 985010082 Email: j...@sulmail.com Website: sulmail.com/pogorelsky Em sáb, 26 de dez de 2020 09:42, Aguinaldo Alves < aguinaldo.al...@yahoo.com.br> escreveu: > > -- > > *Aguinaldo Alves* > > Rua Rubelita, nº 363 - Jardim Santa Helena > Maringá, Paraná, Brasil - CEP: 87083-315 > > Celular: +55 (44) 9 9962-9837 > Telefone: +55 (44) 3023-1972 > > > > > >
Unsubscrible
-- *Aguinaldo Alves* Rua Rubelita, nº 363 - Jardim Santa Helena Maringá, Paraná, Brasil - CEP: 87083-315 Celular: +55 (44) 9 9962-9837 Telefone: +55 (44) 3023-1972
Unsubscrible
-- *Aguinaldo Alves* Rua Rubelita, nº 363 - Jardim Santa Helena Maringá, Paraná, Brasil - CEP: 87083-315 Celular: +55 (44) 9 9962-9837 Telefone: +55 (44) 3023-1972
Re: May I please have a block cursor in nano?
On Fri, Dec 25, 2020 at 08:46:02PM -0500, Bob Bernstein wrote: > On Fri, 25 Dec 2020, to...@tuxteam.de wrote: > > >Perhaps what you have to do is to change the shape of your > >terminal's cursor, and nano inherits it. > > Firstly, thanks to ALL of you who took time out on this holiday to > answer my (pretty dumb) question! There are no dumb questions. Any questions? ;-) > I'm certain this is one of those things I knew clearly, say, as few > years ago as ten, but getting old sucks. It does have its upsides, too (I speak from experience :) > OF COURSE the app looks to the terminal for its cursor policy, and > OF COURSE my terminal (mintty running in cygwin -- LONG story) also > lacked a block cursor. This is not 100% clear. For one, some terminal emulators do have escape sequences to change "cursor style" on the fly (xterm [1], among others), so a terminal-based application /could/ try to make use of that, for the other, your app might be a graphical app (nano is not, but that has to be established in the first place), then all bets are off. > Thank you all. You people are just great, but maybe I'm feeling that > on account of all the time I've had to spend with my wife's family > over the holidays. You're welcome :-) Enjoy the time with your extended family. Cheers [1] https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-Ps-q.1CB1 - t signature.asc Description: Digital signature
Re: Format de data incorrecte de «ls -l»
Missatge de Jordi Pujol del dia dv., 25 de
des. 2020 a les 9:42:
>
> Bondia a tothom,
> és la primera vegada que escric a aquesta llista,
> treballo amb sistemes Linux Debian des de fa temps i he desenvolupat
> alguna cosa.
> En aquest cas puc aportar una solució sencilla.
> Es tracta de modificar el "/usr/share/i18n/locales/ca_ES"
>
> # patch ca_ES locale
> sed -i.bak -e '/^ab_alt_mon/,/^[^ ]/ {/"de /s//"/g
> /"d/s//"/g }' \
> -e '/^abmon/,/^[^ ]/ {/"de /s//"/g
> /"d/s//"/g }' \
> -e '/febr./s//feb./' \
> -e '/ag./s//ago./' \
> "/usr/share/i18n/locales/ca_ES"
>
> Aixó es pot fer en un sistema ja instal.lat, sortim del shell i tornem
> a entrar per veure el resultat.
>
> $ ls -lA
> total 44
> -rw--- 1 jpujol users 80183 25 des. 09:30 .bash_history
> -rw--- 1 jpujol users 84057 15 gen. 2020 .bash_history.old
> -rw-r--r-- 1 jpujol users 4380 15 gen. 2020 .bashrc
> drwxr-xr-x 2 jpujol users 4096 15 abr. 2020 Públic
> drwx-- 3 jpujol users 4096 29 ago. 19:56 .sane
> drwx--x--x 2 jpujol users 4096 7 feb. 2020 .ssh
> Salutacions,
>
> Jordi Pujol
>
Gràcies, Jordi
Això seria equivalent (si es volgués fes que al canvi arribés a
tothom) que canviar els valors associats a %b (mesos abreujats).
No m'agrada perquè trenca l'alineament amb el CLDR i perquè canvia les
abreviatures dels mesos que s'usen arreu.
Té el punt positiu (el gran pro) que facilita la presentació en
columnes en els programes de terminal, cert.
Aprofito i amplio la solució per a "date" que he comentat en el correu anterior.
En el mateix fitxer "/usr/share/i18n/locales/ca_ES" que es comenta més
amunt, caldria canviar la línia:
d_t_fmt"%A, %-d %B de %Y, %T %Z"
I posar-hi:
d_t_fmt"%A, %-d %B de %Y, %T"
date_fmt "%A, %-d %B de %Y, %T %Z
Això és, es treu la zona horària de la variable d_t_fmt, i es defineix
una nova variable date_fmt que és la que usa "date".
Es guarden els canvis i, en el meu cas, sortir del shell no ha estat
suficinet, m'ha calgut tornar a generar el locale:
locale-gen
I ara date ja mostra la data correctament.
Faig una última reflexió sobre aquest fil.
La meva intenció en obrir el fil era fer-vos arribar la solució al
problema de «ls -l» que no té res a veure amb el canvi dels mesos del
català. És un problema que em estar tocant molt els nassos i a l'estiu
hi vaig dedicar una estona fins que vaig comprendre per què fallava
«ls -l». I vaig tenir el problema diagnosticat i reportat vaig poder
dormir tranquil. Havia ajudat amb un gra de serro a millorar Debian.
Fins que vaig veure que la causa del problema amb "date" era
completament diferent, ;)
El tema del canvi dels mesos és completament diferent. S'han trencat
coses? Sí. Però permeteu-me que deixí el tema de les abreviatures dels
mesos aquí. Portem un munt de missatges i hi ha arguments a favor i en
contra de les abreviatures actuals. Dubto que ens posem d'acord.
Prefereixo gaudir de les vacances de Nadal amb la família, :)
Dit tot això, retorno al meu "mode ràdio" habitual en la llista.
Gràcies a tothom pels comentaris i aportacions.
Bones Festes!
Joan Montané
Re: Format de data incorrecte de «ls -l»
Hola,
feu un cop d'ull a aquestes ordres, la sol.lució fàcil és modificar el
locale ca_ES
Aquestes ordres son part d'un script molt llarg però en resum es fa:
# patch ca_ES locale
sed -i.bak -e '/^ab_alt_mon/,/^[^ ]/ {/"de /s//"/g
/"d/s//"/g }' \
-e '/^abmon/,/^[^ ]/ {/"de /s//"/g
/"d/s//"/g }' \
-e '/\bfebr[.]/s//feb./' \
-e '/\bag[.]/s//ago./' \
"/usr/share/i18n/locales/ca_ES"
update-locales
Salut,
Jordi Pujol
On Sat, Dec 26, 2020 at 9:58 AM Joan Montané wrote:
>
> Missatge de Ernest Adrogué del dia dj., 24 de des.
> 2020 a les 18:29:
> >
> > 2020-12-24, 13:22 (+0100); Joan Montané escriu:
> > > Caldria veure l'impacte del canvi que indiques. Per exemple en
> > > aplicacions de calendari. Això també trencaria l'alineament amb el
> > > CLDR.
> >
> > Qui va proposar els canvis al CLDR? He intentat investigar-ho, però no
> > he aclarit res.
>
> Jo participo al CLDR aportant-hi dades, però no vaig demanar aquesta
> funcionalitat. Els camps van aparèixer a la base de dades i els
> col·laboradors els vam anar omplint. Habitualment els col·laboradors
> per al català al CLDR som: un representant d'Apple, un representant de
> Google, un representant de Microsoft i algun participant individual,
> com jo mateix. El pes del vot dels col·laboradors individuals és molt
> més petit que els dels membres d'Unicode. Curiosament, el cas català
> ja apareixia en la documentació [1]. Interpreto que alguna de les
> grans corporacions anteriors (membres de pes a d'Unicode) és qui ho va
> promoure.
>
> [1]
> http://cldr.unicode.org/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting
>
> >
> > > No tot funcionava perfectament abans del 2016. Aquests canvis són el
> > > que permeten tenir el format de data correctament escrit, amb la
> > > preposició "de" apostrofa quan cal. Per exemple al calendari de
> > > l'escriptori. Em vaig fer un fart de veure "xxx de abril...".
> > > Considero que sí, s'havien de fer.
> >
> > Probablement no calia modificar el local per solucionar un problema al
> > calendari del Gnome. I en el cas improbable que l'única solució fos
> > modificar el local, era previsible que aquests canvis comportarien
> > problemes a altres programes. Les mateixes persones que van fer els
> > canvis s'haurien d'haver responsabilitzat de fer les adaptacions
> > necessàries als programes afectats per tal que seguissin funcionant
> > normalment. Si no estaven disposades a fer-ho, no haurien d'haver
> > modificat el local. No em sembla bé fer modificacions i després
> > desentendre's de les conseqüències negatives d'aquestes modificacions.
> >
>
> Estic d'acord amb tu en què hi ha feina de corregir problemes, i que
> potser no es va preveure el cas de programes que usen fonts
> monoespaiades i presenten el contingut en format taula. Caldria haver
> fet un repàs més exhaustiu, especialment quan el canvi pot (i de fet
> ho fa) trencar alguna cosa.
>
> La comunitat d'usuaris també podem ajudar-hi. Per exemple, el problema
> de l'ordre "mes dia" del "ls -l" no té res a veure amb el canvi de les
> abreviatures, i portem mínim des de stretch. Han passat 10 anys fins
> que algú s'ho ha mirat amb "carinyo", i això que afecta un munt de
> llengües, no només el català! Sí, ja sé que tots tenim temps limitat,
> però 10 anys ho trobo exagerat.
>
> Ara que he remirat els apunts de quan em vaig mirar el tema de "ls
> -l", hi ha un tema similar, però que té una causa diferent (tampoc
> relacionada amb el canvi en les abreviatures dels mesos). L'ordre
> "date" a buster mostra primer el mes i després el dia del mes. Per
> què? Perquè al locale manca la variable date_fmt [2]. Interpreto que
> en algun moment "date" va passar d'usar "d_t_fmt" a usar "date_fmt",
> la informació no va arribar als mantenidors dels locales i ja tenim el
> problema.
>
>
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24054
>
> > > Ara hem detectat 2 problemes completament diferents, i és important
> > > diferenciar-los.
> > >
> > > Problema 1: aquest és general. Si un programa usa %b o %B en el format
> > > de data, des del 2016 (en producció des del 2018?) això retorna mesos
> > > amb preposició. Ha canviat la cadena del locale. En aquests casos
> > > només cal corregir la traducció perquè usi %Ob o %OB. Forma part de la
> > > feina de traducció/localització. En canviar els valors %b i %B es va
> > > assumir que hi hauria un temps de transició on les traduccions no es
> > > veurien bé (apareixeria la preposició duplicada o sense preposició).
> > > La majoria de traduccions ja s'ha adaptat a usar %Ob i %OB. En queda
> > > algun? Doncs es corregeix en la traducció. És el que caldria fer a
> > > mutt.
> >
> > És que, a part de la preposició, els noms abreviats dels mesos han
> > passat de tenir tres caràcters a tenir una llargada variable (amb punt
> > inclòs). Aquestes dades del local no semblen adequades per a programes
> > informàtics. Els programes
Re: Format de data incorrecte de «ls -l»
Missatge de Ernest Adrogué del dia dj., 24 de des. 2020 a les 18:29: > > 2020-12-24, 13:22 (+0100); Joan Montané escriu: > > Caldria veure l'impacte del canvi que indiques. Per exemple en > > aplicacions de calendari. Això també trencaria l'alineament amb el > > CLDR. > > Qui va proposar els canvis al CLDR? He intentat investigar-ho, però no > he aclarit res. Jo participo al CLDR aportant-hi dades, però no vaig demanar aquesta funcionalitat. Els camps van aparèixer a la base de dades i els col·laboradors els vam anar omplint. Habitualment els col·laboradors per al català al CLDR som: un representant d'Apple, un representant de Google, un representant de Microsoft i algun participant individual, com jo mateix. El pes del vot dels col·laboradors individuals és molt més petit que els dels membres d'Unicode. Curiosament, el cas català ja apareixia en la documentació [1]. Interpreto que alguna de les grans corporacions anteriors (membres de pes a d'Unicode) és qui ho va promoure. [1] http://cldr.unicode.org/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting > > > No tot funcionava perfectament abans del 2016. Aquests canvis són el > > que permeten tenir el format de data correctament escrit, amb la > > preposició "de" apostrofa quan cal. Per exemple al calendari de > > l'escriptori. Em vaig fer un fart de veure "xxx de abril...". > > Considero que sí, s'havien de fer. > > Probablement no calia modificar el local per solucionar un problema al > calendari del Gnome. I en el cas improbable que l'única solució fos > modificar el local, era previsible que aquests canvis comportarien > problemes a altres programes. Les mateixes persones que van fer els > canvis s'haurien d'haver responsabilitzat de fer les adaptacions > necessàries als programes afectats per tal que seguissin funcionant > normalment. Si no estaven disposades a fer-ho, no haurien d'haver > modificat el local. No em sembla bé fer modificacions i després > desentendre's de les conseqüències negatives d'aquestes modificacions. > Estic d'acord amb tu en què hi ha feina de corregir problemes, i que potser no es va preveure el cas de programes que usen fonts monoespaiades i presenten el contingut en format taula. Caldria haver fet un repàs més exhaustiu, especialment quan el canvi pot (i de fet ho fa) trencar alguna cosa. La comunitat d'usuaris també podem ajudar-hi. Per exemple, el problema de l'ordre "mes dia" del "ls -l" no té res a veure amb el canvi de les abreviatures, i portem mínim des de stretch. Han passat 10 anys fins que algú s'ho ha mirat amb "carinyo", i això que afecta un munt de llengües, no només el català! Sí, ja sé que tots tenim temps limitat, però 10 anys ho trobo exagerat. Ara que he remirat els apunts de quan em vaig mirar el tema de "ls -l", hi ha un tema similar, però que té una causa diferent (tampoc relacionada amb el canvi en les abreviatures dels mesos). L'ordre "date" a buster mostra primer el mes i després el dia del mes. Per què? Perquè al locale manca la variable date_fmt [2]. Interpreto que en algun moment "date" va passar d'usar "d_t_fmt" a usar "date_fmt", la informació no va arribar als mantenidors dels locales i ja tenim el problema. [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24054 > > Ara hem detectat 2 problemes completament diferents, i és important > > diferenciar-los. > > > > Problema 1: aquest és general. Si un programa usa %b o %B en el format > > de data, des del 2016 (en producció des del 2018?) això retorna mesos > > amb preposició. Ha canviat la cadena del locale. En aquests casos > > només cal corregir la traducció perquè usi %Ob o %OB. Forma part de la > > feina de traducció/localització. En canviar els valors %b i %B es va > > assumir que hi hauria un temps de transició on les traduccions no es > > veurien bé (apareixeria la preposició duplicada o sense preposició). > > La majoria de traduccions ja s'ha adaptat a usar %Ob i %OB. En queda > > algun? Doncs es corregeix en la traducció. És el que caldria fer a > > mutt. > > És que, a part de la preposició, els noms abreviats dels mesos han > passat de tenir tres caràcters a tenir una llargada variable (amb punt > inclòs). Aquestes dades del local no semblen adequades per a programes > informàtics. Els programes d'interfície de text estan pensats per > funcionar en terminals de 80 columnes. 80 columnes vol dir que l'espai > és extremadament limitat i que la informació textual ha de ser > minimalista. Si comencem a incloure punts, caràcters innecessaris i > textos de llargades variables que trenquen l'alineació, l'usuabilitat > d'aquests programes es degrada tant que els usuaris probablement no > tindran més alternativa que emprar un altre local. > El tema és que les dades del locale no només s'usen des de programes de terminal. S'usen en tot el sistema. Potser m'equivoco, però la tendència és anar cap a interfícies gràfiques amb finestres i botons, i també missatges de veu sintetitzats a partir
Mjuqbvlg ookapvc
Jdhvra yblcdhfqt svwcmh!
