Re: No GRUB with brand-new GPU
On Sun 27 Dec 2020 at 07:02:53 (-0500), The Wanderer wrote: > On 2020-12-26 at 23:01, David Wright wrote: > > 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'm not sure what exact sequence of actions you're suggesting. > > AFAIK, this motherboard doesn't have integrated graphics, and if it does > I don't have a cable suitable to connect them to my monitor; Fair enough. As I said, it's a while back, and some mobos had integral graphics and some didn't. (I didn't control their purchase, and some were second-use.) > I therefore > can't meaningfully boot (much less reboot), How meaningful it is depends on what sort of notice the mobo takes of the lack of the old card. But you should certainly be able to boot and the POST should run. > let alone get into the CMOS > to "save settings", after removing the old card and before putting in > the new. True, when there's no onboard graphics, though actually I could type unseen the necessary keystrokes to Exit Saving Changes in the Phoenix BIOS. > I have gone into the CMOS, and (by chance) IIRC even made and saved a > change, after putting in the new card. It didn't help. I'm guessing that my problem involved the configuration of the card by the bus, whereas yours is later on, involving drivers etc. Cheers, David.
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sun 27 Dec 2020 at 22:10:53 (+), Andrew M.A. Cater wrote: > On Sun, Dec 27, 2020 at 08:33:26AM -0700, Charles Curley wrote: > > On Sun, 27 Dec 2020 11:01:22 + "Andrew M.A. Cater" wrote: > > > > > > > > Bug??: DI incorrectly detected this machine as having EFI. > > > > > > > At the beginning? Did you get presented with the UEFI install and did > > > it try to install grub-efi at the end (or did it just ask whether you > > > wanted to install grub in the efi fallback path - which is normal > > > > The latter. But why even ask about the EFI backup path if there is no > > EFI?? > > > Because that's a default "if all else fails look here" location, perhaps? As I was offered this screen even on my 2000 PentiumIII/Seattle2 PC, I've always assumed that the d-i was led astray by the fact that the ISO is itself UEFI-aware. > It doesn't make a lot of difference: grub is installed as more or less the > last step in installation anyway. And better to give you a screen you don't need rather than not give you one that you do need. > There are bits of deep magic if you want to convert a machine that's been > installed using Legacy Boot to one using UEFI - but it's not straightforward. What would be the benefit of UEFI booting on a machine that can already BIOS boot? The reason I ask is because I have recently wiped Windows from a laptop that booted Windows with UEFI, but linux with the BIOS. Any reason to change? Cheers, David.
restarting pppd automatically
I'm having problems with pppd and an intermittent phone line connection. My external line occasionally drops out, usually briefly (I'm trying to get this fixed but need a workaround in the meantime). When the line goes down, I get this sequence: Dec 27 01:35:03 snoopy pppd[22798]: No response to 4 echo-requests Dec 27 01:35:03 snoopy pppd[22798]: Serial link appears to be disconnected. Dec 27 01:35:03 snoopy pppd[22798]: Connect time 6266.2 minutes. Dec 27 01:35:03 snoopy pppd[22798]: Sent 3838785941 bytes, received 2059599934 bytes. Dec 27 01:35:03 snoopy pppd[22798]: restoring old default route to enp3s0 [xxx.xxx.xx.xxx] Dec 27 01:35:09 snoopy pppd[22798]: Connection terminated. Dec 27 01:35:09 snoopy pppd[22798]: Sent PADT Dec 27 01:35:09 snoopy pppd[22798]: Modem hangup Dec 27 01:36:14 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:37:19 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:38:24 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:39:29 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:40:34 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:41:39 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:42:44 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:43:49 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:44:54 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:46:00 snoopy pppd[22798]: Timeout waiting for PADO packets Dec 27 01:46:00 snoopy pppd[22798]: Exit which I believe is what it is supposed to do, but leaves the connection dead when the phone line comes back a minute later. I want pppd to restart automatically when it goes down like this, maybe with a couple of minutes delay. According to the pppd documentation on https://tldp.org/HOWTO/Leased-Line/pppd.html section 3.2.1 I can do this by editing /etc/inittab. But I've never really relearnt how everything hangs together since the switch to systemd, and in any case want to stay as close as I can to the default debian setup (which is what I have now). Can anyone tell me what the recommended way to achieve this is now? Thanks Graham
Re: No GRUB with brand-new GPU
On 2020-12-27 at 17:23, to...@tuxteam.de wrote: > On Sun, Dec 27, 2020 at 05:08:27PM -0500, The Wanderer wrote: > > [...] > >> I have the impression that things have by now developed to the >> point where a physical serial-port cable (of the classic type of >> serial port and cable, whose connectors can be visually confused >> with a VGA port in some cases) is no longer necessary, which is >> good, since if we ever had such a thing it was at least back in the >> days of PS/2 keyboards and mice and might have been back in the >> days before our home computers had internal hard drives. > > "Modern" computers tend to lack serial ports (sometimes a pity, but > well...) > > Still I doubt it would be any help. You made a credible case that > there is a hard lockdown at the handover from the BIOS to GRUB. You'd > have to be very lucky for GRUB to utter a last sigh over serial > before that. > > My impression is that the video card reacts allergically to some > modeset attempt by GRUB and this causes a pretty low level lockup. I've had similar thoughts, but if that were the case, I'd expect that telling GRUB to use "console" output would avoid the problem, by having it not do any modesetting. My most recent attempt was with terminal_input and terminal_output set to "console", and the problem persisted. I do see various modules listed in the grub.cfg load_video function, and it's not impossible that the process of trying to use one or more of those includes some action which triggers this behavior. I haven't found a place to configure that, though - or I hadn't until now; it's in /etc/grub.d/00_header, and can be overridden to a single module by defining GRUB_VIDEO_BACKEND (presumably, in /etc/default/grub). I might pursue that if the live-boot environment doesn't give fruitful results. -- 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 Sun, Dec 27, 2020 at 05:08:27PM -0500, The Wanderer wrote: [...] > I have the impression that things have by now developed to the point > where a physical serial-port cable (of the classic type of serial port > and cable, whose connectors can be visually confused with a VGA port in > some cases) is no longer necessary, which is good, since if we ever had > such a thing it was at least back in the days of PS/2 keyboards and mice > and might have been back in the days before our home computers had > internal hard drives. "Modern" computers tend to lack serial ports (sometimes a pity, but well...) Still I doubt it would be any help. You made a credible case that there is a hard lockdown at the handover from the BIOS to GRUB. You'd have to be very lucky for GRUB to utter a last sigh over serial before that. My impression is that the video card reacts allergically to some modeset attempt by GRUB and this causes a pretty low level lockup. Cheers - t signature.asc Description: Digital signature
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sun, Dec 27, 2020 at 08:33:26AM -0700, Charles Curley wrote: > On Sun, 27 Dec 2020 11:01:22 + > "Andrew M.A. Cater" wrote: > > > > > > > Bug??: DI incorrectly detected this machine as having EFI. > > > > > > > At the beginning? Did you get presented with the UEFI install and did > > it try to install grub-efi at the end (or did it just ask whether you > > wanted to install grub in the efi fallback path - which is normal > > The latter. But why even ask about the EFI backup path if there is no > EFI?? > Because that's a default "if all else fails look here" location, perhaps? It doesn't make a lot of difference: grub is installed as more or less the last step in installation anyway. There are bits of deep magic if you want to convert a machine that's been installed using Legacy Boot to one using UEFI - but it's not straightforward. All best, Andy C > > > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ >
Re: No GRUB with brand-new GPU
On 2020-12-27 at 16:36, Anssi Saari wrote:
> The Wanderer writes:
>
>> I need to get that live-boot medium ready and do those tests.
>
> That seems like a good thing to do.
I have it ready now, but haven't shut down for another swap, in part
because I've been napping. I may do it tonight, or more likely, tomorrow.
> Another thing you could do is post your grub.cfg. It seems a little
> odd you haven't.
It mainly just hadn't occurred to me, in part (though only in part)
because I thought I recalled that the boot-configuration files for GRUB2
weren't the same as from legacy GRUB (and might even be stored in
multiple files) and had a mental association of that file with legacy
GRUB, so didn't trust it to necessarily be the correct / full config.
Now that it's been suggested, I have a bit of concern about posting a
file containing filesystem (and other related?) UUIDs; that's probably
excessive paranoia (last time I needed to post a file containing complex
IDs like that some of them were encryption-key hashes), but I've still
chosen to sed them out into generic form before attaching the result.
That's the only difference between the attachment and the original.
I don't expect there to be any useful / relevant information there, but
one never knows.
It occurs to me that it might be worthwhile to note down some
get-information commands from the GRUB documentation, and stop at the
GRUB menu next time I'm booting with the old / current GPU to see
whether I can extract anything that might be helpful.
> Also from previous discussion I think it's worth mentioning that Grub
> doesn't actually read /etc/default/grub, update-grub reads it to
> generate /boot/grub/grub.cfg. So only editing /etc/default/grub
> doesn't change Grub config in any way.
Yes, I know that much. After applying the change, I ran update-grub to
re-generate the config files appropriately.
> If you're up for it, you could setup a serial terminal and send Grub
> output to serial and/or console. That way you might be able to boot
> and wouldn't have to switch video cards to try different
> configurations. But if you only have that one computer then I guess
> not.
We have at least a dozen computers in the household, if you count
servers and laptops, and AFAIK a plurality of them are Debian-based.
What we don't have is A: any experience with working with serial
console, or B: (that I know of) any cables that might work to connect
two computers that way.
I have the impression that things have by now developed to the point
where a physical serial-port cable (of the classic type of serial port
and cable, whose connectors can be visually confused with a VGA port in
some cases) is no longer necessary, which is good, since if we ever had
such a thing it was at least back in the days of PS/2 keyboards and mice
and might have been back in the days before our home computers had
internal hard drives.
I imagine USB would be the replacement (just based on the name), and I'm
also aware of the existence (kernel-side) of netconsole, but how to use
either for this I don't know.
--
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
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
Re: No GRUB with brand-new GPU
The Wanderer writes: > I need to get that live-boot medium ready and do those tests. That seems like a good thing to do. Another thing you could do is post your grub.cfg. It seems a little odd you haven't. Also from previous discussion I think it's worth mentioning that Grub doesn't actually read /etc/default/grub, update-grub reads it to generate /boot/grub/grub.cfg. So only editing /etc/default/grub doesn't change Grub config in any way. If you're up for it, you could setup a serial terminal and send Grub output to serial and/or console. That way you might be able to boot and wouldn't have to switch video cards to try different configurations. But if you only have that one computer then I guess not.
Re: Some recent update to unstable seems to have broken Xfce4 for me
Celejar wrote: > Some recent update to unstable seems to have broken Xfce4 for me: The Xfce team is uploading Xfce 4.16 at the moment. Because not all components can be uploaded in one go, this may cause some temporary problems or instability. I'd advise you to wait some days until all uploads have finished and then check back if the problem persists and file bugs if needed. Grüße, Sven. -- Sigmentation fault. Core dumped.
Re: Some recent update to unstable seems to have broken Xfce4 for me
On 28-12-2020 05:58, Celejar wrote: > Hi, > > Some recent update to unstable seems to have broken Xfce4 for me: I > can't suspend the the machine anymore. When I try the keyboard shortcut > I've configured (that has worked for years), I get an error popup > window: > > Received error while trying to log out > GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: > Type of message, "(yb)", does not match expected type "(b") > > (I've googled this message and found other references to it, but no > clear solution / interpretation: > > https://unix.stackexchange.com/questions/626284/thunar-bug-should-i-report-to-xfce-or-ubuntu > https://askubuntu.com/questions/1233288/unable-to-logout-from-guest-session-on-xubuntu-20-04 > https://bugzilla.redhat.com/show_bug.cgi?id=1729059 > https://forums.freebsd.org/threads/xfce-wont-let-me-log-out-anymore.76968/ > https://www.reddit.com/r/xfce/comments/bej4xx/received_error_while_trying_to_log_out/ > ) > > When I try the little "sleepy moon" icon, I get a different popup window: > > Failed to run action "Suspend" > GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen. > > Any ideas? The only related? fault I can see with my set up, also Xfce unstable, is I can't enter the password to unlock it. I have no problem anywhere else. Cheers! Harry -- `We'll know our disinformation program is complete when everything the American public believes is false'. -- William Casey, CIA Director (first staff meeting, 1981)
Re: Kde inutilisable
Le Sun, 27 Dec 2020 11:59:29 +0100, Francois Mescam a écrit : > je suis en testing et ce matin j'ai fait la mise à jour de kde sauf 4 > paquets que j'ai gelé pour cause de dépendances non satisfaites. > > Résultat lors du début d'une session mes diverses applis se lancent > bien mais le tour des fenres ne s'affiche pas et donc pas possible de > changer de fenêtre donc kde est à ce stade inutilisable. > > je verrai demain s'il y a du nouveau. C'est pour ce genre d'ennui que j'aime bien aptitude, surtout en testing/sid : je fais toujours un safe-upgrade et s'il y a des problème de dépendances soit je diffère, soit j'y vais prudemment paquet par paquet. En plus aptitude fournis quand même pas mal de solutions par lui-même. En tout cas je n'upgrade jamais de force ni ne fige de paquets, ça devient vite ingérable. Pour la même raison je fais aussi du pinning avec Sid en backup, ça permet la plupart du teps de ne pas rester coincé sur un paquet en testing qui peut rester parfois longtemps avant de résoudre un problème: C'est normal, il s'agit d'intégration pour construire une stable et pas d'une version de production... Sid est plus souple et réactive à ce niveau.
Some recent update to unstable seems to have broken Xfce4 for me
Hi, Some recent update to unstable seems to have broken Xfce4 for me: I can't suspend the the machine anymore. When I try the keyboard shortcut I've configured (that has worked for years), I get an error popup window: Received error while trying to log out GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, "(yb)", does not match expected type "(b") (I've googled this message and found other references to it, but no clear solution / interpretation: https://unix.stackexchange.com/questions/626284/thunar-bug-should-i-report-to-xfce-or-ubuntu https://askubuntu.com/questions/1233288/unable-to-logout-from-guest-session-on-xubuntu-20-04 https://bugzilla.redhat.com/show_bug.cgi?id=1729059 https://forums.freebsd.org/threads/xfce-wont-let-me-log-out-anymore.76968/ https://www.reddit.com/r/xfce/comments/bej4xx/received_error_while_trying_to_log_out/ ) When I try the little "sleepy moon" icon, I get a different popup window: Failed to run action "Suspend" GDBus.Error:org.xfce.SessionManager.Error.Failed: Failed to lock the screen. Any ideas? Celejar
Re: /bin/sh naar bash i.p.v. dash linken
On Sat, Dec 26, 2020 at 09:13:23PM +0200, Wouter Verhelst wrote: > 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 Lees vooral verder > > 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. Hoe dat kan? bash is tien keer groter dan dash? " $ ls -l $(which bash) $(which dash) " -rwxr-xr-x 1 root root 1254856 4 nov 18:01 /bin/bash " -rwxr-xr-x 1 root root 125560 12 nov 08:58 /bin/dash > 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). De pijn van het terugzetten komt pas als je het shell script wat voor jou werkt ( want /bin/sh link naar /bin/bash verbergt bashism features) niet werkt voor de ander ( want /bin/sh link naar /bin/dash ) > To the thief who stole my anti-depressants: I hope you're happy > -- seen somewhere on the Internet on a photo of a billboard Groeten Geert Stappers -- Silence is hard to parse.
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sun, 27 Dec 2020 11:01:22 + "Andrew M.A. Cater" wrote: > > 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". > > > > How did you try to load the firmware - via USB stick / untarring a > tar ball? What did it report in logs. Yes, I know, it's a nuisance > installing firmware this way but it ought to work. USB stick, no tarball. Selected extracts from the logs and other information are in the attached file, dragon.cpu.txt. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/ root@dragon:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping: 6 microcode : 0x18 cpu MHz : 600.000 cache size : 2048 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe bts est tm2 bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips: 1199.01 clflush size: 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: root@dragon:~# uname -mpi i686 unknown unknown root@dragon:~# free totalusedfree shared buff/cache available Mem: 1258 186 79 14 992 894 Swap: 1951 11950 Total: 3210 1872030 root@dragon:~# Selected lines from /var/log/installer/hardware-summary: lspci -knn: 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) lspci -knn: Subsystem: Intel Corporation Device [8086:2711] lspci -knn: Kernel driver in use: ipw2200 lspci -knn: Kernel modules: ipw2200 lsmod: lib80211_crypt_wep 16384 1 lsmod: libarc416384 1 lib80211_crypt_wep lsmod: ipw2200 139264 0 lsmod: libipw 32768 1 ipw2200 lsmod: lib80211 16384 2 lib80211_crypt_wep,libipw lsmod: cfg80211 577536 2 ipw2200,libipw lsmod: rfkill 20480 1 cfg80211 lsmod: nls_ascii 16384 0 lsmod: nls_cp437 16384 0 /proc/iomem: c020-cfff : PCI Bus :02 /proc/iomem: c0204000-c0204fff : :02:02.0 /proc/iomem: c0204000-c0204fff : ipw2200 /proc/iomem: c0205000-c0205fff : :02:08.0 /proc/iomem: c0205000-c0205fff : e100 /proc/iomem: c400-c7ff : PCI CardBus :03 /proc/interrupts: 9:717XT-PIC acpi /proc/interrupts: 11: 136193XT-PIC yenta, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, ipw2200, enp2s8 /proc/interrupts: 12: 2XT-PIC i8042 Selected lines from /var/log/installer/syslog: Dec 25 15:44:24 kernel: [ 112.347771] libipw: Copyright (C) 2004-2005 Intel Corporation Dec 25 15:44:24 kernel: [ 112.359982] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq Dec 25 15:44:24 kernel: [ 112.359985] ipw2200: Copyright(c) 2003-2006 Intel Corporation Dec 25 15:44:24 kernel: [ 112.360261] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection Dec 25 15:44:24 kernel: [ 112.360325] ipw2200 :02:02.0: firmware: failed to load ipw2200-bss.fw (-2) Dec 25 15:44:24 kernel: [ 112.360328] ipw2200 :02:02.0: Direct firmware load for ipw2200-bss.fw failed with error -2 Dec 25 15:44:24 kernel: [ 112.360331] ipw2200: Unable to load firmware: -2 Dec 25 15:44:24 kernel: [ 112.360435] ipw2200: probe of :02:02.0 failed with error -5 Dec 25 15:44:27 check-missing-firmware: looking at dmesg again, restarting from \[ 41.376386\] Dec 25 15:44:27 check-missing-firmware: timestamp found, truncating dmesg accordingly Dec 25 15:44:27 check-missing-firmware: saving timestamp for a later use: [ 112.360435] Dec 25 15:44:27 check-missing-firmware: looking for firmware file regulatory.db requested by platform Dec 25 15:44:27 check-missing-firmware: looking for firmware file ipw2200-bss.fw requested by ipw2200 Dec 25 15:44:27 check-missing-firmware: /dev/.udev/firmware-missing does not exist, skipping Dec 25 15:44:27 check-missing-firmware: /run/udev/firmware-missing does not exist, skipping Dec 25 15:44:27 check-missing-firmware: missing firmware files (regulatory.db ipw2200-bss.fw) for ipw2200 platform Dec 25 15:44:28 kernel: [ 115.953931] isofs_fill_super: bread
[SOLVED] python3.9 venv testing error message
the mismatch of the version of distutils prevented it from working so the solution was to upgrade distutils from unstable and it works now. songbird
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sun, 27 Dec 2020 11:01:22 + "Andrew M.A. Cater" wrote: > > > > Bug??: DI incorrectly detected this machine as having EFI. > > > > At the beginning? Did you get presented with the UEFI install and did > it try to install grub-efi at the end (or did it just ask whether you > wanted to install grub in the efi fallback path - which is normal The latter. But why even ask about the EFI backup path if there is no EFI?? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: QEMU-KVM VMs sometime freeze when I run them for a couple of days
George Shuklin's comment may have intended this question too: Are backups running somewhere when the VMs "randomly" hang? Not necessarily on the VM that hangs, but somewhere touching a related filesystem, disk or network device? On Sun, Dec 27, 2020, 4:33 AM wrote: > From: Dan Ritter > > > You probably want to change that to 1 minute or so. > > Btw. could you please tell me how to do that? > > I know how to modify (=> override) systemd unit files but I have no idea > how to change default timeout for mounted block devices that I didn't > manually create in /etc/systemd/system/... > > Thank you. > > Robert > >
Re: Format de data incorrecte de «ls -l»
Missatge de Jordi Pujol del dia dg., 27 de des. 2020 a les 14:57: > > Com s'ha de comprovar l'alineament amb el CLDR ? En el cas que ens ocupa, aquí [1] hi ha les abreviatures dels mesos [1] https://unicode-org.github.io/cldr-staging/charts/latest/summary/ca.html#360c210ad4f23085 > > Em sembla que tenim diferents punts de vista degut a que fem servir > diferents nivells de Debian, els meus sistemes son unstable i aquest > canvi és satisfactori. És satisfactori si l'ús principal és terminal, però en escriptori fa que s'usin abreviatures no estàndards, i en alguns casos no es podrà escriure la data correctament (amb preposició). > Abans "ls -l" posava sempre la preposició "de" i no deixava veure els > noms dels mesos, amb aquest canvi el llistat de directoris amb format > llarg es presenta correctament. > No deixava veure els mesos? Això no hauria de passar mai. «ls -l» no talla els noms dels mesos. Els noms dels mesos sempre els hauries de veure. Passa que, a sid, Si la traducció de «ls» indica %Ob (sense preposició, el que ara mateix hi ha a la traducció), no apareix la preposició, però «ls» no enquadra els mesos i es desquadren els mesos d'abril, agost i febrer. Si la traducció de «ls» indica %b (amb preposició). ls "enquadra" els mesos i apareix tot en columna El dubté és si «ls -l» honora la cadena de la traducció o no (això depèn de l'enllaç que indicava en el primer missatge del fil), però en qualsevol cas, els mesos sempre s'haurien de veure. O potser et refereixes que no veies els noms dels mesos en algun altre programa? Això sí que és important. Hi ha cap programa que talli els noms dels mesos? > > > > Aprofito i amplio la solució per a "date" que he comentat en el correu > > anterior. > > > > aquest canvi que proposes ja s'ha fet al ca_ES de unstable. Sí! Com el tema de l'enllaç perquè «ls -l» honori la cadena que indica el format de data, ja està apedaçat. Tard o d'hora arribarà a stable. Joan Montané
Re: No GRUB with brand-new GPU
On 2020-12-27 at 07:10, The Wanderer wrote: > On 2020-12-27 at 02:51, Sven Joachim wrote: > >> On 2020-12-26 18:44 -0500, The Wanderer wrote: >>> 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). > > Ah, thanks for that correction; that does ring a bell now that you > mention it. > > That would explain why this would be effective. I've made that change > in this file; as soon as I reach a point in my operations where > shutting down again is reasonable, I'll test to confirm that I can > boot that way with the old GPU (and what behavior difference there > may be with that change), and assuming it works will swap GPUs and > see what I get. No joy. It works fine with the old GPU (better, actually, in that the GRUB menu doesn't take several seconds to draw; the lower boot-menu resolution is no hardship), but if anything the behavior with the new GPU is *worse*; I think I got the keyboard freeze even earlier on my first try with the new configuration, although it seems to have gone back to happening at the handover on subsequent attempts, I then went into the BIOS to check it over again, and found that an option for "BIOS EHCI handoff" was set to enabled, with the apparent meaning that the BIOS would take care of handing over USB EHCI control to the booted system rather than relying on the OS to handle that. On the presumption that modern Linux should be able to handle this itself, I disabled that setting; my USB devices are working fine now with the old GPU, but on the new it left me with no apparent change. That may be worth paying more attention to: this isn't just a black-screen hang, it's a more full-system hang. The keyboard lights stay in whatever state they were in immediately prior to the handover, and nothing responds to the keyboard at all. I did also confirm that the BIOS version is 1402, which is the version number of the final BIOS released for this motherboard back in 2012. If the BIOS needing updates to work with this GPU is the problem, then I'm SOL. Still, again, if that were the problem I'd expect there to be no display output during POST and in the BIOS... I need to get that live-boot medium ready and do those tests. -- 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: Format de data incorrecte de «ls -l»
Hola Joan i tothom, On Sat, Dec 26, 2020 at 10:16 AM Joan Montané wrote: > 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. Com s'ha de comprovar l'alineament amb el CLDR ? Em sembla que tenim diferents punts de vista degut a que fem servir diferents nivells de Debian, els meus sistemes son unstable i aquest canvi és satisfactori. Abans "ls -l" posava sempre la preposició "de" i no deixava veure els noms dels mesos, amb aquest canvi el llistat de directoris amb format llarg es presenta correctament. > > 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 > aquest canvi que proposes ja s'ha fet al ca_ES de unstable. > Bones Festes! Bon nadal i Feliç any nou 1 Jordi Pujol
Re: Kde inutilisable
Le 27/12/2020 à 11:59, Francois Mescam a écrit : > je suis en testing et ce matin j'ai fait la mise à jour de kde sauf 4 > paquets que j'ai gelé pour cause de dépendances non satisfaites. > > Résultat lors du début d'une session mes diverses applis se lancent > bien mais le tour des fenres ne s'affiche pas et donc pas possible de > changer de fenêtre donc kde est à ce stade inutilisable. > > je verrai demain s'il y a du nouveau. > > Pour l'instant je me suis rabattu sur xfce. > Merci de prévenir, j'ai failli me faire avoir... Je vais attendre un peu.
Re: No GRUB with brand-new GPU
On 2020-12-27 at 02:51, Sven Joachim wrote: > 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). Ah, thanks for that correction; that does ring a bell now that you mention it. That would explain why this would be effective. I've made that change in this file; as soon as I reach a point in my operations where shutting down again is reasonable, I'll test to confirm that I can boot that way with the old GPU (and what behavior difference there may be with that change), and assuming it works will swap GPUs and see what I get. I also want to make sure I have an up-to-date rescue environment on external media, just in case I need to revert this change in order to boot my current system again. Unlikely, but better to be safe than sorry. -- 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 2020-12-27 at 02:31, Andrei POPESCU wrote: > 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). I know my monitor resolution; it's 2560x1600, and supports many exact-subset lower resolutions. What type of query were you thinking of? The output of xrandr is one possibility, and that of 'get-edid | parse-edid' (with /dev/ mounted exec) is another; the latter is closer to a true "query the monitor", but seems to provide less information. >> 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. I already checked, and didn't see any settings that seemed relevant. IIRC I did change an unrelated setting which I noticed along the way. This behavior didn't change afterward. > 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. If it can get *anything* after the BIOS handover, it's at least progress from where I currently sit. Validating with those basic minimal graphics is actually a good thing, IMO, although you're right that it only goes so far. -- 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 2020-12-26 at 23:01, David Wright wrote: > 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'm not sure what exact sequence of actions you're suggesting. AFAIK, this motherboard doesn't have integrated graphics, and if it does I don't have a cable suitable to connect them to my monitor; I therefore can't meaningfully boot (much less reboot), let alone get into the CMOS to "save settings", after removing the old card and before putting in the new. I have gone into the CMOS, and (by chance) IIRC even made and saved a change, after putting in the new card. It didn't help. -- 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
Impossible de ddémarrer VLC avec Optirun
Bonjour, J'ai installé et configuré Bumblebee sous Debian Buster à fin de n'utiliser que macarte Nvidia quand nécessaire. Je souhaite l'utiliser pour VLC car avec le GPU Intel, la machine freeze tout simplement, je n'ai plus qu'à redémarrer si j'essaye de lire une vidéo quelle qu'elle soit et je n'ai trouvé aucune autre solution. En écrivant "ON" dans /proc/acpi/bbswitch et démarrant la vidéo dans VLC ça fonctionne. Par contre, si je fais "optirun vlc", j'ai simplement l'interface de VLC en ligne de commande. Voilà ce qui ressort dans le terminal : $ optirun vlc VLC media player 3.0.11 Vetinari (revision 3.0.11-0-gdc0c5ced72) [55e80faab570] main libvlc: Lancement de vlc avec l'interface par défaut. Utiliser « cvlc » pour démarrer VLC sans interface. ../include/vlc_xlib.h:46:vlc_xlib_init: Xlib not initialized for threads. This process is probably using LibVLC incorrectly. Pass "--no-xlib" to libvlc_new() to fix this. [55e80fb980c0] qt interface error: Xlib not initialized for threads ../include/vlc_xlib.h:46:vlc_xlib_init: Xlib not initialized for threads. This process is probably using LibVLC incorrectly. Pass "--no-xlib" to libvlc_new() to fix this. [55e80fb980c0] skins2 interface error: Xlib not initialized for threads [55e80fb980c0] skins2 interface error: initializing xlib for multi-threading failed [55e80fb980c0] skins2 interface error: cannot initialize OSFactory [55e80faaf4e0] main playlist: playlist is empty [55e80fb980c0] [cli] lua interface: Listening on host "*console". VLC media player 3.0.11 Vetinari Command Line Interface initialized. Type `help' for help. > quit Shutting down. [55e80fb980c0] [cli] lua interface: Requested shutdown. à toutes fins utiles : $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Device 9ba4 (rev 05) 01:00.0 VGA compatible controller: NVIDIA Corporation Device 1f99 (rev ff) Autre constatation : si je fais le lspci ci-dessus après le optirun, la machine freeze. En fait ça semble le faire si la carte NVIDIA est sur off mais pas toujours. Quelques spécifications matériel : - Processeur : Intel Core i5 10200H ; - Carte graphique : NVIDIA GeForce GTX 1650 Dans /etc/bumblebee/bumblebee.conf j'ai spécifié Bridge=primus dans la section optirun mais ça n'a rien changé. J'ai installé le driver propriétaire, version backports, pareil pour la version de bumblebee et primus. J'ai utilisé les paquets bumblebee-nvidia et primus-nvidia pour m'assurer d'avoir tout vu que j'utilise le driver propriétaire. Version du kernel : 5.9.0-0.bpo.2-amd64 J'ai pris le meta-paquet firmware-linux dans sa version backports. Vu que la machine se figeait dès le démarrage, conformément à ce qui est indiqué sur le wiki fr de Debian j'ai appliquer la solution au bug suivant : https://github.com/Bumblebee-Project/Bumblebee/issues/1036 Pour être sûr, j'ai également créé et activé un service SystemD pour réactiver le GPU NVIDIA à l'arrêt de la machine. Je pense n'avoir rien oublié de mes recherches et manipulations :) En faisant une recherches spécifique sur le problème de VLC, je ne trouve que des résultats qui datent de versions antérieures et qui spécifient que le problème a été corrigé dans VLC... Quelqu'un a-t-il rencontré ce genre de problème ou aurait une idée de piste à part faire echo ON|sudo tee /proc/acpi/bbswitch avant de démarrer VLC puis faire la même chose mais en écrivant OFF au lieu de ON en fermant VLC ? à la limite, que puis-je faire pour ne pas avoir à activer la carte NVIDIA ? En somme pouvoir utiliser VLC avec la carte Intel... Merci d'avoir eu le courage de lire ce pavé... Bon dimanche, Patrick
Kde inutilisable
je suis en testing et ce matin j'ai fait la mise à jour de kde sauf 4 paquets que j'ai gelé pour cause de dépendances non satisfaites. Résultat lors du début d'une session mes diverses applis se lancent bien mais le tour des fenres ne s'affiche pas et donc pas possible de changer de fenêtre donc kde est à ce stade inutilisable. je verrai demain s'il y a du nouveau. Pour l'instant je me suis rabattu sur xfce. -- Francois Mescam
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sat, Dec 26, 2020 at 03:18:40PM -0700, Charles Curley wrote: > 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. > At the beginning? Did you get presented with the UEFI install and did it try to install grub-efi at the end (or did it just ask whether you wanted to install grub in the efi fallback path - which is normal > 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". > How did you try to load the firmware - via USB stick / untarring a tar ball? What did it report in logs. Yes, I know, it's a nuisance installing firmware this way but it ought to work. > Graphics are slow but serviceable. Mozilla and LibreOffice are > pathetically slow but usable in a pinch. > > -- Thanks for the report. All best, Andy > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ >
Re: QEMU-KVM VMs sometime freeze when I run them for a couple of days
From: Dan Ritter > You probably want to change that to 1 minute or so. Btw. could you please tell me how to do that? I know how to modify (=> override) systemd unit files but I have no idea how to change default timeout for mounted block devices that I didn't manually create in /etc/systemd/system/... Thank you. Robert
