Re: Thunderbird inbox malfunction
Paul D Schmitt wrote on 2/14/24 10:49: After an upgrade of Debian 11 yesterday, Thunderbird 115.7.0 now has an inbox issue where the listings move making it difficult to save or delete them! I had this exact issue with Debian based Antix 22 after a recent upgrade. That problem was resolved by a subsequent upgrade from Thunderbird. I haven't seen any response to this, so I just thought I'd confirm to you for your peace of mind that there is indeed a problem (or several problems) of some sort, and it's not just you who is experiencing it/them. Following the last update of TB here, it's been awful to try to work with the view of messages. I don't know how they could have released it in such a horrible state, but am assuming that the next update will fix the problem(s). Doc -- Web: http://enginehousebooks.com/drevans
Re: running a snap package on bookworm?
Greg Wooledge wrote on 1/24/24 12:24: On Wed, Jan 24, 2024 at 12:16:21PM -0700, D. R. Evans wrote: 4. But now how do I actually run the program? I tried just running: $ acrordrdc Have you looked at the man page for snap? It's very long, so I took a guess and looked for "run". Thank you; right at the beginning of the man page it says: > The snap command lets you install, configure, refresh and remove snaps so I didn't think it would be relevant to running a package that was already installed. run Run the given snap command I read that and think: "but I don't want to run a snap command; I want to run an installed snap package". The run command executes the given snap command with the right confinement and environment. Usage: snap [OPTIONS] run [run-OPTIONS] . [...] When I try the run command: $ snap run acrordrdc unknown command: run $ I was amazed that I simply couldn't find anything about actually running installed packages (plenty of sites tell me how to install a package, but none that I looked at then told me how to run the package once it's installed). It can't be hard, but obviously I'm misunderstanding something fundamental about snap. Doc -- Web: http://enginehousebooks.com/drevans
running a snap package on bookworm?
1. I've never used a snap package before. 2. I want to run the acrordrdc program, which is available as a snap package. 3. Following instructions found following a search for help with snap, I ran: sudo apt install snapd sudo snap install core sudo snap install acrordrdc There were no obvious errors. 4. But now how do I actually run the program? I tried just running: $ acrordrdc but that produced: /user.slice/user-1000.slice/session-14.scope is not a snap cgroup which I suppose is useful to someone, but tells me nothing other than that there seems to be some sort of snap-related problem somewhere. 5. As far as I can see, no new entry was added to the start menu, so it would seem that I'm supposed to run the program -- which I assume has the same name as the package; i.e., "acrordrdc" -- from the command line; but how? Doc -- Web: http://enginehousebooks.com/drevans
Re: X: how to *really* switch from nouveau to modesetting?
Felix Miata wrote on 9/12/23 11:51: You really should eliminate that xorg.conf file, and if the problem continues, don't assume it's the kernel driver at fault. Just report a bug if so inclined. Where would depend on behavior after removing xorg.conf. If it fixes the problem, there is almost assuredly no bug anywhere at all affecting you. If with modesetting it's gone, but with xserver-xorg-video-nouveau installed and in use it remains, then it would be good to report a nouveau DDX bug, though the problem could be DRI or Mesa. Unreported bugs can go a very long time before a fix occurs, if ever. What you are now experiencing is not acceptable behavior. 13 years of age is too young to accept FOSS performance degradation or need GPU upgrade. I have removed /etc/X11/xorg.conf, and the problem remains. So in this case, where should I report the issue? Doc -- Web: http://enginehousebooks.com/drevans
Re: X: how to *really* switch from nouveau to modesetting?
Felix Miata wrote on 9/11/23 19:57: You did it. You made the switch. But see below. (There are multiple components to GPU support in Linux.) (There is no "the" nouveau "driver". Graphics support is in the hands of multiple software components, several of which incorporate the string "nouveau" in naming.) I'm glad that you understand this stuff. It certainly seems non-obvious. And the days of good O'Reilly books that walk one through details like this seem to be long gone :-( From the rest of your post, it sounds like everything is as it should be, except that I should probably remove the /etc/X11/xorg.conf file. And I could also re-install the xserver-xorg-video-nouveau without effecting any change; but for now I think I'll just keep things as they are and just note these as possible changes to try sometime, with the expectation that they won't make any practical difference, but might make the system a bit cleaner to administer. And, from what you say here: > D. R. Evans composed on 2023-09-11 11:47 (UTC-0600): > >> Graphics: >> Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau > > Above shows your kernel DEVICE driver is nouveau. It ships specifically for each > kernel with each kernel. For NVidia GPUs there is no other FOSS device driver > option for normal use with KMS enabled, which maximum possible FOSS performance > unconditionally requires. With KMS disabled, there is a crude generic option with > limited resolutions available that no one ever would use purposely unless too > naive to understand the opportunity loss. It's for fallback and troubleshooting > when normal is unavailable. it sounds like the issue must be in the nouveau kernel device driver, and there's nothing I can really do to change that. So I guess I will just wait and hope that some future update removes the problem. ⁂ Just for the record, to provide some context for anyone finding this thread as a result of a search: 1. The issue is that black-on-white text has a "tail" extending some distance on the right of the text (I don't know how to describe it any better than that). 2. It began with a normal bullseye update. Before that, there was no problem at all. 3. Every update and upgrade since then has exhibited the problem. 4. The monitor is KVM-switchable to another bookworm installation, which does not (and never has) exhibited the problem. Doc -- Web: http://enginehousebooks.com/drevans
X: how to *really* switch from nouveau to modesetting?
This is a follow-on to the thread that started with: https://lists.debian.org/debian-user/2023/05/msg00657.html Following the upgrade to bookworm that I recently performed, I was hoping that the problem described in the first post in that thread would magically go away. It didn't :-( Felix suggested removing the nouveau driver and using "modesetting" as the driver. I have removed the nouveau driver -- or at least I thought I did -- by executing: apt-get remove xserver-xorg-video-nouveau which moved the packages: xserver-xorg-video-nouveau xserver-xorg-video-all Upon rebooting into bookworm, though, I still see the original problem, as described in the original post. If I look to see what driver is being used: [ZB:~] inxi -SGaz System: Kernel: 6.1.0-12-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-6.1.0-12-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity info: kicker wm: Twin vt: 7 dm: LightDM v: 1.26.0 Distro: Debian GNU/Linux 12 (bookworm) Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DVI-I-1,VGA-1 bus-ID: 04:00.0 chip-ID: 10de:0de1 class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting dri: nouveau gpu: nouveau display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x317mm (20.00x12.48") s-diag: 599mm (23.57") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: VGA TO HDMI built: 2013 res: 1920x1080 hz: 60 dpi: 96 gamma: 1.2 size: 509x286mm (20.04x11.26") diag: 584mm (23") ratio: 16:9 modes: max: 1920x1080 min: 640x480 API: OpenGL v: 4.3 Mesa 22.3.6 renderer: NVC1 direct-render: Yes [ZB:~] So the nouveau driver still seems to be available and in use, despite being removed. My xorg.conf file currently looks like this: [ZB:~] cat /etc/X11/xorg.conf Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 Screen 1 "Screen1" RightOf "Screen0" InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection Section "Monitor" Identifier "Monitor1" VendorName "Monitor Vendor" ModelName"Monitor Model" EndSection [54/136] Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "SWcursor" # [] #Option "HWcursor" # [] #Option "NoAccel" # [] #Option "ShadowFB" # [] #Option "VideoKey" # #Option "WrappedFB" # [] #Option "GLXVBlank" # [] #Option "ZaphodHeads" # #Option "PageFlip" # [] #Option "SwapLimit" # #Option "AsyncUTSDFS" # [] #Option "AccelMethod" # #Option "DRI" # Identifier "Card0" # Driver "nouveau" Driver "modesetting" BusID "PCI:4:0:0" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " Hz/kHz/MHz", ### : "%" ### [arg]: arg optional #Option "SWcursor" # [] #Option "kmsdev"# #Option "ShadowFB" # [] #Option "AccelMethod" #
Re: bookworm and network connections
Brian wrote on 9/2/23 04:51: Installation over ethernet, no DE - ifupdown provided. Installation over ethernet or wireless with a DE - network-manager provided. Yep, that one's exactly what I experienced. Although the machine is used more like a server than a desktop, it has DE (KDE) to make it easier on the occasions I do need to do some work on the machine. Installation over wireless without a DE - nothing provided, that is, no networking. Doc -- Web: http://enginehousebooks.com/drevans
Re: WORKAROUND (longish): was bookworm and network connections
Brian wrote on 9/2/23 13:01: Send a mail to cont...@bugs.debian.org Ib the mail body put ressign 1051086 installation-report thanks Sorry. That's "reassign". Done. Thank you. I pondered where to assign in, and couldn't see anywhere that the report really fit. (I interpreted "installation" to mean "initial installation", not "upgrade", so didn't realise that that was the right place.) Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
Michael Kjörling wrote on 9/2/23 03:23: You might want to poke around a little among the files in /etc/NetworkManager, particularly /e/NM/system-connections. That's what NetworkManager _should_ be using to set up the interfaces. See if there's something there to explain the two seemingly being intertwined. You might already have done this, of course, and if so, I apologize for pointing out something you've already tried. I hadn't before but I went and looked carefully this morning. Since I am running ZFS, I can go back and look at those files before the upgrade and see what, if anything has changed. The only change was that there is now an "ntpsec" file in /e/NM/dispatcher.d. Nothing changed anywhere else in or under /e/NM. But see a long posting that I'm about to make about all this, with a subject line containing the word "WORKAROUND". Doc -- Web: http://enginehousebooks.com/drevans
WORKAROUND (longish): was bookworm and network connections
Starting a new thread so that this doesn't get lost in the postings in the original thread. The original thread was started at: https://lists.debian.org/debian-user/2023/09/msg00024.html That post contains a description of the problem. I now have a workaround (although not an explanation) for the problem. As I noted in the above thread, once the system was up, I could get the networking to function correctly by manually entering the commands: sudo nmcli connection down "Wired connection enp11s0(eth0)" sudo nmcli connection up "Wired connection enp11s0(eth0)" However, if I put those same nmcli commands in rc.local, the problem was not resolved. After floundering for a while, and being suspicious that manual commands once the system was up were not being treated the same as the same commands in rc.local, I tried putting these lines in rc.local (whose output I log, so I can see what's happening): nmcli connection down "Wired connection enp11s0(eth0)" nmcli sleep 10 nmcli connection up "Wired connection enp11s0(eth0)" nmcli These showed that after the first command, everything looked as it should, but after the second, everything had reverted to the broken state. But it was still true that if I entered the same commands manually after the system had completed booting, the networking worked. But I'm a slow typist, and I wondered if that 10-second pause might be too short. So I changed it to 20 seconds. And lo! and behold! That worked. I tried booting numerous times with a 10-second delay, and also with a 20-second delay. The results were consistent. With a 10-second delay, the network comes up in an unusable state. With a 20-second delay, it comes up in a working state. (Which to me suggests a race condition somewhere, but I'll let the developers deal with the exact cause and finding a proper fix.) Of course, this is all just a workaround for what appears to be a problem during network initialisation in the boot process. But it does seem to work. I will file a bug report. Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
David Wright wrote on 9/1/23 19:40: I don't see that the OP is doing anything complicated that requires rc.local to run at all. They just need to distinguish between the two Correct. I was simply trying to workaround the problem by putting commands into rc.local that are known to work when I type them manually. I wish I had never mentioned rc.local. It seems to have taken over the thread, whereas it's not the problem that I'm trying to fix at all :-( Regarding the whole "Network Manager versus old-style" thing, I would gladly have done it all old style, except that when I first installed debian on the system, it went the Network Manager route. And because that all worked until today's upgrade (which was, I think, the third upgrade upgrade of debian stable on the machine; so it worked correctly for a lustrum or so), I didn't pay much attention to it apart from being mildly annoyed that it looked a lot more complicated than old-style network management. The real problem remains, per the original post, that Network Manager isn't configuring the interfaces properly and seems to be sort-of setting one interface to be the same as the other, with the result that neither of them work. I'm going to try switching to old-style when I feel confident that I have enough high-quality time to make the switch, and I expect that to work. It would be nice to really fix the Network Manager misconfiguration; but it seems that the expertise here is all with old-style. Which is fine. I'm happy to go back to old-style. I probably need to file some sort of bug report against the upgrade, but I'd like to get a better feel for how the misconfiguration is happening before I do that. Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
Michel Verdier wrote on 9/1/23 15:06: If you want old names put in /etc/default/grub GRUB_CMDLINE_LINUX="net.ifnames=0" Nice to know, but I'll stay with the new names, I think. network manager is good for changing networks. For a server the network must not change normally. So you could put configuration in /etc/network/interfaces.d/ with something like : auto enp11s0 iface enp11s0 inet static mtu 1500 metric 101 address 209.97.232.18/24 netmask 255.255.255.0 gateway 209.97.232.1 auto enp12s0 iface enp12s0 inet static mtu 1500 metric 100 address 192.168.0.1/24 netmask 255.255.0.0 When I'm feeling less tired and prone to making a mistake, I'll do this. The old method seems so much simpler, so I'd be happy to go back to it. It seems that enough people are using it that it doesn't seem likely that it'll go away anytime soon. When I installed debian on this computer -- quite a few years ago -- I'm pretty sure it just went off and installed all the Network Manager stuff without asking. And, to be honest, it's worked fine for the last several years. I can't imagine why its so messed up now. I (obviously) didn't change anything related to Network Manager myself; the upgrade is entirely responsible for its now-non-functioning state. I you want IPv6 add : iface enp11s0 inet6 auto iface enp12s0 inet6 auto I would love IPv6, but my ISP doesn't support it, and has no plans to do so, so for now I'm stuck in IPv4 land. Once it works you can then remove network manager That sounds like something to celebrate. I'll try to get time to work on all this over the weekend, and let everyone know how it turns out. Thanks to everyone for their suggestions. Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
Andy Smith wrote on 9/1/23 16:32: Your situation appears to have been triggered by the renaming of your network interfaces (which was warned about in the release These weird names like "Wired connection enp11s0(eth0)" were names that the debian installer came up with several OS versions ago (stretch, perhaps?). Anyway, they haven't changed since bullseye, when everything worked (i.e., early this morning, before I ran the upgrade :-( ). Both of these are worth reading: https://wiki.debian.org/NetworkConfiguration https://wiki.debian.org/NetworkInterfaceNames I'll take a look at those. Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
Greg Wooledge wrote on 9/1/23 15:38: In particular, when using /etc/network/interfaces, only interfaces that are marked as "auto" need to be up, to satisfy this criterion. An I don't think that debian has used used /etc/network/interfaces for a while, at least not by default. Certainly there's nothing useful there on the machine that I just upgraded and whose networking is failing to configure itself correctly. Network Manager -- I think -- uses some completely different mechanism for managing networking (although I have no idea what that mechanism is.) Doc -- Web: http://enginehousebooks.com/drevans
Re: bookworm and network connections
Thank you for your thoughts... As people are addressing the rc.local issue (I now realise that I shouldn't have mentioned it :-) )... I just checked, and: 1. rc.local is being executed; 2. it is executing the nmcli commands; 3. the commands are successful. But it remains true that when the boot is fully complete, the networking is still hosed in the way that I described. So, apparently, putting commands in rc.local doesn't provide the workaround that I expected. I think that we should concentrate on the underlying networking issue so that it comes up properly rather than being derailed by trying to fix the networking after the fact. [[ I speculate wildly that systemd or something doesn't complete configuring the network until after rc.local has finished processing (I know that rc.local executes late in the boot process, but I don't think that that means that everything else has *finished* executing when rc.local runs). I may easily be wrong, but really I don't think I care. ]] I just want to get the networking to come up properly :-) I don't understand modern systemd-controlled networking initiation well enough to know where to look for something that the upgrade might have clobbered, nor how I might go about fixing it. Doc -- Web: http://enginehousebooks.com/drevans
bookworm and network connections
I just upgraded my main server to bookworm, having successfully, over the course of the past couple of months, methodically upgraded my other machines with only minor issues. Unfortunately, the upgrade of the server, the most important of my machines, has not been smooth at all, even though no important errors appeared during the upgrade process. So right now the thing I want to fix is networking (which of course worked fine in the last few releases of debian, until now). The machine has two ethernet ports, which used to be eth0 and eth1 in the old days, but are now magically called "Wired connection enp11s0(eth0)" and "Wired connection enp12s0(eth1)". When I booted the machine after the upgrade, no networking was working at all, on either interface, even though: zserver# nmcli networking connectivity full zserver# which was definitely a lie, as nothing was successfully going in or out of the machine. Looking in more detail: [Z:~] nmcli enp12s0: connected to Wired connection enp11s0(eth0) "Intel I210" ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500 ip4 default inet4 209.97.232.18/24 route4 209.97.232.0/24 metric 100 route4 default via 209.97.232.1 metric 100 inet6 fe80::e0c1:20a:c535:873c/64 route6 fe80::/64 metric 1024 lo: connected (externally) to lo "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 inet4 127.0.0.1/8 inet6 ::1/128 enp11s0: disconnected "Intel I210" 1 connection available ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500 enp13s0: unavailable "Intel I210" ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500 enp14s0: unavailable "Intel I210" ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500 DNS configuration: servers: 127.0.0.1 209.97.224.2 209.97.224.3 interface: enp12s0 Somehow, it had got into a state where enp12s0 was connected to enp11s0 (whatever that means), with the result that nothing worked. So, after a bit of messing around with an increasing sense of desperation, I discovered that: [Z:~] sudo nmcli connection down "Wired connection enp11s0(eth0)" Connection 'Wired connection enp11s0(eth0)' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) [Z:~] sudo nmcli connection up "Wired connection enp11s0(eth0)" Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4) resulted in: [Z:~] nmcli enp11s0: connected to Wired connection enp11s0(eth0) "Intel I210" ethernet (igb), D8:50:E6:C2:76:02, hw, mtu 1500 ip4 default inet4 209.97.232.18/24 route4 209.97.232.0/24 metric 101 route4 default via 209.97.232.1 metric 101 inet6 fe80::1ae1:dfcf:be36:f72f/64 route6 fe80::/64 metric 1024 enp12s0: connected to Wired connection enp12s0(eth1) "Intel I210" ethernet (igb), D8:50:E6:C2:76:03, hw, mtu 1500 inet4 192.168.0.1/24 route4 192.168.0.0/24 metric 100 inet6 fe80::d30e:86f6:ca86:8986/64 route6 fe80::/64 metric 1024 lo: connected (externally) to lo "lo" loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536 inet4 127.0.0.1/8 inet6 ::1/128 enp13s0: unavailable "Intel I210" ethernet (igb), D8:50:E6:C2:76:04, hw, mtu 1500 enp14s0: unavailable "Intel I210" ethernet (igb), D8:50:E6:C2:76:05, hw, mtu 1500 DNS configuration: servers: 127.0.0.1 209.97.224.2 209.97.224.3 interface: enp11s0 and indeed, everything was now working. Which was good, because I was running out of ideas, and had no way to reach the Internet to look for more help. Well, great, sort-of, except that every time I reboot I have to manually issue the two above nmcli commands to take down and bring back up enp11s. I tried putting them in my rc.local file, but that had no effect (for reasons that I don't understand; I was sure that that would paper over the problem). So how do I fix this so that the networking is configured to work correctly during the boot sequence, as it has always done before? (I suppose it has to be said explicitly: I did not change any configuration files ... indeed, these days I don't even know where the files are that control the network devices.) All the other machines that I have upgraded to bookworm have only a single ethernet port, which may be why I have not seen this issue after any other upgrade. Doc -- Web: http://enginehousebooks.com/drevans
Re: Transport endpoint is not connected
Greg Wooledge wrote on 7/5/23 08:59: I'm still waiting for setup details to be provided. Is "sh" the user's I was merely trying to inform the OP that he wasn't alone in seeing this "Transport endpoint is not connected" message coming from bookworm when prior versions of debian stable were silent when performing the same activity. I wasn't actually seeking help -- if I had've been, I would have made some attempt to get to the bottom of the problem first, and then provided complete details here if I were unable to fix it myself. None of that seemed worthwhile just for a message that doesn't seem to be indicating a real problem. So you were going beyond my expectations when you attempted to help, and I'm sorry for the miscommunication. Doc -- Web: http://enginehousebooks.com/drevans
Re: Transport endpoint is not connected
to...@tuxteam.de wrote on 7/4/23 22:23: FWIW, since upgrading to bookworm, I see: sh: 0: getcwd() failed: Transport endpoint is not connected when I ssh into the upgraded box. This seems to be coming from getcwd() (aka get current working directory, see man page). Asking the intertubes, it seems to happen often when it or its ancestors are mounted over FUSE. This is a plain ol' ssh login, so I don't think that FUSE is involved. I have no idea why. (And, just to be clear, this has never happened before, through many releases of debian stable.) I'm assuming, for now, that: 1. I can use the box as usual despite the message; 2. the problem will be fixed at some point soon. I haven't seen any other obvious problems if I proceed to use the ssh session as normal. Are you able to access all the directories you expect to? How is, e.g. the user's $HOME mounted? Its parent? Yep... can't see any unusual behaviour at all. So far, anyway. If I get some time, I'll try to figure out exactly where and why it's happening; but at this point, since it never happened before in 15 years of sshing into the box and there seems to be no obvious consequences other than the appearance of the message at login, I'm assuming there's nothing really wrong and it's some bug -- probably a race condition, perhaps involving systemd, since that seems to have a history of them -- introduced in bookworm that will get fixed fairly quickly. Doc -- Web: http://enginehousebooks.com/drevans
Re: Transport endpoint is not connected
hlyg wrote on 6/28/23 21:32: notification message: Transport endpoint is not connected FWIW, since upgrading to bookworm, I see: sh: 0: getcwd() failed: Transport endpoint is not connected when I ssh into the upgraded box. I have no idea why. (And, just to be clear, this has never happened before, through many releases of debian stable.) I'm assuming, for now, that: 1. I can use the box as usual despite the message; 2. the problem will be fixed at some point soon. I haven't seen any other obvious problems if I proceed to use the ssh session as normal. Doc -- Web: http://enginehousebooks.com/drevans
Re: video issue following latest bullseye update
I'm sorry I'm so slow to respond... it's all a matter of trying to put aside quality uninterruptible time to work on this. Since the problem is not so bad that I can't perform work with this computer, a lot of other work-related things unfortunately have to take priority. Felix Miata wrote on 5/23/23 13:26: I currently get: [ZB:~] sudo inxi -GSaz System:Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity R14.1.1~[DEVELOPMENT] tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: LightDM 1.26.0 The line wrapping suggests you never succeeded to do "inxi -U". As seen below, The officially supported version of inxi on bullseye [inxi 3.3.01-00 (2021-02-08), according to "inxi --version"] seems to have "-U" disabled. Which I guess makes sense. Are all users of ZFS supposed to include two root= parameters on their linu lines? What an excellent question. I don't know for sure, but I suspect that it's related to the fact that I am running root-on-ZFS (i.e., the / filesystem is on a ZFS disk). It's been like that for many years on this machine, and I believe that when I first installed root-on-ZFS, the instructions told me to do that. FWIW, I have another root-on-ZFS system, and it also has two "root=" parameters. But I am still seeing the original problem I reported. Could it be that your PC doesn't like LightDM? Try switching to TDM. All my TDM has never worked properly on this machine; TDM doesn't correctly figure out which video card to use (at least, it didn't last time I tried it), so it presents me with a black screen, leaving me having to ssh into the machine and reconfigure it to use LightDM. Debians use it only. I also use TDM to run Plasma on Leap and Tumbleweed. I switched from the modesetting DIX driver to the nouveau DDX driver via: # cat /etc/X11/xorg.conf.d/15-ddxdrv.conf #Section "OutputClass" Section "Device" Identifier "DDX" # MatchDriver "amdgpu" # Driver "amdgpu" # MatchDriver "intel" # Driver "intel" # MatchDriver "modesetting" # Driver "modesetting" # MatchDriver "nouveau" Driver "nouveau" # MatchDriver "radeon" # Driver "radeon" EndSection I was unable to detect any kind of video corruption in the TDE 14.1.x relnotes window, or doing what follows in TDE's Konsole: I don't think it can be a TDE issue, as the same problem exists on this machine if I run the official KDE that is currently in bullseye. I suppose your issue could involve a timing coincidence, and your problem may be failing gfxcard RAM. I suppose anything is possible. But since this began as soon as I applied a bullseye update, it seems much more likely that it's a nouveau issue that landed on this machine when I performed the update. The modesetting DIX is newer technology than the reverse-engineered, "experimental" nouveau DDX. Whatever happened when you attempted switching to the DIX should not have happened. Do you have /etc/X11/xorg.conf or any content in /etc/X11/xorg.conf.d/ directed to gfx (device, monitor, screen, driver) other than the file I suggested? Here is xorg.conf (which I believe was auto-created at some point; I have no notes that say that I created it): [ZB:X11] cat xorg.conf | pastebinit https://paste.debian.net/1281598/ [ZB:X11] And /etc/X11/xorg.conf.d/ just contains the file you suggested (currently set to nouveau): [ZB:xorg.conf.d] ls -al total 11 drwxr-xr-x 2 root root 3 May 22 14:46 . drwxr-xr-x 14 root root 25 Nov 9 2021 .. -rw-r--r-- 1 root root 88 May 22 14:46 50-device.conf [ZB:xorg.conf.d] cat * Section "Device" Identifier "DDX" # Driver "modesetting" Driver "nouveau" EndSection [ZB:xorg.conf.d] Doc -- Web: http://enginehousebooks.com/drevans
Re: video issue following latest bullseye update
Felix Miata wrote on 5/19/23 11:23: How much time did you allow the login screen to show up? I've lately seen on Somewhere between three and five minutes, I'd say. Certainly long after the disk light stopped flickering and the system seemed to have reached a stable state. systemctl restart OK; so that would be: systemctl restart lightdm Useful to know; thank you. I reinstalled xserver-xorg-video-nouveau from the console, and (fortunately) when I rebooted LDM came up as usual and I was able to log in as I normally do. Obviously, the original issue still exists, but at least I got a graphical display back. If by that you mean back to 640x480 or 800x600 instead of your display's native No; I didn't mean that. Sorry I wasn't clear. I meant that after reinstalling xserver-xorg-video-nouveau and rebooting, everything looked the way it did before I removed xserver-xorg-video-nouveau, so I was back exactly to what I was seeing when I first started this thread. [1] Instead of driver removal/reinstallation, create file, or add following content to existing file: /etc/X11/xorg.conf.d/50-device.conf Section "Device" Identifier "DDX" Driver "modesetting" # Driver "nouveau" EndSection I have created that file, with those contents: [ZB:~] cat /etc/X11/xorg.conf.d/50-device.conf Section "Device" Identifier "DDX" Driver "modesetting" # Driver "nouveau" EndSection [ZB:~] Do you really mean "DDX", not "DIX"? < I made the edit according to your instructions (i.e., "DDX") but I'm not certain that your e-mail didn't contain a typo. By simply moving the # to the other driver line, you can easily switch between using the two display drivers by restarting your DM or rebooting. Right now, the 50-device.conf file looks exactly as it does above but, and I have restarted lightdm by issuing: systemctl restart lightdm from the console. I currently get: [ZB:~] sudo inxi -GSaz System:Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity R14.1.1~[DEVELOPMENT] tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: LightDM 1.26.0 Distro: Debian GNU/Linux 11 (bullseye) Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau v: kernel bus ID: 04:00.0 chip ID: 10de:0de1 class ID: 0300 Display: server: X.Org 1.20.11 driver: loaded: nouveau unloaded: modesetting display ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9") Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 96 size: 509x286mm (20.0x11.3") diag: 584mm (23") OpenGL: renderer: NVC1 v: 4.3 Mesa 20.3.5 direct render: Yes But I am still seeing the original problem I reported. [I also did a test, just to prove to myself that what I'm seeing isn't due to some weird monitor problem (it's a pretty new monitor, and I wanted to be sure that somehow I hadn't just missed seeing the problem before I performed the update -- even though the issue is so obvious that I can't really believe that I wouldn't have noticed it before). I took a screenshot of a screen display that exhibited the problem (a konqueror file listing), and copied the file to another system that is attached to the same KVM switch. When I display the screenshot image in this, my normal desktop system, I see the problem; when I look at the same image file on my other system -- which has NOT had the recent update applied -- the problem is absent, even though I'm viewing it on the very same monitor. So I am as sure as I can be that, as I believed, the recent bullseye update led to the issue.] Doc -- Web: http://enginehousebooks.com/drevans
Re: video issue following latest bullseye update
Felix Miata wrote on 5/15/23 13:25: Try using the (default) modesetting DIX display driver instead of Nouveau. Remove package xserver-xorg-video-nouveau and reboot to see if it makes a difference. I did this, and when I rebooted I was in the Linux console instead of Light DM (which is my display manager). Hitting ctrl-alt-F7 to go to the X screen did not show me the LDM login screen, or any other X screen, but instead another non-graphical screen. I reinstalled xserver-xorg-video-nouveau from the console, and (fortunately) when I rebooted LDM came up as usual and I was able to log in as I normally do. Obviously, the original issue still exists, but at least I got a graphical display back. Doc -- Web: http://enginehousebooks.com/drevans
Re: video issue following latest bullseye update
Felix Miata wrote on 5/15/23 13:25: Try using the (default) modesetting DIX display driver instead of Nouveau. Remove package xserver-xorg-video-nouveau Synaptic is telling me that this will also remove: xserver-xorg-video-all Is it OK that that will also be removed? Doc -- Web: http://enginehousebooks.com/drevans
Re: video issue following latest bullseye update
Felix Miata wrote on 5/15/23 11:16: D. R. Evans composed on 2023-05-15 09:49 (UTC-0600): I'm wondering if someone can walk me through how to figure out what video driver I am using, and what other drivers might be available to try? Not without knowing anything about your GPU: Yes, I figured that that would be the first step; I didn't know how to do that either, so thanks for taking my "walk me through" request seriously. sudo sed -i 'a/^B_ALLOW_UPDATE/#B_ALLOW_UPDATE/g' /etc/inxi.conf # just doit inxi -SGaz # paste into your reply [ZB:tmp] inxi -SGaz System:Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-23-amd64 root=ZFS=/ROOT/debian ro root=ZFS=rpool/ROOT/debian Desktop: Trinity info: kicker wm: Twin dm: LightDM 1.26.0 Distro: Debian GNU/Linux 11 (bullseye) Graphics: Device-1: NVIDIA GF108 [GeForce GT 430] vendor: Gigabyte driver: nouveau v: kernel bus ID: 04:00.0 chip ID: 10de:0de1 class ID: 0300 Display: x11 server: X.Org 1.20.11 driver: loaded: nouveau unloaded: modesetting display ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9") Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 96 size: 509x286mm (20.0x11.3") diag: 584mm (23") OpenGL: renderer: NVC1 v: 4.3 Mesa 20.3.5 direct render: Yes [ZB:tmp] FYI, the actual physical size of the monitor is quite a lot larger than the 23" reported in the output above. I don't suppose that that matters, but I noticed that the numbers are wrong, so I thought I'd better mention it. The actual diagonal size of the monitor is ~32". cat /var/log/Xorg.0.log | pastebinit # provide resulting URL in reply https://paste.debian.net/1280303/ Thank you. Doc -- Web: http://enginehousebooks.com/drevans
video issue following latest bullseye update
Following an update this morning to one of my bullseye systems, an irritating video problem has surfaced. The best way I can think of to describe the problem is that if one has a line of black text on what is supposed to be a white background, to the right of the text a clear, short tail of even whiter background is visible (the tail is maybe an inch or so long). The update was to: Linux 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux I suspect that this is due to a driver issue related to the update. (I have tried a couple of different desktops, KDE and TDE, but they both exhibit the problem, so I don't think it can be caused by the desktop software. The problem did not exist prior to this morning's update.) So I'm wondering if someone can walk me through how to figure out what video driver I am using, and what other drivers might be available to try? Doc -- Web: http://enginehousebooks.com/drevans
Thunderbird and font size used to display plain text e-mails?
I have looked everywhere I can think of, and have been unable to find an answer -- among the ridiculous number of ways that fonts appear to be controlled in Thunderbird -- that works for this issue :-( I recently changed to a larger monitor, and, after lots of twiddling, have more-or-less got most programs looking reasonably sensible. But Thunderbird is being recalcitrant. I am using TB 102.10.0, which is the current version in the debian stable repositories, on 64-bit debian stable. Here is the issue: When I open TB, I see three panes: one runs the full height of the TB window, and is on the left of the screen. It contains a list of the TB e-mail folders. The remaining space is divided into two panes, one vertically above the other. The second pane, the top one of these two, shows the subjects of received e-mails in whatever folder is selected in the first pane. The third pane, below the second one, is where the contents of e-mails are displayed. I have TB configured so as to display incoming e-mail as plain text. They display correctly, BUT the font used to display the contents in the third pane is too large on the new monitor. How *exactly* do I control the size of the font used to display the contents of received plain text e-mails? That is: -- | | | | | | | | | | |-| | | | <- how to control font size | | | <- in this pane?? -- Doc -- Web: http://enginehousebooks.com/drevans
Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?)
hw wrote on 11/9/22 04:41: configure the controller cards, so that won't really work. And ZFS with Linux isn't so great because it keeps fuse in between. That isn't true. I've been using ZFS with Debian for years without FUSE, through the ZFSonLinux project. The only slightly discomforting issue is that it's not officially supported on Debian because of a perceived license conflict. Doc -- Web: http://enginehousebooks.com/drevans
Re: issue with purging an old kernel
DdB wrote on 6/20/22 10:07: Since i am running dozens of VM's, i can say: Me2 am running into this regularly, when i am trying to purge old kernels. I am seeing this so frequently, that i even wrote a script (meant to be run inside the VM's) to clean up the mess, some apt-scripts happen to leave behind. It's comforting to know that this seems to be a relatively common occurrence (although this is the first time I've run into it, and I've been running debian for maybe seven or eight years at this point). As far as I know I have only official debian stable packages on the system, so it has the flavour of a minor packaging bug somewhere. Anyway, I'm not going to worry about it, given that you see it so often. I have cleared out the offending directory and moved on. Thanks to you and the other posters for responding. Doc -- Web: http://enginehousebooks.com/drevans
issue with purging an old kernel
Normally to remove an old kernel from my debian stable systems, I issue the following command: apt purge linux-headers--amd64 linux-headers--common linux-image--amd64 Following this recipe, which has always worked in the past, I issued: apt purge linux-headers-5.10.0-11-amd64 linux-headers-5.10.0-11-common linux-image-5.10.0-11-amd64 But it failed, with the error message: Purging configuration files for linux-image-5.10.0-11-amd64 (5.10.92-2) ... rmdir: failed to remove '/lib/modules/5.10.0-11-amd64': Directory not empty dpkg: warning: while removing linux-image-5.10.0-11-amd64, directory '/lib/modules/5.10.0-11-amd64' not empty so not removed If I look in the named directory, I see: root@zbrew:~# ls -al /lib/modules/5.10.0-11-amd64 total 35 drwxr-xr-x 3 root root 3 Jun 20 08:49 . drwxr-xr-x 7 root root 7 Jun 17 07:08 .. drwxr-xr-x 2 root root 2 Apr 25 07:53 misc and the directory /lib/modules/5.10.0-11-amd64/misc turns out to be empty. So it seems reasonable to remove /lib/modules/5.10.0-11-amd64/misc/ manually and re-execute the purge command. But before I try that, I'm puzzled as to how this situation could have arisen. Has anyone else seen this happen, and does anyone have a reasonable suggestion as to how it could have occurred? Doc -- Web: http://enginehousebooks.com/drevans
[SOLVED] Re: postfix + gmail
And, of course, half an hour after giving up and asking for help, I discovered what I needed to change. I did a "journalctl | grep smtp" and noticed that, when my machine was connecting to gmail, it seemed to be doing so on port 25. Aha! So I changed my transport file explicitly to use port 587 when connecting to smtp.googlemail.com, reloaded everything and now it works. (Slightly in my defence, I had briefly pondered the question of port number earlier this morning, but, since I hadn't seem any mention of it in my reading of solutions to this problem, I figured that the fact that I had enabled auth in the main.cf file must mean that postfix was automagically going to use port 587 instead of port 25. Now I know better.) Doc -- Web: http://enginehousebooks.com/drevans
postfix + gmail
I am trying to configure postfix correctly to send e-mail to a gmail.com account, using my gmail credentials. 1. It all works fine if I use Thunderbird, with the following configuration: server name: smtp.googlemail.com port:587 Connection security: STARTTLS Authentication method: normal password username: doc.ev...@gmail.com and the password set to my gmail password. That, in fact, is the method that I am using to post this e-mail to the reflector. 2. But when I try to duplicate that with postfix, I receive the following error: : host smtp.googlemail.com[142.250.138.16] said: 530-5.7.0 Authentication Required. Learn more at 530 5.7.0 https://support.google.com/mail/?p=WantAuthError e12-20020a9d490c00b0060b6facd5e4sm4170514otf.29 - gsmtp (in reply to MAIL FROM command) I have spent most of the morning following various Internet threads related to this error, and making many variations to my postfix configuration, but without success. FWIW, here are the relevant parts of my current postfix configuration, and it generates the error message quoted above (I am running debian stable): in main.cf: smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd smtp_sasl_security_options = smtp_sasl_type = cyrus smtp_use_tls = yes smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt in sasl_passwd: [smtp.googlemail.com]:587 doc.ev...@gmail.com: I did check that the password matches exactly the password in Thunderbird. So if some postfix guru could enlighten me as to what I need to change, I'd be very grateful. Doc -- Web: http://enginehousebooks.com/drevans
Re: Start ZFS partition on boot.
James Allsopp wrote on 3/18/22 15:20: I'm having lots of trouble starting my zfs /var partition as part of boot, I urge you to post the question on the zfs-discuss reflector. Doc -- Web: http://enginehousebooks.com/drevans
Re: jupyter-notebook and bullseye
Reco wrote on 12/31/21 1:47 PM: That was certainly a help (although I wonder why it was necessary for me to do that manually), It's official Debian policy now, believe it or not. python 2.x is /usr/bin/python2. python 3.x is /usr/bin/python3. If the user really wants /usr/bin/python the user should install python-is-python2 or python-is-python3. And these two packages conflict with each other. Once upon a time, not really that long ago, Debian seemed to make very sensible decisions to keep everything stable and working across upgrades. In the past few years, however, I find myself shaking my head and wondering "what were they thinking?" It's not that some of the things they've done are necessarily *wrong* per se, but they have certainly been a lot more experimental than one wants in an environment that one expects to keep working properly across upgrades; it seems that somehow the importance of keeping the users' systems functioning as one hopes they will is now a much lower priority than it used to be. but ultimately I am still unable to do anything. I'm not familiar with jupyter and I'm not using it. Pretty wise; I think. I was sucked in a bit about the hype that surrounds it and put in quite a bit of effort to build some useful notebooks a few years ago. But now I find that it's pretty much like the majority of experiments I've tried over the years: it looks nifty, and doubtless some people find it useful, but for me it's too fragile and ultimately the cost in time isn't worth the possible benefit. But it certainly would be nice to at least be able to use my old jupyter notebooks, even if it's unlikely that I'll create any new ones. Judging from [1], you're required to reinstall all these "jupyter kernels", because what you have was installed for python2, but what you need is to install them for python3. But then again, I could be wrong. Sorry, cannot help you further. That's probably a good bet. I don't remember how any of those kernels got installed [I thought that all except the sos kernel were from debian repositories, but my memory might be faulty], so I'll have to search around and see what I can dig up. The evidence to hand does seem to suggest that they don't auto-upgrade and therefore need to be upgraded manually somehow. Thank you for taking the time to share your thoughts, especially as you don't use jupyter yourself. Doc -- Web: http://enginehousebooks.com/drevans
Re: jupyter-notebook and bullseye
Reco wrote on 12/17/21 6:10 AM: Hi. On Thu, Dec 16, 2021 at 12:43:51PM -0700, D. R. Evans wrote: FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python' ... Can someone suggest how I might get back to the fully-working set of kernels that I had in buster? Try this: apt install python-is-python3 Thank you very much. That was certainly a help (although I wonder why it was necessary for me to do that manually), but ultimately I am still unable to do anything. "jupyter kernelspec list" now looks better: [ZB:jupyter] jupyter kernelspec list Available kernels: ir /home/n7dr/.local/share/jupyter/kernels/ir markdown/home/n7dr/.local/share/jupyter/kernels/markdown bash/usr/local/share/jupyter/kernels/bash gnuplot /usr/local/share/jupyter/kernels/gnuplot sos /usr/local/share/jupyter/kernels/sos python3 /usr/share/jupyter/kernels/python3 [ZB:jupyter] But if I actually run jupyter-notebook on a known-good .ipynb file I get the following: [ZB:jupyter] jn CQ* [I 13:22:37.809 NotebookApp] Loading IPython parallel extension [I 13:22:37.824 NotebookApp] Serving notebooks from local directory: /home/n7dr/notebooks/jupyter [I 13:22:37.824 NotebookApp] Jupyter Notebook 6.2.0 is running at: [I 13:22:37.824 NotebookApp] http://localhost:/?token=5e06127359465bc598e53eb5b48ef202592e96e3a1fe4ba7 [I 13:22:37.824 NotebookApp] or http://127.0.0.1:/?token=5e06127359465bc598e53eb5b48ef202592e96e3a1fe4ba7 [I 13:22:37.825 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). [C 13:22:42.319 NotebookApp] To access the notebook, open this file in a browser: file:///home/n7dr/.local/share/jupyter/runtime/nbserver-2497406-open.html Or copy and paste one of these URLs: http://localhost:/?token=5e06127359465bc598e53eb5b48ef202592e96e3a1fe4ba7 or http://127.0.0.1:/?token=5e06127359465bc598e53eb5b48ef202592e96e3a1fe4ba7 [W 13:22:50.477 NotebookApp] 404 GET /nbextensions/widgets/notebook/js/extension.js?v=20211231132234 (127.0.0.1) 96.38ms referer=http://localhost:/notebooks/CQ%20WW.ipynb [I 13:22:51.078 NotebookApp] 302 GET /notebooks/activity-160.png (127.0.0.1) 0.67ms [I 13:22:51.171 NotebookApp] 302 GET /notebooks/2017-ALL.png (127.0.0.1) 0.61ms [I 13:22:51.394 NotebookApp] 302 GET /notebooks/cq-ww-qso-nlogs-a-u.png (127.0.0.1) 0.62ms [I 13:22:51.456 NotebookApp] 302 GET /notebooks/cq-ww-qso-percentiles.png (127.0.0.1) 0.64ms [I 13:22:51.576 NotebookApp] Kernel started: 9636f23d-6e5c-4ce6-931a-f0844f8876e5, name: bash /usr/bin/python: No module named bash_kernel [I 13:22:54.576 NotebookApp] KernelRestarter: restarting kernel (1/5), new random ports /usr/bin/python: No module named bash_kernel [I 13:22:57.590 NotebookApp] KernelRestarter: restarting kernel (2/5), new random ports /usr/bin/python: No module named bash_kernel [I 13:23:00.598 NotebookApp] KernelRestarter: restarting kernel (3/5), new random ports /usr/bin/python: No module named bash_kernel [I 13:23:03.605 NotebookApp] KernelRestarter: restarting kernel (4/5), new random ports /usr/bin/python: No module named bash_kernel [W 13:23:06.621 NotebookApp] KernelRestarter: restart failed [W 13:23:06.621 NotebookApp] Kernel 9636f23d-6e5c-4ce6-931a-f0844f8876e5 died, removing from map. [W 13:23:12.691 NotebookApp] Replacing stale connection: 9636f23d-6e5c-4ce6-931a-f0844f8876e5:1820effccd3749579998b085be46704b [W 13:23:34.746 NotebookApp] Replacing stale connection: 9636f23d-6e5c-4ce6-931a-f0844f8876e5:1820effccd3749579998b085be46704b [W 13:23:51.683 NotebookApp] Timeout waiting for kernel_info reply from 9636f23d-6e5c-4ce6-931a-f0844f8876e5 [E 13:23:51.686 NotebookApp] Error opening stream: HTTP 404: Not Found (Kernel does not exist: 9636f23d-6e5c-4ce6-931a-f0844f8876e5) [W 13:23:51.689 NotebookApp] 404 GET /api/kernels/9636f23d-6e5c-4ce6-931a-f0844f8876e5/channels?session_id=1820effccd3749579998b085be46704b (127.0.0.1): Kernel does not exist: 9636f23d-6e5c-4ce6-931a-f0844f8876e5 [W 13:23:51.690 NotebookApp] 404 GET /api/kernels/9636f23d-6e5c-4ce6-931a-f0844f8876e5/channels?session_id=1820effccd3749579998b085be46704b (127.0.0.1) 39005.31ms referer=None [W 13:23:51.690 NotebookApp] 404 GET /api/kernels/9636f23d-6e5c-4ce6-931a-f0844f8876e5/channels?session_id=1820effccd3749579998b085be46704b (127.0.0.1): Kernel does not exist: 9636f23d-6e5c-4ce6-931a-f0844f8876e5 [W 13:23:51.691 NotebookApp] 404 GET /api/kernels/9636f23d-6e5c-4ce6-931a-f0844f8876e5/channels?session_id=1820effccd3749579998b085be46704b (127.0.0.1) 16950.43ms referer=None [W 13:23:55.701 NotebookApp] Replacing stale connection: 9636f23d-6e5c-4ce6-931a-f0844f8876e5:1820effccd3749579998b085be46704b [W 13:24:23.733 NotebookApp] Replacing stale connection: 9636f23d-6e5c-4ce6-931a-f0844f8876e5:1820effccd3749579998b085be46704b And in the brow
jupyter-notebook and bullseye
I don't use jupyter-notebook often, so I only just discovered that I am encountering a problem with it following my upgrade from buster to bullseye a couple of months ago. It worked fine on buster, and I have changed nothing related to jupyter since the upgrade. When jupyter-notebook starts the browser, I see a big red "kernel error" button, and when I press it, the following pops up: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/tornado/web.py", line 1704, in _execute result = await result File "/usr/lib/python3/dist-packages/tornado/gen.py", line 769, in run yielded = self.gen.throw(*exc_info) # type: ignore File "/usr/lib/python3/dist-packages/notebook/services/sessions/handlers.py", line 69, in post model = yield maybe_future( File "/usr/lib/python3/dist-packages/tornado/gen.py", line 762, in run value = future.result() File "/usr/lib/python3/dist-packages/tornado/gen.py", line 769, in run yielded = self.gen.throw(*exc_info) # type: ignore File "/usr/lib/python3/dist-packages/notebook/services/sessions/sessionmanager.py", line 88, in create_session kernel_id = yield self.start_kernel_for_session(session_id, path, name, type, kernel_name) File "/usr/lib/python3/dist-packages/tornado/gen.py", line 762, in run value = future.result() File "/usr/lib/python3/dist-packages/tornado/gen.py", line 769, in run yielded = self.gen.throw(*exc_info) # type: ignore File "/usr/lib/python3/dist-packages/notebook/services/sessions/sessionmanager.py", line 100, in start_kernel_for_session kernel_id = yield maybe_future( File "/usr/lib/python3/dist-packages/tornado/gen.py", line 762, in run value = future.result() File "/usr/lib/python3/dist-packages/notebook/services/kernels/kernelmanager.py", line 176, in start_kernel kernel_id = await maybe_future(self.pinned_superclass.start_kernel(self, **kwargs)) File "/usr/lib/python3/dist-packages/jupyter_client/multikernelmanager.py", line 185, in start_kernel km.start_kernel(**kwargs) File "/usr/lib/python3/dist-packages/jupyter_client/manager.py", line 313, in start_kernel self.kernel = self._launch_kernel(kernel_cmd, **kw) File "/usr/lib/python3/dist-packages/jupyter_client/manager.py", line 222, in _launch_kernel return launch_kernel(kernel_cmd, **kw) File "/usr/lib/python3/dist-packages/jupyter_client/launcher.py", line 134, in launch_kernel proc = Popen(cmd, **kwargs) File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/lib/python3.9/subprocess.py", line 1823, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python' - It is certainly true that that file does not exist, but something is obviously telling jupyter to look for it. So something about the jupyter configuration seems to have been hosed by the upgrade. The command "jupyter kernelspec list" produces: [ZB:~] jupyter kernelspec list -bash: /home/n7dr/.local/bin/jupyter: /usr/bin/python: bad interpreter: No such file or directory [ZB:~] In buster I had perhaps half a dozen kernels available (and they all worked). Can someone suggest how I might get back to the fully-working set of kernels that I had in buster? Doc -- Web: http://enginehousebooks.com/drevans
Re: bullseye and running graphics over ssh
Greg Wooledge wrote on 10/7/21 2:21 PM: On Thu, Oct 07, 2021 at 02:15:45PM -0600, D. R. Evans wrote: For years (decades, actually) I have routinely executed graphical programs over ssh (i.e., I sit at computer A, ssh into computer B, then run a graphical program on computer B whose windows, mouse events, etc., all occur on computer A). In bullseye, at least out-of-the-box bullseye, this suddenly no longer works. You should have been using "ssh -X B" all along to get this functionality. Your previous system A must have had ssh_config (or your personal .ssh/config) set up to turn on X11 forwarding by default, which is not recommended. That's interesting... ssh_config was overwritten. Normally when a config file I've altered is overwritten during an upgrade, I expect to be told and to be given a chance to do something sensible -- and that didn't happen in the case of the global ssh configuration file. But indeed, comparing the bullseye ssh_config to the one I had in buster, I see that ForwardX11 has changed back to "no" whereas I had forced it to "yes" in buster. You're right that making that change in the global config file was bad practice, so this time I've left the global ssh_config unchanged from the default and added an explicit ForwardX11 yes to the entry for the destination host in ~/.ssh/config. So nothing to do with Wayland. Thanks for putting me straight and saving me a lot of frustration. Doc -- Web: http://enginehousebooks.com/drevans
bullseye and running graphics over ssh
For years (decades, actually) I have routinely executed graphical programs over ssh (i.e., I sit at computer A, ssh into computer B, then run a graphical program on computer B whose windows, mouse events, etc., all occur on computer A). In bullseye, at least out-of-the-box bullseye, this suddenly no longer works. I have bullseye running on both computers. The first indication of a problem is immediately when I log in via ssh. I now see: xrdb: Can't open display '' as part of the login process. The cause seems to be the line: xrdb -load ~/.Xresources in .bashrc. For some reason that no longer works as it has in the past. And this seems to be because the DISPLAY variable hasn't been set. I really don't understand what's going on, because this has worked forever. And naturally, since DISPLAY isn't set, nothing else works. Can someone point me to some instructions as to how to fix all this? I suspect it's all to do with Wayland suddenly becoming the default. But I can't find any way to STOP bullseye using Wayland and forcing it to revert to the X that I've known since the 1990s. There must be some way either to get X working over Wayland or to remove Wayland until it properly supports X sessions unobtrusively; but I can't find it. Doc -- Web: http://enginehousebooks.com/drevans
Re: failed upgrade buster -> bullseye
D. R. Evans wrote on 10/4/21 4:36 PM: D. R. Evans wrote on 10/4/21 4:12 PM: I just tried to upgrade my main desktop machine (this machine) from buster to bullseye. I am suspicious that the problem is related to having root on ZFS on this machine. So I have posted a request for help on the zfsonlinux reflector, and probably it would be best if no one here spent much (or any) time thinking about the problem unless/until I am satisfied that the issue is unrelated to ZFS. Indeed, the problem seems to have been caused by using root on ZFS. Running bullseye here now. Doc -- Web: http://enginehousebooks.com/drevans
Re: failed upgrade buster -> bullseye
D. R. Evans wrote on 10/4/21 4:12 PM: I just tried to upgrade my main desktop machine (this machine) from buster to bullseye. I am suspicious that the problem is related to having root on ZFS on this machine. So I have posted a request for help on the zfsonlinux reflector, and probably it would be best if no one here spent much (or any) time thinking about the problem unless/until I am satisfied that the issue is unrelated to ZFS. Doc -- Web: http://enginehousebooks.com/drevans
failed upgrade buster -> bullseye
I just tried to upgrade my main desktop machine (this machine) from buster to bullseye. The upgrade halted with: ... Setting up libgnustep-base1.27 (1.27.0-3) ... Processing triggers for shared-mime-info (2.0-1) ... Setting up gnustep-base-runtime (1.27.0-3) ... Setting up unar (1.10.1-2+b6) ... Errors were encountered while processing: linux-image-5.10.0-8-amd64 linux-image-amd64 Sub-process /usr/bin/dpkg returned an error code (1) I have no idea what to do (other than to refrain from rebooting and hope that I don't lose power for so long that the UPS dies). How do I start to find and fix the problem??? I do have a script record of the entire upgrade. It's about 6MB in length. Doc -- Web: http://enginehousebooks.com/drevans
Re: Debian stable - updates
Christian wrote on 6/25/21 6:19 AM: Is Debian stable safe to use - I mean in the sense that it gets security updates for the installed packages? Yes, it does get security updates. It also gets non-security updates for some of the most popular packages. For years I have run debian stable on my main desktop machine (the one I am using to type this e-mail). It has had fewer major issues than any other distribution I have tried. Doc Evans -- Web: http://enginehousebooks.com/drevans
Re: TDE (Trinity Desktop Environment) vs KDE
Andrew M.A. Cater wrote on 4/22/21 2:57 PM: On Thu, Apr 22, 2021 at 04:23:02PM -0400, Kenneth Parker wrote: I saw TDE discussed in another, recent Thread, and had to look it up, as I am not familiar with it. How does it compare with the current KDE? Other than a qemu VM with KDE (so that I can examine it), I haven't used KDE in years (using XFCE for most of my systems, but with one current Gnome Desktop). Is it worth using *instead* of KDE, or would that throw me into a mess? I use TDE as my desktop on my main [debian stable, 64-bit] machine for real work; I gave up waiting for the KDE coders to reimplement some functionality that was lost when they switched to KDE4 (and then KDE5, or whatever it's called nowadays). I also have KDE installed on the machine, for the very few occasions when I find that the KDE5 version of a program has something that I need and which is not in TDE -- that happens so rarely that off the top of my head I can't even think of an example, but I know that it has happened; but I believe that it's always been in the nature of fluff/candy, not core functionality. And in fact even then I don't run the KDE desktop, but just run the KDE version of a program instead of the TDE version. FWIW, the biggest reason I switched to TDE was the lack of support in KDE for displaying in the panel sysguard widgets that obtain data from remote systems. In my panel I have widgets reporting on the health of other machines... and those other machines are running KDE (because I interact with their desktops so infrequently that it wasn't worth installing a different desktop on them). I will also say that the modern KDE look, with its rather astonishing amount of wasted space, was not to my taste, although that was not the principal reason why I installed TDE. The biggest two annoyances I find in TDE as compared to KDE are both in Konqueror: a) the display of directories does not continually renew on changes; b) when displaying image files, the images are not scaled down to fit within the current display panel. So it's not perfect. But I find it just a lot nicer to use than modern versions of KDE. Other people doubtless have different opinions. Doc -- Web: http://enginehousebooks.com/drevans
Re: debian stable kernel not updating on one machine
Andy Smith wrote on 2/2/21 6:33 PM: Perhaps you do not have the virtual package "linux-image-amd64" for some reason. That package depends upon the latest actual kernel package, so causes you to see upgrades. That's it. Somehow both linux-image-amd64 and the linux-headers-amd64 were no longer installed on that machine. Thank you. Doc -- Web: http://enginehousebooks.com/drevans
debian stable kernel not updating on one machine
I went to update one of my machines running debian stable today, using (as usual) synaptic [which I think is basically a wrapper for various apt functions]. The machine is running: [Z:~] uname -a Linux zserver 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux [Z:~] But I see that synaptic lists 4.19.0-14-amd64 as being available in the repository; and, indeed, on another machine I updated earlier in the day the kernel was updated from -13 to -14. How might I be able to diagnose why the files relating to the -14 kernel are not selected when I hit synaptic's "Mark All Upgrades" button? Doc -- Web: http://enginehousebooks.com/drevans
Re: rsync link corruption with -H and --link-dest
Celejar wrote on 11/22/20 7:46 AM: On a list like this, changing the subject line while leaving the other headers in place will result in many users' MUAs still associating the new message with the old thread, annoying those users. Just compose a And also meaning that users such as myself who weren't following the original thread never even saw your question at all. So it's in your own interest to thread messages properly, because otherwise some people who might want to respond to your issue, or otherwise be interested in it, might not ever see the issue raised if you don't start a new thread. Doc -- Web: http://enginehousebooks.com/drevans OpenPGP_0x69D7ACBC362912B8.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Thunderbird / enigmail
Greg Marks wrote on 10/21/20 5:23 PM: I had no problems transitioning from Enigmail to Thunderbird 78.3.1, which has removed Enigmail. With an existing GPG installation, it was necessary to run the command "gpg --export-secret-keys --armor > private_key.asc" for importation into Thunderbird. Then in Thunderbird, clicking the main account header in the side panel brings up a link "End-to-end encryption." This brings up "Account Settings," toward the bottom of which is an "End-To-End Encryption" header. From here one can enable OpenPGP by importing the "private_key.asc" file created earlier. OK, but how do I create a sticky setting that tells TB to use encryption? If I go to "Account Settings | End-to-End Encryption" I can select and add a key to an account. But there doesn't seem to be a "save" function, and as soon as I leave the settings page, the setting reverts to "None - do not use OpenPGP for this identity". The first step is not exactly adding a key to an account. The first step is importing a private GPG key stored on your computer for use in Thunderbird; this key can then be used (or not) with any e-mail account you are accessing via Thunderbird. (For example, you might access both a work e-mail account and a personal e-mail account in Thunderbird.) I'll try to elaborate on my previous message with more details. I'm assuming you have an existing GPG key stored in the subdirectory ~/.gnupg of your home directory and have run the command "gpg --export-secret-keys --armor > private_key.asc" already. 1. In Thunderbird, under Account Settings --> End-to-End Encryption," under the "OpenPGP" section, initially it will say, "Thunderbird doesn't have a personal OpenPGP key for [your e-mail address]." Next to that message is a button "Add Key." Yep; that's what I did. 2. Clicking on that button opens a new window with the message, "If you have an existing personal key for this email address, you should import it. Otherwise you will not have access to your archives of encrypted emails, nor be able to read incoming encrypted emails from people who are still using your existing key." You will be able to select either "Create a new OpenPGP Key" or "Import an existing OpenPGP Key." Select "Import an existing OpenPGP Key" and click "Continue." Yep; that's what I did. 3. In the next window that opens, click "Select File to Import" and select the file "private_key.asc" created earlier. Yep; that's what I did. 4. A new window will open that should have a message at the top saying (in my case) "Thunderbird found 2 keys that can be imported"; each will be listed with its ID, e-mail address, and a box you can check saying "Treat this key as a Personal Key." (In my case, I selected my most recent key, the earlier one having been revoked.) Click "Continue." You'll be asked to enter the passphrase used to decrypt access to your private key on your machine. Then a window should open with a green highlighted message saying "OpenPGP Keys successfully imported!" Each key will be listed with a button "Key Properties." Yep; that's what I did. 5. At the bottom of the window there will be a message, "To start using your imported OpenPGP key for email encryption, close this dialog and access your Account Settings to select it." Click Continue. Then, on the Account Settings --> End-to-End Encryption screen, deselect "None" and select the ID of the OpenPGP key. Yep; that's what I did. That's the thing that I don't know how to make sticky. Merely selecting the ID doesn't seem to do anything except that the marked radio button switches from "None" to the key ID. If I leave that screen and return to it, the "None" radio button is marked again. 6. At the bottom of the page you can select default settings for sending messages: whether to encrypt by default, whether to digitally sign be default. If you are using Thunderbird to access multiple accounts, you will set these options on the "Account Settings --> End-to-End Encryption" page for each account. Nope; they remain greyed out, even after step 5. 7. Quit Thunderbird and restart it. (This step is probably unnecessary but couldn't hurt.) I'm afraid that that doesn't help. I still can't use encryption, and when I go back to the e2ee screen under the account settings, "None" is selected, not the key I previously selected. So far as I can tell, account settings in Thunderbird are sticky by default. If I go to Account Settings (accessible under the "Edit" drop-down menu of Thunderbird), change an option, and then simply close the "Account Settings" tab, the option stays as I set it until I change it again by reopening Account Settings. They seems to be sticky here, except for the choice of key. Or, to be more precise, the choice of key never seems actually to enable any functionality, so I suspect that TB is somehow thinking that I still haven't selected a key, even though the radio button is definitely consistent
Re: Thunderbird / enigmail
Greg Marks wrote on 10/13/20 9:37 AM: I had no problems transitioning from Enigmail to Thunderbird 78.3.1, which has removed Enigmail. With an existing GPG installation, it was necessary to run the command "gpg --export-secret-keys --armor > private_key.asc" for importation into Thunderbird. Then in Thunderbird, clicking the main account header in the side panel brings up a link "End-to-end encryption." This brings up "Account Settings," toward the bottom of which is an "End-To-End Encryption" header. From here one can enable OpenPGP by importing the "private_key.asc" file created earlier. OK, but how do I create a sticky setting that tells TB to use encryption? If I go to "Account Settings | End-to-End Encryption" I can select and add a key to an account. But there doesn't seem to be a "save" function, and as soon as I leave the settings page, the setting reverts to "None - do not use OpenPGP for this identity". Doc PS BTW Thanks very much for the instructions; I would have been completely lost without them. This sure isn't easy/obvious. -- Web: http://enginehousebooks.com/drevans
Re: rsync --delete
Mike McClain wrote on 10/16/20 4:09 PM: > I've been using rsync to backup to a flash drive but it's not > performing exactly as I expected. > > The man page says: > --deletedelete extraneous files from dest dirs > A section of the backup script is so: > Params=(-a --inplace --delete); > Flash=/sda/rpi4b > cd /home/mike > [ ! -d $Flash/mike ] && mkdir $Flash/mike; > > # exclude compressed files and the contents of most of the .* directories > /mc/bin/mk_rsync_exclude.sh > echo /usr/bin/rsync $Params --exclude-from=/home/mike/.rsync_exclude . > $Flash/mike > /usr/bin/rsync $Params --exclude-from=/home/mike/.rsync_exclude . $Flash/mike > || > echo rsync $Params --exclude-from=/home/mike/.rsync_exclude . $Flash/mike >Failed $? ; > > If I delete a file from my home directory then backup over last > week's copy the deleted file stays in the backup directory and these > build up over time. > Am I misusing rsync or am I just not understanding how it works? The latter :-) You need to add: --delete-excluded (I'll let you read the man page to see what that does :-) ) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Thunderbird / enigmail
Greg Marks wrote on 10/13/20 9:37 AM: >> So I'd like to know if anyone who uses encrypted e-mail has taken >> the plunge and installed the newer version of Thunderbird that the >> official buster repository is offering (and also, therefore, removed >> enigmail); and, if so, have there been any issues with using encrypted >> e-mail following the update. > > I had no problems transitioning from Enigmail to Thunderbird 78.3.1, > which has removed Enigmail. With an existing GPG installation, it > was necessary to run the command "gpg --export-secret-keys --armor > > private_key.asc" for importation into Thunderbird. Then in Thunderbird, > clicking the main account header in the side panel brings up a link > "End-to-end encryption." This brings up "Account Settings," toward the > bottom of which is an "End-To-End Encryption" header. From here one can > enable OpenPGP by importing the "private_key.asc" file created earlier. > (Afterwards "private_key.asc" should be securely deleted, e.g. with srm.) > Once this is complete, when composing an e-mail in the new Thunderbird, > there is a "Security" tab near the top permitting one to encrypt or > digitally sign the message. It all seems to work fine. > Thank you for that encouraging information. I'll give it a day or two to see if anyone says that they had problems with the transition, and, if not, will give it a shot, hoping and expecting that it will be as smooth as your experience. [The experience a couple of years ago when debian stable for a while wouldn't permit encrypted e-mail from Thunderbird has probably made me over-cautious on this subject.] Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Thunderbird / enigmail
to...@tuxteam.de wrote on 10/13/20 8:25 AM: > On Tue, Oct 13, 2020 at 07:26:28AM -0600, D. R. Evans wrote: >> repository. But I seem to recall reading somewhere a while back that the >> enigmail functionality was going to be incorporated into Thunderbird >> upstream. > > This is true, AFAIK, from Thunderbird 78 on. See [1]. > > Cheers > > [1] https://blog.thunderbird.net/2019/10/thunderbird-enigmail-and-openpgp/ > - t Yes, that's the post I think I saw. Still, preferring not to be a guinea pig on this occasion, I'm wondering if any enigmail user here has installed the update, and if they have had any problems with the transition to the new enigmail-less encrypted e-mail system. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Thunderbird / enigmail
I see that the latest official updates to debian stable want to remove enigmail and install a new version of Thunderbird. I recall a couple of years ago the same thing happened, and encrypted e-mail was effectively broken for a couple of months until a version of enigmail compatible with the updated Thunderbird became available from the official repository. But I seem to recall reading somewhere a while back that the enigmail functionality was going to be incorporated into Thunderbird upstream. So I am wondering if perhaps this has happened and that that is what the intended removal of enigmail signifies: i.e., that encrypted e-mail is part of the newer Thunderbird that is now in the official repository. So I'd like to know if anyone who uses encrypted e-mail has taken the plunge and installed the newer version of Thunderbird that the official buster repository is offering (and also, therefore, removed enigmail); and, if so, have there been any issues with using encrypted e-mail following the update. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: arc_meta_used > arc_meta_limit, need tuning hints
Victor Sudakov wrote on 9/30/20 7:12 AM: > No ZFS gurus here? Where could I ask? > zfs-disc...@list.zfsonlinux.org Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: 32 versus 64 bit reading list suggestions
David Wright wrote on 9/7/20 12:53 PM: > > That may be an unfair comparison as the OP has a 64-bit machine > running the 32-bit software, rather than two machines of different > generations. > Sorry; I missed that. (I find it too easy to skim instead of actually /read/ on a computer screen.) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: 32 versus 64 bit reading list suggestions
Richard Owlett wrote on 9/7/20 9:12 AM: >> > > Answers I'm seem focused on too low levels. I'm interested in the > end-user experience. > > E.G. what end user observable difference would there be between 32 bit > based browser and a 64 bit based browser? > The short version: what Reco said. The longer version: 64-bit will be faster... not because 64-bit is intrinsically faster (although, depending on the optimisation settings in the compilation, it almost certainly will be faster, as has been pointed out, because of the additional CPU instructions available on 64-bit machines), but basically because the 64-bit CPU is likely to be newer and run at a higher clock rate, and hence faster for that reason alone. I recently retired a debian stable 32-bit machine in favour of a debian stable 64-bit machine. All ordinary pre-built officially supported programs simply worked exactly the same (but /far/ faster: for example, a 10-minute code compile became less than 20 seconds). [I did have trouble with low-level sound in my own code, but that was entirely related to the fact that the sound hardware on the new machine supported only CD-quality sound, and it took quite a bit of digging, learning and a lot of print statements finally to get it to do what happened naturally on the old 32-bit machine when I needed low-quality sampling.] The biggest reason to switch, if everything runs sufficiently quickly on the 32-bit machine, is probably that at some point 32 bits will stop being supported (I vaguely seem to remember that the decision to do that has already been taken by the debian project once, but was revoked). Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Recommendation for filesystem for USB external drive for backups
Greg Wooledge wrote on 8/13/20 2:29 PM: > > The simplest answer would be to use ext4. > I concur, given the OP's use case. And I speak as someone who raves about ZFS at every reasonable opportunity :-) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: grub update and reinstallation
Tom Dial wrote on 8/1/20 9:31 PM: > > My experience, now on eight machines, indicates that it should be if the > installed, configured, and used versions of grub components is > > 2.02+dfsg1-20+deb10u2. > > I could be wrong, but here it has been the case for both UEFI (and root > on ZFS) and legacy boot setups, on both i386 and amd64. The only > exception is one root-on-ZFS VM that was slightly broken beforehand and > declines to boot for reasons I am fairly sure are unrelated to grub > installation. > So if one has two bootable drives (call them A and B), will this update update the MBR on both A and B, not just the one that happened to have been used for the most recent boot? I ask because I have a couple of root-on-ZFS BIOS-boot machines that are both configured as two-disk mirrors and I want to be sure that, following this upgrade, I can still boot off either of the two disks (as I can at the moment) without having to perform any manual changes. The use case is, if it's not obvious, that if under normal circumstances disk A is used for booting, but then at some point A fails (so ZFS is running in a degraded state) I can still boot from drive B if necessary. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Do other owners of WD Gold disks hear a periodic plonk ?
rhkra...@gmail.com wrote on 7/24/20 4:28 PM: > On Friday, July 24, 2020 05:35:34 PM Thomas Schmitt wrote: >> David Christensen wrote: >>> https://en.wikipedia.org/wiki/Click_of_death >> >> But that's a different technology (and 20 years ago). > > You might not have read the entire article. > Having experienced this phenomenon multiple times on both Zip disks (!) and hard drives, I can say that my experience (YMMV) is that 100% of the drives that exhibit this phenomenon have failed sometime not long after the phenomenon began -- I recently had a hard drive stay alive and usable for a month or so after starting to click, but it did eventually permanently fail. All the other drives failed much more quickly than that. Reco wrote on 7/24/20 1:14 PM: > What about smartctl long test, does it show anything suspicious? Definitely you should try that, possibly multiple times if it happens to pass the first time. Frankly, I wouldn't trust the drive in any case -- if for some reason I *had* to continue to use it, I'd definitely put it in a RAID array of some kind, with a spare available to replace it at short notice. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Advice on hardware server to use for small a dedicated data center
Dan Ritter wrote on 6/26/20 1:41 PM: > echo test wrote: > >> Note: I will need some RAID solution hard or soft. > > We are firmly of the opinion that mdadm or ZFS are the best > solutions here. > Absolutely. Actually I'd go further and differentiate the two by suggesting that if you use ECC memory (which you definitely should for a business server) then ZFS is the way to go. If for some reason you can't use ECC memory, then mdadm is arguably the thing to use (although there is certainly a valid position that says that ZFS is /still/ the right one). At least, that's the way I have my systems configured. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Looping Shell Scripts and System Load
Martin McCormick wrote on 6/24/20 11:19 AM: > > Right now, uptime looks like: > > 11:48:07 up 26 days, 23:10, 7 users, load average: 16.15, 15.60, 10.65 > > That's pretty loaded so ideally, one could start the > looping script and it would fire up processes until things got > really busy and then not allow any more new procs to start until > some have stopped so cron and other system utilities don't stop > running which is what happens when systems get too busy. > > Thanks for any constructive suggestions. > My general approach is to use sem to create N-1 parallel jobs, where N is the number of CPUs on the machine. Not /exactly/ what you're asking for, but something along those lines would probably help the situation. At least, it works for me :-) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
[SOLVED] Re: Question for users of Thunderbird on buster
Virgo Pärna wrote on 6/16/20 6:27 AM: > > Nothing to do with keyboard layouts. Some fonts have ligatures, > that combine two different characters into one symbol. I actually tried > it on Windows with Thunderbird and "Cascadia Mono" font. Rendering > engine in Thunderbird probably has ligature support enabled and then, if > used font has ligatures for specific symbol, then those are used. > I finally had some time to delve into this, and indeed that was the problem. The font mapped the pair "<<" to the left guillemot, the pair "--" to an en-dash (although the en-dash glyph was no different than the ordinary hyphen glyph, so it looked like it was dropping one of the pair), along with a handful of other ligatures. Using fontforge I edited the ligature table to remove the ones that were causing a problem. Restarted Thunderbird and presto! all fixed. So many (many!) thanks to Virgo for the suggestion to look at the font itself. I looked in the TB config editor, but couldn't see anything that would turn off the use of ligatures -- which is rather surprising, since it must have been enabled only in the fairly recent past, as I'm using exactly the same fonts I've been using for years without this problem appearing -- but maybe it's in the config editor with an unguessable name. It's also surprising that TB enables ligatures with a monospoaced font, because that's generally not a good idea; but I suppose that if the font itself says it's OK to use a ligature, I can only half-blame TB for using it :-) Anyway, I'm delighted that I can now write: cout << n-- << endl; without a noticeable increase in my blood pressure. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Question for users of Thunderbird on buster
Virgo Pärna wrote on 6/16/20 6:34 AM: > On Thu, 11 Jun 2020 13:12:25 -0600, D. R. Evans wrote: >> >> I'll have to dig in and see if there's a way to turn it off. I'll look at the >> details of the font as well; I'm not at all sure what exactly is telling TB >> "if you see two consecutive "less-than" signs, then render them as a single >> "much less than" character. No other program seems to be doing it, so it >> seems >> to be a TB decision somewhere; but since it seems to be font-dependent, TB >> must (presumably) be looking at some characteristic of the font before >> deciding to make the substitution. Very strange. > > https://bugzilla.mozilla.org/show_bug.cgi?id=450151 maybe? > I don't think so. Changing the value of: browser.display.auto_quality_min_font_size makes no difference :-( Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: Question for users of Thunderbird on buster
Virgo Pärna wrote on 6/11/20 1:27 AM: > On Wed, 10 Jun 2020 14:10:45 -0600, D. R. Evans wrote: >> For example: >> if I type the "-" character twice in a row, Thunderbird displays only one, >> even though both characters are present in the text >> if I type the "<" character twice in a row, Thunderbird converts the two >> "less than" characters into a single "much less than" character when it >> displays them, even though the text actually contains the two "<" characters >> > > What happens, if you change the default composition font. Sounds > like those are rendered as ligatures. I'm using Windows, but when I set > monospace font to Cascadia code, I started getting similar issues. Oh, that's very interesting. Yep, changing font "fixed" the problem. It's a puzzle why someone thought would think that this would be a good way for the rendering engine to work. I can think of a few of reasons for it NOT to behave this way, and none for why it's a good idea. I'll have to dig in and see if there's a way to turn it off. I'll look at the details of the font as well; I'm not at all sure what exactly is telling TB "if you see two consecutive "less-than" signs, then render them as a single "much less than" character. No other program seems to be doing it, so it seems to be a TB decision somewhere; but since it seems to be font-dependent, TB must (presumably) be looking at some characteristic of the font before deciding to make the substitution. Very strange. Thanks for the suggestion that it might be dependent on the font. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Question for users of Thunderbird on buster
As far as I can tell, no one else using other OSes seems to be having this problem, so maybe it's a Thunderbird-on-buster issue that needs to be reported somewhere. Or maybe it's just my system for some obscure reason So, with current buster, the installed version of Thunderbird is 68.8.0. I have Thunderbird configured to generate ordinary plain-text e-mails (like this one). When composing an e-mail, something (and I assume it's Thunderbird because I can't guess what else might do this) is attempting to be "intelligent" and is interpreting sequences of characters instead of just leaving them alone when they are displayed. For example: if I type the "-" character twice in a row, Thunderbird displays only one, even though both characters are present in the text if I type the "<" character twice in a row, Thunderbird converts the two "less than" characters into a single "much less than" character when it displays them, even though the text actually contains the two "<" characters So on the next line I type the "-" character twice: -- and on the next line I type the "<" character twice: << in both cases they are being displayed incorrectly in the composition window here. Are other people seeing the same behaviour? Doc PS I have tried turning off all add-ons and restarting Thunderbird, but it made no difference. -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: how to build package alsa-utils?
to...@tuxteam.de wrote on 5/29/20 8:08 AM: > On Fri, May 29, 2020 at 07:54:51AM -0600, D. R. Evans wrote: >> I am trying to build alsa-utils from source, but am clearly missing something >> obvious. >> >> 1. I executed: >> apt-get source alsa-utils >> and that seemed to run OK, generating: >> >> drwxr-xr-x 23 n7dr n7dr4096 May 29 07:41 alsa-utils-1.1.8 >> -rw-r--r-- 1 n7dr n7dr 27076 Apr 9 2019 alsa-utils_1.1.8-2.debian.tar.xz >> -rw-r--r-- 1 n7dr n7dr2346 Apr 9 2019 alsa-utils_1.1.8-2.dsc >> -rw-r--r-- 1 n7dr n7dr 1019988 Feb 11 2019 alsa-utils_1.1.8.orig.tar.bz2 >> >> 2. In alsa-utils-1.1.8, there is no BUILD file (which is what I'm used to >> seeing), but there is an INSTALL file, which says: >> for installation you can use these commands: >> ./configure >> make install >> so I figured that the normal "./configure; make" would perform the build. >> >> 3. There is no ./configure file :-( So there seems to be an inconsistency >> between the instructions and what is actually supplied. >> >> Without a ./configure file, I don't know how to proceed :-( > > Most probably (I'm assuming alsautils is an autoconf package), there > is a configure.ac from which to generate the configure script. So > you'd first have to invoke autoconf for that. BUT WAIT! > > This is a Debian package. One of the things Debian does for you is > to unify all that buildery. So first > > - install the package "build-essential" > - install the packages alsa-util's build depends on: >apt-get build-dep alsa-utils > - change into alsa-utils-1.1.8 > - invoke there >dpkg-buildpackage -uc -us >(look up in the man page what those things mean) > > A finished Debian package apears next to alsa-utils-1.1.8. Unless... > I've forgotten something, that is. Just come back. > It all looks good. The build process spewed out an "interesting" number of warnings but no errors. I guess that debian (and, presumably, upstream) doesn't worry much about mere warnings. Anyway, a quick test shows that the binary I was interested in runs as expected, so now I'm in a position to make some changes to the source in an attempt to understand why arecord works with a particular set of parameters that causes my own code to throw a hissy fit. Thanks very much. A very useful and informative morning. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: how to build package alsa-utils?
to...@tuxteam.de wrote on 5/29/20 8:08 AM: > On Fri, May 29, 2020 at 07:54:51AM -0600, D. R. Evans wrote: > > This is a Debian package. One of the things Debian does for you is > to unify all that buildery. So first > > - install the package "build-essential" > - install the packages alsa-util's build depends on: >apt-get build-dep alsa-utils > - change into alsa-utils-1.1.8 > - invoke there >dpkg-buildpackage -uc -us >(look up in the man page what those things mean) > > A finished Debian package apears next to alsa-utils-1.1.8. Unless... > I've forgotten something, that is. Just come back. What a wonderful, quick response. Thank you so much. I'll try this later today and report back (and make a note of all this somewhere in case I ever need to do something like this again I've occasionally had to look at source before, but I think this is the first time I've needed to actually build a package.). Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
how to build package alsa-utils?
I am trying to build alsa-utils from source, but am clearly missing something obvious. 1. I executed: apt-get source alsa-utils and that seemed to run OK, generating: drwxr-xr-x 23 n7dr n7dr4096 May 29 07:41 alsa-utils-1.1.8 -rw-r--r-- 1 n7dr n7dr 27076 Apr 9 2019 alsa-utils_1.1.8-2.debian.tar.xz -rw-r--r-- 1 n7dr n7dr2346 Apr 9 2019 alsa-utils_1.1.8-2.dsc -rw-r--r-- 1 n7dr n7dr 1019988 Feb 11 2019 alsa-utils_1.1.8.orig.tar.bz2 2. In alsa-utils-1.1.8, there is no BUILD file (which is what I'm used to seeing), but there is an INSTALL file, which says: for installation you can use these commands: ./configure make install so I figured that the normal "./configure; make" would perform the build. 3. There is no ./configure file :-( So there seems to be an inconsistency between the instructions and what is actually supplied. Without a ./configure file, I don't know how to proceed :-( FWIW, all I really want to build is aplay, but all my attempts to do that manually throw up compilation errors. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
unable to create SCHED_FIFO thread on 64-bit buster
I have some code that has worked for years under 32-bit versions of Debian (and other distros before that). Specifically, it works fine under 32-bit buster. But on a pristine 64-bit installation it fails, and I can sort-of understand why, but I don't know how to fix it. The code tried to create a pthread with SCHED_FIFO policy and a priority of 95. The call to pthread_create() fails with an EPERM error. If I run ulimit -r, it returns 0, which is probably why the call to pthread_create() failing, but I don't know what to change so that I (operating as an ordinary user) can create a SCHED_FIFO thread with priority > 0. The documentation I've found says to edit /etc/security/limits.conf, and I have done so, adding the line: n7drhardrtprio 99 but that made no difference :-( None of my notes say that I had to do anything special to get this to work in the past, but it's possible (barely) that somehow I had to edit a configuration file of some kind and simply forgot to make a note. What am I missing/forgetting? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: R performance
Mark Fletcher wrote on 5/12/20 9:55 AM: > On Tue, May 12, 2020 at 08:16:52AM -0600, D. R. Evans wrote: >> Mark Fletcher wrote on 5/12/20 7:34 AM: >>> Hello >>> >> >> I have noticed that recent versions of R supplied by debian are using all the >> available cores instead of just one. I don't know whether that's a debian >> change or an R change, but it certainly makes things much faster (one of my >> major complaints about R was that it seemed to be single threaded, so I'm >> very >> glad that, for whatever reason, that's no longer the case). >> > Thanks, but definitely not the case here. When running on my own > machine, top shows the process at 100% CPU, the load on the machine > heading for 1.0, and the Gnome system monitor shows one CPU vCore > (hyperthread, whatever) at 100% and the other 7 idle. > > R is certainly _capable_ of using more of the CPU than that, but you > have to load libraries eg snow and use their function calls to do it -- in > short, like in many languages, you have to code for parallelism. I tried > to keep parallelism out of this experiment on both machines being > compared. > OK. Well I don't understand what's going on and don't really have anything further to contribute :-( All I know is that the same code that used to run on just one core pre-buster now uses all the cores available, with no changes or fancy libraries. I was (of course) very pleasantly surprised the first time I ran one of my R scripts under buster and saw this happen. I haven't experimented further. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: R performance
Mark Fletcher wrote on 5/12/20 7:34 AM: > Hello > > I have recently had cause to compare performance of running the R > language on my 10+-year-old PC running Buster (Intel Core i7-920 CPU) > and in the cloud on AWS. I got a surprising result, and I am wondering > if the R packages on Debian have been built with any flags that account > for the difference. > > My PC was a mean machine when it was built, but that was in 2009. I'd > expect it would be outperformed by up to date hardware. > I have noticed that recent versions of R supplied by debian are using all the available cores instead of just one. I don't know whether that's a debian change or an R change, but it certainly makes things much faster (one of my major complaints about R was that it seemed to be single threaded, so I'm very glad that, for whatever reason, that's no longer the case). Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: authentication failing through PolicyKit
john doe wrote on 3/2/20 12:31 PM: > On 3/2/2020 8:22 PM, D. R. Evans wrote: >> I am trying to run a command that appears to need super-user privileges. When >> it tries to run, I get: >> >> --- >> >> AUTHENTICATING FOR org.freedesktop.policykit.exec === >> Authentication is needed to run `/tmp/hda-jack-retask-0TDDG0/script.sh' as >> the >> super user >> Authenticating as: D. R. Evans,,, (n7dr) >> Password: >> polkit-agent-helper-1: error response to PolicyKit daemon: >> GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie >> AUTHENTICATION FAILED === >> Error executing command as another user: Not authorized >> >> This incident has been reported. >> >> --- >> >> I have tried entering my password, and also entering the super-user password >> (as the wording is rather ambiguous, although most likely it seems to be >> wanting the password of the regular user). In both cases, I get the >> AUTHENTICATION FAILED message and am unable to proceed. >> >> I have no idea why this is happening, nor how to fix it. Any assistance would >> be gratefully received. >> > > Looks like it is 'sudo' related, you need to add your user in the > sudoers file or in a file in /etc/sudoers.d or to the sudo group. > I am already in the sudo group: --- root@zbrew:/etc# groups n7dr n7dr : n7dr cdrom floppy sudo audio dip video plugdev netdev root@zbrew:/etc# --- and the sudoers file confirms that I should be able to do anything: --- # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL --- Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
authentication failing through PolicyKit
I am trying to run a command that appears to need super-user privileges. When it tries to run, I get: --- AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/tmp/hda-jack-retask-0TDDG0/script.sh' as the super user Authenticating as: D. R. Evans,,, (n7dr) Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported. --- I have tried entering my password, and also entering the super-user password (as the wording is rather ambiguous, although most likely it seems to be wanting the password of the regular user). In both cases, I get the AUTHENTICATION FAILED message and am unable to proceed. I have no idea why this is happening, nor how to fix it. Any assistance would be gratefully received. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Curt wrote on 2/13/20 9:31 AM: > On 2020-02-13, D. R. Evans wrote: >> >> I'm wondering if there's a problem with the sound driver that the system = >> is >> using, and therefore: >> 1. How to determine which driver I'm using? >> 2. How to switch to a different driver, if one is available? > > (And you've tried adjusting, to no avail, the underlying ALSA-level volume > controls > with alsamixer?) > Yes. That was in one of my e-mails somewhere in the thread. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
D. R. Evans wrote on 2/12/20 4:58 PM: > For what it's worth, "aplay -l" says, for the port I'm using: > > card 0: PCH [HDA Intel PCH], device 0: ALC888-VD Analog [ALC888-VD Analog] > Subdevices: 0/1 > Subdevice #0: subdevice #0 > I'm wondering if there's a problem with the sound driver that the system is using, and therefore: 1. How to determine which driver I'm using? 2. How to switch to a different driver, if one is available? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
D. R. Evans wrote on 2/12/20 12:28 PM: > Doug McGarrett wrote on 2/12/20 12:19 PM: >> >> >> On 2/12/20 1:05 PM, D. R. Evans wrote: >>> Jonas Smedegaard wrote on 2/12/20 10:43 AM: >>>> Quoting D. R. Evans (2020-02-12 18:34:27) >>>>> I just installed buster on a new (to me) machine, and the audio level >>>>> is very low. With all the mixer controls and the physical volume >>>>> control on the speakers turned up, I can hear audio, but even then it >>>>> is unpleasantly quiet, certainly nothing one would want to listen to. >>>>> >>>>> Any suggestions as to how to fix this, or even how to go about >>>>> investigating it sensibly, would be gratefully received. >>>> > >>> >> You say this is a new machine, so it surely came with Windows. If you > > No, I said it was new to me. It worked fine under Windows -- basically a > gaming machine -- but now it has brand new disks with a clean install of > buster. i have been corrected by the person from whom I bought it: it was previsouly used as a server, not a gaming machine, and hence the sound was never used. For what it's worth, "aplay -l" says, for the port I'm using: card 0: PCH [HDA Intel PCH], device 0: ALC888-VD Analog [ALC888-VD Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Jonas Smedegaard wrote on 2/12/20 3:21 PM: > I would recommend to first try locate possible places where volume is > turned down, and only as a last option (for this setup, before giving up > and buying another card) artificially amplify the weak audio - because > that will undoubtedly lead to bad audio quality, and has the risk of > playing too loud if at some point the dampening place decides to no > longer dampen. > > My thoughts exactly. There is obviously something somewhere set incorrectly, and the proper fix is to find it and change the setting. All the simple user-based stuff seems to be too late in the chain: the volume is already too low by the time any of the normal user programs that have been suggested come into play. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Jonas Smedegaard wrote on 2/12/20 3:19 PM: > Another thing you might try is go "below" Pulseaudio and mess directly > with ALSA settings: > > Install the package alsa-utils and run (in a terminal) the tool > alsamixer > > By default it will probably show a single volume control for a virtual > audio card called Pulseaudio - switch to your real underlying audio card > by hitting F6 and select it. Try play around with that... All the outputs are set to 100. Lowering them does make things (even) quieter; but that's not very helpful, of course. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Jonas Smedegaard wrote on 2/12/20 1:26 PM: > Quoting D. R. Evans (2020-02-12 19:05:40) >> Jonas Smedegaard wrote on 2/12/20 10:43 AM: >>> Quoting D. R. Evans (2020-02-12 18:34:27) >>>> I just installed buster on a new (to me) machine, and the audio >>>> level is very low. With all the mixer controls and the physical >>>> volume control on the speakers turned up, I can hear audio, but >>>> even then it is unpleasantly quiet, certainly nothing one would >>>> want to listen to. >>>> >>>> Any suggestions as to how to fix this, or even how to go about >>>> investigating it sensibly, would be gratefully received. >>> >>> Maybe you missed some mixer controls? Desktop environments nowadays >>> commonly use (not only ALSA but also) Pulseaudio, and a common >>> mistake is to only play with the knobs tied to ALSA. >>> >>> One relatively userfriendly interface to Pulseaudio that I know of >>> is pavucontrol, available in the Debian package of the same name. >>> You can run it as a self-contained graphical tool, or if you want it >>> handy accesible then additionally install pasystray. >>> >> >> OK; I installed that, but it doesn't seem to do anything more than the >> desktop mixer program. >> >> It says that Analog Stereo Output is 100%, as does the mixer program. >> Moving that slider does make the volume even lower, so it is having an >> effect, but only to make the audio even harder to hear. > > That sounds like you have looked at _one_ of the volume controls. >> When I open pavucontrol (on my Debian unstable system, but should be > similar e.g. on Debian buster), there are 5 tabs: > > * Playback >+ one control per source (e.g. "System sounds", mpv, and microphone) "System Sounds" is the only one. It's at 100% > * Recording >+ one control per recorder (irrelevant for _playing_ audio) > * Output Devices >+ one control per audio device (incl. virtual ones if enabled) One slider, at 100%. > * Input Devices >+ one control per audio device (irrelevant for _playing_ audio) > * Configuration >+ switch to select routing mode (e.g. use HDMI instead of analog) It's set to "Analog Stereo Output"; since my speakers are plugged into the green jack at the back, it seems like that should be the correct selection. > > Make sure that you check both application level volume (for the > application you want to test - while it is running) and output device > volume. At this point I've tried with several programs that I've used (on other systems) for a long time. On all of them, even with the volume set to 100%, the sound is audible but too quiet. The same applications playing the same files on my debian 9 system produces output that is too loud for comfort. > Also, try available routing modes - they depend on your audio > device(s) so I cannot tell what is correct or optimal on your system. I don't know what "routing modes" means, nor where to control them. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Doug McGarrett wrote on 2/12/20 12:19 PM: > > > On 2/12/20 1:05 PM, D. R. Evans wrote: >> Jonas Smedegaard wrote on 2/12/20 10:43 AM: >>> Quoting D. R. Evans (2020-02-12 18:34:27) >>>> I just installed buster on a new (to me) machine, and the audio level >>>> is very low. With all the mixer controls and the physical volume >>>> control on the speakers turned up, I can hear audio, but even then it >>>> is unpleasantly quiet, certainly nothing one would want to listen to. >>>> >>>> Any suggestions as to how to fix this, or even how to go about >>>> investigating it sensibly, would be gratefully received. >>> >> > You say this is a new machine, so it surely came with Windows. If you No, I said it was new to me. It worked fine under Windows -- basically a gaming machine -- but now it has brand new disks with a clean install of buster. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: low audio level
Jonas Smedegaard wrote on 2/12/20 10:43 AM: > Quoting D. R. Evans (2020-02-12 18:34:27) >> I just installed buster on a new (to me) machine, and the audio level >> is very low. With all the mixer controls and the physical volume >> control on the speakers turned up, I can hear audio, but even then it >> is unpleasantly quiet, certainly nothing one would want to listen to. >> >> Any suggestions as to how to fix this, or even how to go about >> investigating it sensibly, would be gratefully received. > > Maybe you missed some mixer controls? Desktop environments nowadays > commonly use (not only ALSA but also) Pulseaudio, and a common mistake > is to only play with the knobs tied to ALSA. > > One relatively userfriendly interface to Pulseaudio that I know of is > pavucontrol, available in the Debian package of the same name. You can > run it as a self-contained graphical tool, or if you want it handy > accesible then additionally install pasystray. > OK; I installed that, but it doesn't seem to do anything more than the desktop mixer program. It says that Analog Stereo Output is 100%, as does the mixer program. Moving that slider does make the volume even lower, so it is having an effect, but only to make the audio even harder to hear. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
buster: low audio level
I just installed buster on a new (to me) machine, and the audio level is very low. With all the mixer controls and the physical volume control on the speakers turned up, I can hear audio, but even then it is unpleasantly quiet, certainly nothing one would want to listen to. Any suggestions as to how to fix this, or even how to go about investigating it sensibly, would be gratefully received. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: The nightmare of Intel Integrated GPUs under Linux in general and Debian in particular
Miguel A. Vallejo wrote on 2/11/20 12:07 PM: > > What are my alternatives? nVidia cards? I've never used an nVidia card > but I have read also tons of problems with them in the past. How about > now? And how about AMD cards? > > What are your recommendations / experiences? > My advice: put an nvidia card in there. That's what I did, and have had no problems since. (I also had to tell the BIOS to affirmatively disable the Intel GPU, otherwise insanity resulted, with two desktop sessions both being sent to the nvidia chip; it seemed that if the kernel could see two chips, it was determined to create two sessions, even if only one chip was actually attached to a monitor, and then it would send the two sessions to that chip/monitor.) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: graphics woes :-(
Felix Miata wrote on 1/27/20 4:47 PM: > D. R. Evans composed on 2020-01-27 14:57 (UTC-0700): > >> I'm sure I'm missed out important information, so feel free to ask and I'll >> do >> my best to answer. > > I have a display that takes a long time to initialize when connected to a PC > using > UEFI mode and a disk configured with GPT and UEFI boot, but not connected to > an > MBR disk. So IME, this trouble may be as much to blame on the display itself > as > the PC. > > In no particular order, things to try re the access to BIOS problem: > > 1-when you do get into BIOS, turn off Fast Boot. There is no Fast Boot setting. > > 2-check for a BIOS upgrade > Will do, but the mobo is several years old, and the BIOS was recently updated. > 3-disconnect the HD, and try turning PC on with only a DVD, CD or 2.0 USB > stick as > potential boot device (to make it take longer to handoff from POST to boot) That will be very difficult, and I'm not exactly sure how that would be expected change the visibility of the BIOS screen. > > 4-Don't wait for a beep to try BIOS access keys (F2/DEL/whatever) > Tried that; nothing appears on the display, although to judge from the (lack of) sounds from the drives, it "thinks" it is displaying the BIOS screen. No textual boot messages appear. > 5-try another display (or a TV) I don't have one that I can easily switch. This display works fine on several other debian computers, though, and works with Intel with the problem computer, except for the flickering problem I mentioned. > > 6-connect to the display using the connector closest to the motherboard and/or > farthest from the expansion slots I don't understand what you're saying. There's the motherboard (Intel) connector and the card connector, and obviously I have to switch to the card connector to use the add-on graphics card, so I'm really not understanding what you're suggesting. > > 7-once in the BIOS, make the initial display output selection not equal to IGP > 1st, e.g. Disabled I don't see any mention of any kind of display output in the BIOS settings. > > Re tearing with Intel: > > If this is a dual channel RAM motherboard with only one RAM stick installed, > switch to a matched pair. Intel GPUs share system RAM. Also, in BIOS, adjust > the > amount of RAM allocated to GPU. (DVMT Pre-Allocated and DVMT Total Gfx Mem on > my > Gigabyte) > I don't see anything like that in any BIOS screen. FWIW, the motherboard is a SuperMicro MBD-X11SAT-F-P, with an AMI BIOS. > Re cheap graphics cards: > Any of the under $15 PCIe NVidia cards on eBay should suffice, but then so > should > your 750 Ti. > Yes, I thought that the 750 Ti would just plug in and work. But (obviously) it doesn't :-( Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: graphics woes :-(
Stefan Monnier wrote on 1/27/20 4:06 PM: >> anything at all, then, after a very long time, I see the stream of Linux text >> messages that indicates booting, but I never see a graphical login screen. >> (The delay before the messages appear is far longer than a normal boot cycle >> -- indeed, I had given up waiting for something to happen and was pondering >> my >> next move when suddenly the messages started flying by). > > This sounds like your BIOS doesn't know how (or try) to use your > graphics card, so all the BIOS output goes to the other display > connector (the one of the built-in graphics adapter). So the BIOS's own > boot messages, the GRUB boot messages, and the early kernel messages all > go "unseen" and it's only once the Linux kernel loads your display > driver (to get a framebuffer) that finally you start seeing output. > >> This sounds like perhaps a driver issue of some kind, so what packages >> do I need to be sure are > > No, it looks like it's fine on Linux's side. The problem is the earlier > boot environment (the one from which Linux is started). > > So the fix will need to be somewhere between your BIOS and your video card. > Maybe all it takes is to tell your BIOS to use your external graphics > card instead of (or additionally to) the built-in video adapter. That certainly sounds plausible, but I don't see anything in the AMI BIOS that mentions video at all. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: graphics woes :-(
D. R. Evans wrote on 1/27/20 2:57 PM: > Running debian stable (64 bit). > > For the past couple of months I've been trying to get a system with onboard > Intel graphics to work completely correctly, but have never been able to get > rid of flicker on the console tty or on fine text in konsole in a graphical > desktop. There are enough threads on the Internet about this sort of issue and > the Intel driver to indicate that this is a somewhat common problem with > various combinations of hardware when using an Intel chipset, and although > there is a lot of ad hoc advice, it seems that not everyone can successfully > work around what appears to be a bug in the Intel driver. Having tried all the > suggested fixes I saw, and none of them working, I decided to avoid the issue > by installing a non-Intel graphics card. > > A friend gave me an MSI Geforce GTX 750 Ti card, but I am having no success > getting it working. > > 1. Normally (i.e., when using the Intel hardware/software), after two beeps on > power on I can hit DEL a couple of times and be taken to the BIOS control > screens. With the Geforce card, everything just stays blank (forever) if I hit > DEL after the two beeps. So the first issue is: how can I access the BIOS > control screens when using this card? > > 2. If I boot with the monitor attached to the Geforce card and don't touch > anything at all, then, after a very long time, I see the stream of Linux text > messages that indicates booting, but I never see a graphical login screen. I also don't ever see the blue GRUB screen that normally counts down for five seconds before printing the text output. The Linux boot text output is the first thing to appear. > (The delay before the messages appear is far longer than a normal boot cycle > -- indeed, I had given up waiting for something to happen and was pondering my > next move when suddenly the messages started flying by). This sounds like > perhaps a driver issue of some kind, so what packages do I need to be sure are > installed to allow booting into a graphical environment with this card? > > The one hopeful sign is that when I see that text messages, the text doesn't > flicker... unlike when I boot with the Intel chipset/driver. > > I'm sure I'm missed out important information, so feel free to ask and I'll do > my best to answer. > Or, if someone can suggest a low-end graphics card that is just plug-and-play (I don't play games or need 3D stuff at all), maybe it'll just be easier to buy one and swap out the Geforce GTX 750 Ti, which is vastly more card than I need. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
graphics woes :-(
Running debian stable (64 bit). For the past couple of months I've been trying to get a system with onboard Intel graphics to work completely correctly, but have never been able to get rid of flicker on the console tty or on fine text in konsole in a graphical desktop. There are enough threads on the Internet about this sort of issue and the Intel driver to indicate that this is a somewhat common problem with various combinations of hardware when using an Intel chipset, and although there is a lot of ad hoc advice, it seems that not everyone can successfully work around what appears to be a bug in the Intel driver. Having tried all the suggested fixes I saw, and none of them working, I decided to avoid the issue by installing a non-Intel graphics card. A friend gave me an MSI Geforce GTX 750 Ti card, but I am having no success getting it working. 1. Normally (i.e., when using the Intel hardware/software), after two beeps on power on I can hit DEL a couple of times and be taken to the BIOS control screens. With the Geforce card, everything just stays blank (forever) if I hit DEL after the two beeps. So the first issue is: how can I access the BIOS control screens when using this card? 2. If I boot with the monitor attached to the Geforce card and don't touch anything at all, then, after a very long time, I see the stream of Linux text messages that indicates booting, but I never see a graphical login screen. (The delay before the messages appear is far longer than a normal boot cycle -- indeed, I had given up waiting for something to happen and was pondering my next move when suddenly the messages started flying by). This sounds like perhaps a driver issue of some kind, so what packages do I need to be sure are installed to allow booting into a graphical environment with this card? The one hopeful sign is that when I see that text messages, the text doesn't flicker... unlike when I boot with the Intel chipset/driver. I'm sure I'm missed out important information, so feel free to ask and I'll do my best to answer. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: not reaching login screen on console
Felix Miata wrote on 12/6/19 11:22 AM: > D. R. Evans composed on 2019-12-06 11:11 (UTC-0700): > >> I have a buster system that is failing ever to reach a login prompt on the >> console tty. > >> The last message on the screen is: >> A start job is running for Hold until boot process finished up >> followed by a timer that simply increases without end and says "no limit". > >> How do I find out what is causing this? > > After the last message appears, can you reach any of the other 5 vttys to find > waiting logins? Right away? Only after some delay of many seconds, or more > than a > minute? > Nope, all just black. But I could log in via ssh, and started backing out recent changes (I'm not sure how long the problem had existed, as I don't normally look at the console screen once X has started). One of the changes was to switch to the Trinity desktop manager, and when I reverted to using sddm, the problem went away. I don't like sddm, but at least it allows the machine to reach a login screen, so I'll forget about trying to use tdm on that machine, and assume that the problem won't recur. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
buster: not reaching login screen on console
I have a buster system that is failing ever to reach a login prompt on the console tty. The last message on the screen is: A start job is running for Hold until boot process finished up followed by a timer that simply increases without end and says "no limit". How do I find out what is causing this? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Q: how to stop konsole hiding cursor in buster/stable?
After five seconds, konsole hides the cursor if it's within the window boundary. Can anyone tell me where the setting is to stop the cursor from being hidden? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: enigmail
D. R. Evans wrote on 11/18/19 12:57 PM: > I see that the update to debian stable that I was going to do today wants to > update thunderbird but remove enigmail. Does anyone have any insight into how > long it is likely to take before enigmail will be made compatible with the > thunderbird that debian stable wants to install? > For those who care, these are probably the best threads to follow regarding resolution of this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945014 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945066 Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
enigmail
I see that the update to debian stable that I was going to do today wants to update thunderbird but remove enigmail. Does anyone have any insight into how long it is likely to take before enigmail will be made compatible with the thunderbird that debian stable wants to install? I remember that this happened once before, and it seemed like a very long (weeks rather than days, if I'm remembering correctly) before I could run the update. I hope it won't be as long this time. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: intel video
D. R. Evans wrote on 11/11/19 5:32 PM: > Felix Miata wrote on 11/11/19 4:58 PM: >> D. R. Evans composed on 2019-11-11 16:04 (UTC-0700): >> >>> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304 >>> resolution. >> >>> Any suggestions as to what I might need to do to improve at least the >>> logged-in resolution? >> >> >> At the grub menu use the E key to edit the linux line to include >> video=1920x1080 Bingo! (Actually 1920x1200). So I've added that to /etc/default/grub, and run update-grub, and now it looks fine once I log in. (For some reason, the actual login screen is still low-res; it looks ugly, but I can live with that unless someone wants to offer a suggestion to fix it.) Thanks so much. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: intel video
Felix Miata wrote on 11/11/19 4:58 PM: > D. R. Evans composed on 2019-11-11 16:04 (UTC-0700): > >> The chip is an E3-1245, which is supposed to be able to operate at 4096x2304 >> resolution. > >> Any suggestions as to what I might need to do to improve at least the >> logged-in resolution? > > Try a different video cable type if you can. > > pastebinit /var/log/Xorg.0.log > or > pastebinit ~/.local/share/xorg/Xorg.0.log > > whichever of the two exists and is the newer if both exist. From there we > might be > able to turn an error message into a solution. Only the first exists: http://paste.debian.net/1115831/ > > At the grub menu use the E key to edit the linux line to include > > plymouth.enable=0 > and/or > video=1920x1080 > I'll try those when I'm free to reboot the machine a couple of times, which should be in two or three hours or so. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: intel video
Michael Lange wrote on 11/11/19 4:11 PM: > (...) >> The chip is an E3-1245, which is supposed to be able to operate at >> 4096x2304 resolution. >> >> Any suggestions as to what I might need to do to improve at least the >> logged-in resolution? >> > > just a guess: maybe some firmware file(s) from the nonfree firmware > package are missing? > Do you have any idea how I would find out if there are any such files missing? Looking at the names and descriptions, I don't see anything obvious that would help; but that might not mean much. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: intel video
Felix Miata wrote on 11/11/19 4:08 PM: > D. R. Evans composed on 2019-11-11 16:04 (UTC-0700): > >> Any suggestions as to what I might need to do to improve at least the >> logged-in resolution? > > Make sure your kernel cmdline does not include nomodeset. Sometimes it is > necessary for installation to work, but when it remains on the installed > system it > is a big handicap: > <https://en.opensuse.org/SDB:Nomodeset:_Work_Around_Graphic_Upgrade_&_Installation_Obstacles> > No, there's nothing like that in /etc/default/grub, which I assume is where I needed to look. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
intel video
I just installed buster on a new machine (well, new to me; I think that the mobo is two or three years old). The GUI splash screen comes up with very large icons (i.e., it's low res), and once I am logged in, the (KDE) function to control the size of display provides nothing higher than 1600x1200. My other two (non-Intel) buster systems on the same monitor happily generate a high-res login screen and operate at 1920x1280 once I'm logged in (possibly that's the resolution of the login screen as well; I don't know how to determine the log-in resolution). It's an Intel chipset. The installation procedure installed xserver-xorg-video-intel, which suggests removing that package if one's system is newer than 2007, and letting the X server handle everything. So I removed that package and rebooted, but nothing obvious changed: still a low-res login screen and a logged-in display limited to 1600x1200. The chip is an E3-1245, which is supposed to be able to operate at 4096x2304 resolution. Any suggestions as to what I might need to do to improve at least the logged-in resolution? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: OT: Missing sidebar; was buster: multiple instances of konqueror?
R.Lewis wrote on 9/7/19 8:14 AM: > I'm glad to see that you have solved your problem with konqueror, and I'm > wondering if you can help me with mine. > > Do you have a sidebar (F9)? If you do, how did you get it? > Nope. I saw your original question, and have no solution for you, I'm afraid. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: multiple instances of konqueror?
Curt wrote on 9/7/19 5:37 AM: > On 2019-09-01, D. R. Evans wrote: >> >> How do I configure konqueror in buster so that I can run more than one >> instance? > > > Settings-Configure Konqueror-Performance- > Disable 'Always try to have one preloaded instance' > Quit > Kill all residual konqueror processes. > Nope; that did not fix it. I had tried that before I asked here. :-) That just affects whether it stays in memory when you quit, which isn't the same thing as running multiple instances. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: multiple instances of konqueror?
Étienne Mollier wrote on 9/5/19 1:38 PM: > On my side, the window manager happily brings up the first > konqueror window having been started, and the "konqueror" > command gives back the hand to the shell, instead of spawning a > new window, which I believe is the expected behaviour ? > I'm afraid that I don't understand what you are asking. > According to my few tests and browsing diverse konqueror related > documents, it would seem that running several konqueror > processes is technically prevented by various means, probably > on purpose. I wonder why? This is new behaviour, at least on my systems. In the past, multiple instances of konqueror peacefully co-existed and did exactly what one would naïvely expect. For years I have configured a the keyboard shortcut "alt-S" to be the command "konqueror", and have been able to start as many instances (processes) as I want with that method. For example: I am typing this on a stretch system. And between typing that last sentence and this one, I created five instances of konqueror. They all work perfectly. I've used konqueror since the old Mandrake days (somewhere around 2002 is my best guess). Multiple instances have always worked fine before on my systems. I find the change very mysterious... and the lack of documentation anywhere I can find to justify, or even describe this new behaviour, equally puzzling. > Perhaps you can work this around some way or > another, depending on your use case. If by "instances", you > mean: By "instances" I meant "processes". I'm sorry that that wasn't clear. > $ konqueror . # brings up a new window showing the CWD > I just spent some time experimenting, and indeed I found a way to get the behaviour I've always seen before: If I map "alt-S" to "konqueror " instead of just "konqueror" then it seems perfectly happy to start multiple instances. So the problem is solved -- if not understood -- and I thank you for this clue. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: multiple instances of konqueror?
Dan Ritter wrote on 9/5/19 9:36 AM: > D. R. Evans wrote: >> D. R. Evans wrote on 9/1/19 8:51 AM: >>> How do I configure konqueror in buster so that I can run more than one >>> instance? >>> >> >> I haven't seen any responses to this. Is it perhaps, for reasons I can't even >> begin to guess, by design not even possible to run multiple instances of >> konqueror under buster?? Or (I hope) am I just missing some simple >> configuration option? > > I've never used konqueror, but a good first question is: how do > you expect to run multiple instances of konqueror elsewhere? > Either type "konqueror" at the command line, or select "Konqueror" from the normal KDE menu system. > What error messages do you get when trying the same thing in > buster? > None. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: buster: multiple instances of konqueror?
D. R. Evans wrote on 9/1/19 8:51 AM: > How do I configure konqueror in buster so that I can run more than one > instance? > I haven't seen any responses to this. Is it perhaps, for reasons I can't even begin to guess, by design not even possible to run multiple instances of konqueror under buster?? Or (I hope) am I just missing some simple configuration option? Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
