Re: loss of screen resolution
Kleene, Steven (kleenesj) composed on 2022-12-02 02:41 (UTC): ... Your old Xorg.0.logs differ significantly from your current ones, and my own on a similar Intel GPU. In what follows, the current ones and the old ones omit everything between the first and last lines: * [ 2059.607] (II) modeset(0): EDID for output VGA-1 [ 2059.607] (II) modeset(0): Manufacturer: DEL Model: a079 Serial#: 810693964 [ 2059.607] (II) modeset(0): Year: 2014 Week: 24 [ 2059.607] (II) modeset(0): EDID Version: 1.3 [ 2059.607] (II) modeset(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V [ 2059.607] (II) modeset(0): Sync: Separate Composite SyncOnGreen [ 2059.607] (II) modeset(0): Max Image Size [cm]: horiz.: 52 vert.: 32 [ 2059.607] (II) modeset(0): Gamma: 2.20 [ 2059.607] (II) modeset(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display [ 2059.607] (II) modeset(0): First detailed timing is preferred mode [ 2059.607] (II) modeset(0): redX: 0.640 redY: 0.330 greenX: 0.300 greenY: 0.600 [ 2059.607] (II) modeset(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 [ 2059.607] (II) modeset(0): Supported established timings: [ 2059.607] (II) modeset(0): 720x400@70Hz [ 2059.607] (II) modeset(0): 640x480@60Hz [ 2059.607] (II) modeset(0): 800x600@60Hz [ 2059.607] (II) modeset(0): 1024x768@60Hz [ 2059.607] (II) modeset(0): Manufacturer's mask: 0 [ 2059.607] (II) modeset(0): Supported standard timings: [ 2059.607] (II) modeset(0): #0: hsize: 1280 vsize 960 refresh: 60 vid: 16513 [ 2059.607] (II) modeset(0): #1: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [ 2059.607] (II) modeset(0): #2: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 [ 2059.607] (II) modeset(0): #3: hsize: 1680 vsize 1050 refresh: 60 vid: 179 [ 2059.607] (II) modeset(0): #4: hsize: 1920 vsize 1080 refresh: 60 vid: 49361 [ 2059.607] (II) modeset(0): Supported detailed timing: [ 2059.607] (II) modeset(0): clock: 154.0 MHz Image Size: 518 x 324 mm [ 2059.607] (II) modeset(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080 h_border: 0 [ 2059.607] (II) modeset(0): v_active: 1200 v_sync: 1203 v_sync_end 1209 v_blanking: 1235 v_border: 0 [ 2059.607] (II) modeset(0): Serial No: YMYH146D0R5L [ 2059.607] (II) modeset(0): Monitor name: DELL U2412M [ 2059.608] (II) modeset(0): Ranges: V min: 50 V max: 61 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz [ 2059.608] (II) modeset(0): EDID (in hex): [ 2059.608] (II) modeset(0): 000010ac79a04c355230 [ 2059.608] (II) modeset(0): 181801030e342078eaee95a3544c9926 [ 2059.608] (II) modeset(0): 0f5054a1080081408180a940b300d1c0 [ 2059.608] (II) modeset(0): 010101010101283c80a070b023403020 [ 2059.608] (II) modeset(0): 36000644211a00ff00594d59 [ 2059.608] (II) modeset(0): 48313436443052354c0a00fc0044 [ 2059.608] (II) modeset(0): 454c4c2055323431324d0a2000fd [ 2059.608] (II) modeset(0): 00323d1e5311000a2020202020200092 [ 2059.608] (II) modeset(0): Printing probed modes for output VGA-1 * This suggests to me your EDID is currently being misread or is incomplete. Does your VGA cable have 15 pins on both ends, or only 14? Do you have another VGA cable you could try? Do you have any other PCs with VGA output available that you could test with your display? Do you have a FullHD TV with VGA input you could test 1920x1080 with? Perhaps your cable simply could use a removal and refitting. Something to try: switch display driver from modesetting to intel. If xserver-xorg-video-intel is not installed, it should be used automatically if you install it. If it's already installed, then likely there's a .conf file in /etc/X11/xorg.conf.d/ specifically calling it that you could switch to calling intel instead. The modesetting display driver is newer technology developed in large part by Intel's driver programmers, and is responsible for the intel display driver not having an official release in nearly a decade. Sometimes it works better, or at least works when the modesetting driver has a bug, but the modesetting is actually the default for AMD, Intel, NVidia and all other GPUs for which a KMS module exists. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: problem getting debian live to run
On Thursday, December 1, 2022, 10:12:21 PM GMT+1, Andrew M.A. Cater wrote: On Thu, Dec 01, 2022 at 08:43:29PM +, L Dimov wrote: > On Thursday, December 1, 2022 at 03:28:33 PM EST, Andrew M.A. Cater > wrote: > > On Thu, Dec 01, 2022 at 06:58:11PM +, L Dimov wrote: > > I am trying to run debian stable (11.5) live on a new Dell XPS laptop from > > a USB drive. After the Debian logo displays for a bout a minute, I get this > > text: > > > > DPC: RP PIO log size 0 is invalid > > thunderbolt 0-0: reading DROM failed > > BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash) > > Enter 'help' for list of built-in commans. > > (initramsfs) _ > > > > I tried it multiple times, including first formatting the USB as a FAT32. > > None of that helped. > > > > Any help in getting this party started will be greatly appreciated! > > Thanks! > > Luben > > > > Exactly how did you copy the image onto the USB stick - what command did > you use and did you wait until it had copied fully? > > Andy Cater > > Andy, I did wait till it was done indeed. I copied the image to the USB with: > dd if=/home/luben/Downloads/debian-live-11.5.0-amd64-gnome.iso of=/dev/sdb > bs=8M; sync > I tried it without the: > > bs=8M; sync > as well. > Two things: I'd suggest that you try using the unofficial .iso that includes the firmware. https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0-live+nonfree/amd64/iso-hybrid/ - and pick your desktop from under there. Andrew, Thomas, and David: Thank you for the suggestions. The suggestions at https://docs.kernel.org/admin-guide/thunderbolt.html did not help, unfortunately. I also got the same result with live-nonfree. I am however able to get Linux Mint to run live (tho I didn't install it because I want Debian), so I think it is a Debian issue. I tried Debian testing as well - also a no-go. I also tried installing (rather than running live) Debian stable and testing and with and without non-free, to no avail: during installation I get these error messages: "No kernel modules were found. This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive. You should make sure that your installation image is up-to-date, or - if that's the case, try a different mirror, preferably deb.debian.org" and later: "Software RAID not available. The current kernel doesn't seem to support software RAID (MD) devices. This should be solved by loading the necessary modules" as well as: "The current kernel doesn't support the Logical Volume Manager. You may need to load the lvm-mod module." Based on all that, sounds like lack of current hardware support in Debian for this machine because it is so new? I have the output of lshw, if that would help. Thanks, L I'd also suggest dd if=/home/luben/Downloads/[whatever] of=/dev/sdb bs=4M oflag=sync status=progress The oflag=sync forces the sync but status=progress also gives you a figure for what's actually being written to the stick. I try hard not to use the live CD but to use the normal Debian installer instead. > Thanks,Luben > All best, Andy Cater
Re: loss of screen resolution
Kleene, Steven (kleenesj) composed on 2022-12-02 02:41 (UTC): See if adding the following file helps: --- # cat /etc/X11/xorg.conf.d/25-intelExtra.conf Section "Device" Identifier "IntelKludges" Option "ReprobeOutputs" "on" # default off EndSection --- "(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support" from your logs puzzles me. :( Is this in a VM? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: pb wifi en installant sur Asus vivobook 14
Le 02/12/2022 à 12:19, Pierre Couderc a écrit : Merci, en fait , je n'en suis pas encore là, j'en suis à comprendre pouruqoi mon interface que je trouve dans lspci, n'est pas listé par iwlist... Je prefere ne pas utiliser network-manager mais seulement wpa-supplicant. Mais il fuat que j'arrive à detecter cette santée interface... est-ce que tu as regardé dans ce qu'affiche la commande dmesg. Quelques fois il indique quel fichier manque quand il a détecté la carte. Et sinon il affiche des informations sur la carte détectée.
Re: GPG problems
On Sat, Dec 3, 2022 at 12:42 PM Alain D D Williams wrote: > > I am running Debian 10 (buster). I generated a new key that I wanted to > upload, > but it fails: > > $ gpg --send-keys 0xBA366B977C06BAF7 > gpg: sending key 0xBA366B977C06BAF7 to hkps://keys.openpgp.org > gpg: keyserver send failed: Server indicated a failure > gpg: keyserver send failed: Server indicated a failure > > I copied my ~/.gnupg to a Debian 11 (bullesys) machine, it works: > > $ gpg --send-keys 0xBA366B977C06BAF7 > gpg: sending key 0xBA366B977C06BAF7 to hkps://keys.openpgp.org > $ > > Back on buster I grabbed the latest version: > /etc/apt/sources.list: > deb http://deb.debian.org/debian/ buster-backports main contrib > non-free > # apt -V -t=buster-backports install gpg > > I killed the dirmngr daemon: > > # killall dirmngr > > I tried the send-keys again and got the same result, ie failure. > > Please: what should I do to fix this. keys.openpgp.org should be operational. It responds to ping. Also have a look at https://lists.gnupg.org/pipermail/gnupg-users/2021-June/065261.html . Jeff
Re: DNSSEC working but SSHFP reported as insecure
On Sat, 2022-12-03 at 12:09 -0700, Casey Deccio wrote: > > > On Dec 3, 2022, at 9:22 AM, Andre Rodier wrote: > > > > > ssh -o VerifyHostKeyDNS=yes main.homebox.world > > > > Yes, this is the default option in my ssh/config file. > > > > I tried on the command line as well, but same result: > > It could be that your default DNS resolver is not validating. ssh simply > looks at the result of the DNSSEC validation > provided by your default resolver [1], so if it's not validating then you > will never get "secure". In the example in > your original post, you queried 1.1.1.1, which is a validating resolver. But > your default resolver might yield > different results. To test, do the following: > > $ dig +dnssec main.homebox.world sshfp > > And look for the presence of the "ad" (authenticated data) flag in the > response. > > Casey > > [1] https://github.com/openssh/openssh-portable/blob/master/dns.c#L230 Thanks for your suggestion. I was already using 1.1.1.1 in /etc/resolv.conf, when I had the issue. I am running Debian Bullseye. Kind regards, André
Re: loss of screen resolution
On December 1, 2022 9:41 PM, I wrote: >> Out of the blue today, my usual screen resolution (1920x1200) became >> unavailable. ... On December 3, 2022 1:23 PM, Felix Miata wrote: > This and http://paste.debian.net/1262700/ are the same log created Sat Jul 3 > 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from /var/log/ then > look in ~/.local/share/xorg/ for a current one. Sorry, I should have noticed that. Here are the contents of ~/.local/share/xorg/Xorg.0.log, first from the console after a fresh boot: http://paste.debian.net/1262763/ then after calling startx and coming up 1024x768: http://paste.debian.net/1262764/ and finally after using xrandr to get 1920x1200: http://paste.debian.net/1262765/ The second and third files only differ by one line at the end. Thanks. From: Felix Miata Sent: Saturday, December 3, 2022 1:23 PM To: debian-user@lists.debian.org Subject: Re: loss of screen resolution External Email: Use Caution Kleene, Steven (kleenesj) composed on 2022-12-03 14:15 (UTC): > For Xorg.0.log, > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262735%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Cfb8f5bce786f42dc921308dad55c42f3%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056889486652349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cEu7XkZUJn3VOTiLcdvcVEvidGKsA8RLvXd1kUf7oR8%3Dreserved=0 This and https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262700%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Cfb8f5bce786f42dc921308dad55c42f3%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056889486652349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6zqt%2FcKItF3u%2BCd7nzEQOizl9DeiksEDaNBS6BHpUb0%3Dreserved=0 are the same log created Sat Jul 3 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from /var/log/ then look in ~/.local/share/xorg/ for a current one. Current kernel is 4.19.0-22-amd64. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: DNSSEC working but SSHFP reported as insecure
> On Dec 3, 2022, at 9:22 AM, Andre Rodier wrote: > >> ssh -o VerifyHostKeyDNS=yes main.homebox.world > > Yes, this is the default option in my ssh/config file. > > I tried on the command line as well, but same result: It could be that your default DNS resolver is not validating. ssh simply looks at the result of the DNSSEC validation provided by your default resolver [1], so if it's not validating then you will never get "secure". In the example in your original post, you queried 1.1.1.1, which is a validating resolver. But your default resolver might yield different results. To test, do the following: $ dig +dnssec main.homebox.world sshfp And look for the presence of the "ad" (authenticated data) flag in the response. Casey [1] https://github.com/openssh/openssh-portable/blob/master/dns.c#L230
Re: Logout at apt upgrade
On Sat 03 Dec 2022 at 08:19:48 (+0100), Loïc Grenié wrote: > On Sat Dec, 3, 2022 at 04:03, David Wright wrote: > > Yes, hence my comment on potential interactions between different > > packages. The OP mentioned udev, but in their OP they talked about > > manually restarting systemd services. I was under the impression > > that systemd and udev are upgraded in step, and AFAICT (as I'm not > > running bookworm or sid), they've had half a dozen upgrades in the > > last two months. Plenty of scope for interactions there. > > I run sid and am usually able to resolve the problems by myself. > The fact is that during some upgrades X gets killed unexpectedly, > without any warning, and on the console I see that some services > do not start. The obvious questions are which services, and are they consistently the same ones. > I usually reboot but it's annoying; a couple of kills ago > I tried to manually restart the failed services, and it's very time > consuming. > I still don't know *what upgrade(s)* kill(s) X. I have suspected > logind, libpam and udev, but I don't know for sure. I'll try udevadm > monitor as you suggested. > > Hence I asked if anybody else experienced the same behaviour, > and implicitly what I could do to prevent those X kills. An obvious answer is to shut down X yourself in order to see whether there's any link between X being killed and whether/which services fail to restart. Inevitably, this raises the question of why you might not want to shut down X for upgrades. (I fall in the camp of people who boot systems/start X/etc into known initial states. There is an opposite camp that prefers the restoration of the previous state of the system/their session. I believe there are packages to help with this, but I'm not familiar with them. My sole (and partial) exception is Firefox.) Beyond these generalities about note-taking/reporting and problem disection, I'm still not much help on the specifics. Cheers, David.
Re: loss of screen resolution
Kleene, Steven (kleenesj) composed on 2022-12-03 14:15 (UTC): > For Xorg.0.log, > http://paste.debian.net/1262735/ This and http://paste.debian.net/1262700/ are the same log created Sat Jul 3 16:37:19 2021 using kernel 4.19.0-17-amd64. If these are from /var/log/ then look in ~/.local/share/xorg/ for a current one. Current kernel is 4.19.0-22-amd64. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
GPG problems
I am running Debian 10 (buster). I generated a new key that I wanted to upload, but it fails: $ gpg --send-keys 0xBA366B977C06BAF7 gpg: sending key 0xBA366B977C06BAF7 to hkps://keys.openpgp.org gpg: keyserver send failed: Server indicated a failure gpg: keyserver send failed: Server indicated a failure I copied my ~/.gnupg to a Debian 11 (bullesys) machine, it works: $ gpg --send-keys 0xBA366B977C06BAF7 gpg: sending key 0xBA366B977C06BAF7 to hkps://keys.openpgp.org $ Back on buster I grabbed the latest version: /etc/apt/sources.list: deb http://deb.debian.org/debian/ buster-backports main contrib non-free # apt -V -t=buster-backports install gpg I killed the dirmngr daemon: # killall dirmngr I tried the send-keys again and got the same result, ie failure. Please: what should I do to fix this. Thanks in advance -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html #include
Re: DNSSEC working but SSHFP reported as insecure
On Sat, 2022-12-03 at 09:19 -0700, Casey Deccio wrote: > ssh -o VerifyHostKeyDNS=yes main.homebox.world Yes, this is the default option in my ssh/config file. I tried on the command line as well, but same result: > ssh -o VerifyHostKeyDNS=yes main.homebox.world > The authenticity of host 'main.homebox.world (78.141.231.71)' can't > be established. > ECDSA key fingerprint is > SHA256:T23Vm3xnHp/jJlBXrvdrxEiu91pPzjVRPBfGLpu5yPY. > Matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no/[fingerprint])? > ^C
Re: DNSSEC working but SSHFP reported as insecure
> On Dec 3, 2022, at 8:30 AM, Andre Rodier wrote: > > Where am I making a mistake, please ? The DNSSEC looks fine. That is, there is a secure chain from the root to the SSHFP record (see below). Have you tried adding the VerifyHostKeyDNS=yes option? ssh -o VerifyHostKeyDNS=yes main.homebox.world Casey [1] $ dnsviz probe -a . -A -R sshfp main.homebox.world | dnsviz print No global IPv6 connectivity detected Analyzing . Analyzing world Analyzing homebox.world Analyzing main.homebox.world . [.] [.] DNSKEY: 8/20326/257 [.], 8/18733/256 [.] [.]RRSIG: ./8/20326 (2022-11-30 - 2022-12-21) [.] world [.] [.] [.] DS: 8/13081/2 [.] [.]RRSIG: ./8/18733 (2022-12-03 - 2022-12-16) [.] [.] DNSKEY: 8/13081/257 [.], 8/5436/256 [.], 8/60063/256 [.] [.]RRSIG: world/8/13081 (2022-12-01 - 2022-12-22) [.] homebox.world [.] [.] [.] DS: 13/8704/2 [.], 13/19691/2 [.], 13/45407/2 [.] [.]RRSIG: world/8/5436 (2022-12-02 - 2022-12-23) [.] [.] DNSKEY: 13/19691/257 [.], 13/45407/256 [.], 13/8704/257 [.] [.]RRSIG: homebox.world/13/8704 (2022-11-24 - 2022-12-15) [.] [.]RRSIG: homebox.world/13/19691 (2022-11-24 - 2022-12-15) [.] main.homebox.world [.] SSHFP: 1 2 7cf3701693baeb8406fd0db7182e01bbadc1f639ba4fc2ca7224116cc9d237dc, 2 1 eb09a2823e9d8a51ef7fe3260e0890a56924da6f, 3 1 142f2a695a2e06cabab6e19800657c3f0b28301d, 4 1 35d346e05d1351a78868e033ebe736c3030d3551, 4 2 052736c5f2e6dce7d41aeeb7f41dbce01d19d2ac9e9ccffab79fb37ab85ce335, 2 2 c3cdd443653530c94c1b90511f3e07ce8fe1fcbbcd60e37729543a577b0a5a44, 3 2 4f6dd59b7c671e9fe3265057aef76bc448aef75a4fce35513c17c62e9bb9c8f6, 1 1 ea89f6c8c8eda5e29e913f4448a816a19624d125 [.]RRSIG: homebox.world/13/45407 (2022-11-24 - 2022-12-15) [.]
Re: Touchpad synaptics changes name after resume
On Sat 03 Dec 2022 at 10:37:50 (+), Ottavio Caruso wrote: > $ uname -a > Linux t440 6.0.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 6.0.3-1~bpo11+1 (2022-10-29) x86_64 GNU/Linux > > I have two scripts that enable/disable touchpad that I mapped to some > keyboard shortcuts: > > $ cat ~/opt/bin/touchpad-on > xinput enable "SynPS/2 Synaptics TouchPad" > $ cat ~/opt/bin/touchpad-off > xinput disable "SynPS/2 Synaptics TouchPad" > > The problem is that xinput(1) changes the name of the touchpad every > now and again: > > $ dmesg| grep -i synaptics |grep "as /devices" > [463340.358242] input: Synaptics TM2722-001 as > /devices/pci:00/:00:1f.3/i2c-0/0-002c/rmi4-00/input/input319 > [505228.803682] input: SynPS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input335 > [505234.019989] input: SynPS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input338 > > That is, it alternates between "Synaptics TM2722-001" and "SynPS/2 > Synaptics TouchPad". > > Even the id changes. Sometimes it's 11, some other times it's 10 or 9. As a workaround, how about trying: $ cat ~/opt/bin/touchpad-on xinput enable "SynPS/2 Synaptics TouchPad" xinput enable "Synaptics TM2722-001" $ cat ~/opt/bin/touchpad-off xinput disable "SynPS/2 Synaptics TouchPad" xinput disable "Synaptics TM2722-001" > The culprit may be this custom script: > > $ cat/lib/systemd/system-sleep/custom > #!/bin/sh > > case $1 in > pre) > systemctl stop ssh > ifconfig wlp3s0 off > sleep 5 > ;; > post) > sleep 5 > modprobe -r psmouse && > modprobe psmouse > modprobe -r rmi_smbus && > modprobe rmi_smbus > ifconfig wlp3s0 on > ;; > esac > > See the "modprobe"'s? I need them, because there is an outstanding bug > in the kernel that shuts the input drivers on resume on some > Thinkpads. How did you choose the order of your modprobes? I'm wondering whether the way psmouse configures the Synaptics is influenced by the presence of modules that drive the busses. But I'm afraid I'm just guessing. Cheers, David.
Re: DNSSEC working but SSHFP reported as insecure
On Sat, 2022-12-03 at 15:48 +, John Scott wrote: > > Where am I making a mistake, please ? > > I think I know the problem. On the client machine, by default glibc > doesn't indicate to applications that DNS records were signed via > DNSSEC. This is because, how is glibc to know whether the DNS servers > it's getting its records from is supposed to be considered > trustworthy? It might be some DNS server set up by your ISP or > something, and you might not want to place your full trust in them. > > I believe your server is configured correctly. However, in order for > GNU/Linux clients to take advantage of DNSSEC, they typically need to > run validating DNS resolvers locally that can be trusted, AND set a > glibc option in /etc/resolv.conf letting glibc know that the > signatures can be trusted. > > I'm not a DNS aficionado, so someone please correct me if I got the > details wrong Thanks, John, I am following this clue. Kind regards, André
Re: DNSSEC working but SSHFP reported as insecure
> Where am I making a mistake, please ? I think I know the problem. On the client machine, by default glibc doesn't indicate to applications that DNS records were signed via DNSSEC. This is because, how is glibc to know whether the DNS servers it's getting its records from is supposed to be considered trustworthy? It might be some DNS server set up by your ISP or something, and you might not want to place your full trust in them. I believe your server is configured correctly. However, in order for GNU/Linux clients to take advantage of DNSSEC, they typically need to run validating DNS resolvers locally that can be trusted, AND set a glibc option in /etc/resolv.conf letting glibc know that the signatures can be trusted. I'm not a DNS aficionado, so someone please correct me if I got the details wrong signature.asc Description: This is a digitally signed message part
DNSSEC working but SSHFP reported as insecure
Hello, all. I have implemented DNSSEC successfully (apparently) on a test box (using PowerDNS, btw). We can see the test here: https://dnssec-debugger.verisignlabs.com/homebox.world I have set my SSHFP records correctly (I think): > dig +dnssec -t SSHFP main.homebox.world @1.1.1.1 > ; <<>> DiG 9.18.8-1~bpo11+1-Debian <<>> +dnssec -t SSHFP > main.homebox.world @1.1.1.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26002 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: > 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ;; QUESTION SECTION: > ;main.homebox.world.IN SSHFP > > ;; ANSWER SECTION: > main.homebox.world. 3600IN SSHFP 1 1 > EA89F6C8C8EDA5E29E913F4448A816A19624D125 > main.homebox.world. 3600IN SSHFP 1 2 > 7CF3701693BAEB8406FD0DB7182E01BBADC1F639BA4FC2CA7224116C C9D237DC > main.homebox.world. 3600IN SSHFP 2 1 > EB09A2823E9D8A51EF7FE3260E0890A56924DA6F > main.homebox.world. 3600IN SSHFP 2 2 > C3CDD443653530C94C1B90511F3E07CE8FE1FCBBCD60E37729543A57 7B0A5A44 > main.homebox.world. 3600IN SSHFP 3 1 > 142F2A695A2E06CABAB6E19800657C3F0B28301D > main.homebox.world. 3600IN SSHFP 3 2 > 4F6DD59B7C671E9FE3265057AEF76BC448AEF75A4FCE35513C17C62E 9BB9C8F6 > main.homebox.world. 3600IN SSHFP 4 1 > 35D346E05D1351A78868E033EBE736C3030D3551 > main.homebox.world. 3600IN SSHFP 4 2 > 052736C5F2E6DCE7D41AEEB7F41DBCE01D19D2AC9E9CCFFAB79FB37A B85CE335 > main.homebox.world. 3600IN RRSIG SSHFP 13 3 3600 > 2022121500 2022112400 45407 homebox.world. > t30IX78PNMQLWy7g/3Xs8JvEgcwK6dEnxk7MtJZ9Iqk6ATKfZ32u0uPu > nYw8Hi+bkU45qcQ+9gl5iWCOrd3VVA== > > ;; Query time: 52 msec > ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) > ;; WHEN: Sat Dec 03 15:28:26 GMT 2022 > ;; MSG SIZE rcvd: 476 However, when I connect using SSH, the client complains the keys are insecure: > OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n 15 Mar 2022 > debug1: Reading configuration data /home/andre/.ssh/config > debug1: /home/andre/.ssh/config line 21: Applying options for > main.homebox.world > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: include > /etc/ssh/ssh_config.d/*.conf matched no files > debug1: /etc/ssh/ssh_config line 21: Applying options for * > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> > '/home/andre/.ssh/known_hosts' > debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> > '/home/andre/.ssh/known_hosts2' > debug2: resolving "main.homebox.world" port 22 > debug2: ssh_connect_direct > debug1: Connecting to main.homebox.world [78.141.231.71] port 22. > debug1: Connection established. > debug1: identity file /home/andre/.ssh/id_rsa type 0 > debug1: identity file /home/andre/.ssh/id_rsa-cert type -1 > debug1: identity file /home/andre/.ssh/id_dsa type -1 > debug1: identity file /home/andre/.ssh/id_dsa-cert type -1 > debug1: identity file /home/andre/.ssh/id_ecdsa type -1 > debug1: identity file /home/andre/.ssh/id_ecdsa-cert type -1 > debug1: identity file /home/andre/.ssh/id_ecdsa_sk type -1 > debug1: identity file /home/andre/.ssh/id_ecdsa_sk-cert type -1 > debug1: identity file /home/andre/.ssh/id_ed25519 type -1 > debug1: identity file /home/andre/.ssh/id_ed25519-cert type -1 > debug1: identity file /home/andre/.ssh/id_ed25519_sk type -1 > debug1: identity file /home/andre/.ssh/id_ed25519_sk-cert type -1 > debug1: identity file /home/andre/.ssh/id_xmss type -1 > debug1: identity file /home/andre/.ssh/id_xmss-cert type -1 > debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_8.4p1 Debian-5+deb11u1 > debug1: match: OpenSSH_8.4p1 Debian-5+deb11u1 pat OpenSSH* compat > 0x0400 > debug2: fd 3 setting O_NONBLOCK > debug1: Authenticating to main.homebox.world:22 as 'root' > debug3: hostkeys_foreach: reading file "/home/andre/.ssh/known_hosts" > debug3: send packet: type 20 > debug1: SSH2_MSG_KEXINIT sent > debug3: receive packet: type 20 > debug1: SSH2_MSG_KEXINIT received > debug2: local client KEXINIT proposal > debug2: KEX algorithms: curve25519-sha256, > curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2- > nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange- > sha256,diffie-hellman-group16-sha512,diffie-hellman-group18- > sha512,diffie-hellman-group14-sha256,ext-info-c > debug2: host key algorithms: > ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com > , ecdsa-sha2-nistp521-cert-...@openssh.com, > sk-ecdsa-sha2-nistp256-cert-...@openssh.com, > ssh-ed25519-cert-...@openssh.com,sk-ssh-ed25519-cert-...@openssh.com, > rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com, > ssh-rsa-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2- >
Re: loss of screen resolution
On December 1, 2022 9:41 PM, I wrote: >>> Out of the blue today, my usual screen resolution (1920x1200) became >>> unavailable. ... On December 2, 2022 10:12 AM, Felix Miata wrote: >> ... run >> inxi -U >> to upgrade, and post here output from within an X terminal: >> inxi -GSaz >> ... >> Next, give us the whole log to see: cat /var/log/Xorg.0.log | pastebinit And on December 3, 2022 1:14 AM, Felix Miata added: > Did these result after applying your xrandr workaround? If the problem > remains in absence of the workaround, the inxi and log need to come from > being in that condition. I had done those after the workaround. So I exited fvwm back to the console, recalled fvwm via startx, and gathered the information again before doing the workaround. inxi -> System: Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc v: 8.3.0 parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-22-amd64 root=UUID=093750e2-4489-4550-a3fc-5e86b450320b ro quiet Desktop: FVWM v: 2.6.8 vt: 1 dm: startx Distro: Debian GNU/Linux 10 (buster) Graphics: Device-1: Intel 82946GZ/GL Integrated Graphics driver: i915 v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports: active: VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2972 class-ID: 0300 Display: server: X.Org v: 1.20.4 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: i965 gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 270x203mm (10.63x7.99") s-diag: 338mm (13.3") Monitor-1: VGA-1 res: 1024x768 hz: 60 size: N/A modes: max: 1024x768 min: 640x480 API: OpenGL v: 2.1 Mesa 18.3.6 renderer: Mesa DRI Intel 946GZ direct render: Yes This is the same as before except showing 1024x768 instead of 1920x1200. For Xorg.0.log, http://paste.debian.net/1262735/ Thanks again. From: Felix Miata Sent: Saturday, December 3, 2022 1:14 AM To: debian-user@lists.debian.org Subject: Re: loss of screen resolution External Email: Use Caution Kleene, Steven (kleenesj) composed on 2022-12-02 02:20 (UTC): >> Next, give us the whole log to see: > cat /var/log/Xorg.0.log | pastebinit > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpaste.debian.net%2F1262700%2Fdata=05%7C01%7Ckleenesj%40ucmail.uc.edu%7Ccfc9a461f864488b9b7108dad4f5c190%7Cf5222e6c5fc648eb8f0373db18203b63%7C1%7C0%7C638056449240692027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=pQ9QP%2BuDQ2%2BjbzxZB815Oo2YL8z022xO%2BTjkzHaH1%2BE%3Dreserved=0 > That's a lot to look at. Thank you. I don't see anything to suggest that there's anything wrong. Did these result after applying your xrandr workaround? If the problem remains in absence of the workaround, the inxi and log need to come from being in that condition. I have something similar needing no correction or workaround: # inxi -GSaz --vs --zl --hostname inxi 3.3.23-00 (2022-10-31) System: Host: gx62b Kernel: 4.19.0-22-amd64 arch: x86_64 bits: 64 compiler: gcc v: 8.3.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0 biosdevname=0 plymouth.enable=0 noresume mitigations=auto consoleblank=0 Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0 vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux 10 (buster) Graphics: Device-1: Intel 82945G/GZ Integrated Graphics vendor: Dell driver: i915 v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports: active: DVI-D-1,VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:2772 class-ID: 0300 Display: x11 server: X.Org v: 1.20.4 driver: X: loaded: intel unloaded: fbdev,modesetting,vesa dri: i915 gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00") s-diag: 803mm (31.62") Monitor-1: DVI-D-1 mapped: DVI1 pos: primary,left model: NEC EA243WM serial: built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 size: 520x320mm (20.47x12.6") diag: 612mm (24.1") ratio: 16:10 modes: max: 1920x1200 min: 640x480 Monitor-2: VGA-1 mapped: VGA1 pos: right model: Dell P2213 serial: built: 2012 res: 1680x1050 hz: 60 dpi: 91 gamma: 1.2 size: 470x300mm (18.5x11.81") diag: 558mm (22") ratio: 16:10 modes: max: 1680x1050 min: 720x400 API: OpenGL v: 1.4 Mesa 18.3.6 renderer: Mesa DRI Intel 945G direct render: Yes -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: Touchpad synaptics changes name after resume
* Ottavio Caruso [22-12/03=Sa 10:37 +]: > $ uname -a > Linux t440 6.0.0-0.deb11.2-amd64 #1 SMP PREEMPT_DYNAMIC Debian > 6.0.3-1~bpo11+1 (2022-10-29) x86_64 GNU/Linux > > I have two scripts that enable/disable touchpad > [running the commands] > xinput enable "SynPS/2 Synaptics TouchPad" > xinput disable "SynPS/2 Synaptics TouchPad" > > The problem is that xinput(1) changes the > name of the touchpad every now and again: > > $ dmesg| grep -i synaptics |grep "as /devices" > [463340.358242] input: Synaptics TM2722-001 as > /devices/pci:00/:00:1f.3/i2c-0/0-002c/rmi4-00/input/input319 > [505228.803682] input: SynPS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input335 > [505234.019989] input: SynPS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input338 > > [...] Can $(xinput --list) tell you the current name of the device? You may have to grep for "Synaptics" in the output.
