Re: [FIXED] Re: brltty=huge distraction for folks that don't need it.

[Tom Dial]

On 1/3/22 02:46, gene heskett wrote:
> On Monday, January 3, 2022 1:59:56 AM EST john doe wrote:
...

>>
>> It would be nice if you could replicate the issue and file a bug report
>> against the Debian Installer with the D-I logs.
> 
> I appreciate that, but that means I'd have to do a complete re-install from 
> scratch, something I had to do 7 times already as its a full day per install 
> even when most of the storage is now SSD's in raid10 configs. The latest 
> generation of shingled spinning rust is a disaster looking for a place to 
> happen.  And that's just the bare metal install, nowhere near a working 
> system. To redo this system to the state its in now would take around a 
> week. And I still haven't gotten my web page working.

I think that if you did not purposely excise /var/log/installer/* the files 
should still be available. That is the case with my systems that were installed 
from media, some dating to 2006 (or likely earlier; I only checked three).

Regards,
Tom Dial

> 
>> John Doe
> 
> Cheers John, Gene Heskett.
> 

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[tomas]

On Mon, Jan 03, 2022 at 11:01:34PM +0100, local10 wrote:
> Hi,
> 
> Am I the only one who's getting this error? When I go to the USPS.com[1] to 
> track a package I get this "Warning: Potential Security Risk Ahead" error ( 
> Error code: SSL_ERROR_BAD_CERT_DOMAIN ). It's been like this for a couple of 
> weeks for me so it looks really strange that the USPS has fixed it after all 
> this time.
> I tried the same URL[1] in Konqueror and it also complains about the bad 
> certificate.
> 
> Any ideas? Thanks
> 
> 
> 1 .https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890

Seems to work for me (currently). Are you still getting the error?

The error means that the site was offering a cert for the wrong domain.
This could happen for a whole bunch of reasons, someone fat-fingering
something at the server end, someone forgetting to hand out the cert to
the CDN, whatever.

If the error persists on your side, you can try to dig into it by
clicking [1] on the security thingie to the left of the URL bar, then
your browser offers more info about the server cert.

Cheers

[1] Don't you hate GUIs? Describing how to do a simple thing ends up in
   reams of difficult-to-understand text.

-- 
tomás


signature.asc
Description: PGP signature

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David]

On Tue, 4 Jan 2022 at 14:40, David  wrote:

> There are a couple of unexpected aspects to script #2, which I will
> explain ...
>
> a) Script sequencing
>
> or "Why has he put it under /usr ?"
>
> All the PREREQ= and prereqs stuff is a mechanism to control the
> sequencing of scripts in each subdirectory under
> '*/initramfs-toos/scripts/'.
>
> How to use that mechanism will depend on how the other scripts present
> are already using it. Above I left it unused because I had to use a
> different approach, so PREREQ was irrelevant and I never assigned it
> any values. This seems common in other scripts too, when order does
> not matter.
>
> For my situation it was essential to ensure that Step #2 ran before
> the interactive cryptsetup password prompt script in the initrd.
>
> So I had to take note of where that occurs in the whole sequence of
> different subdirectories, and ensure that my script ran before.
>
> And a complicating factor is that 'man initramfs-tools' says:
>
>   Please notice that PREREQ is only honored inside a single directory.
>   So first the scripts in /usr/share/initramfs-tools are ordered
>   according to their PREREQ values and executed. Then all scripts in
>   /etc/initramfs-tools are ordered according to their PREREQ values and
>   executed. This mean that currently there is no possibility to have a
>   local script (/etc/initramfs-tools) get executed before one from the
>   package (/usr/share/initramfs-tools).
>
> Note the last sentence. Even though I suspect it ambiguously
> overstates the problem, that explains why my script *must* be placed
> in '/usr//local-top' subdirectory and not under /etc as would be
> more desirable. I could not see any way to have it under /etc and
> be sure that it would run early enough. I tried that, and it worked.

Realised that I forgot to articulate something important
in that explanation ...

The other "boot script"
  /usr/share/initramfs-tools/scripts/local-top/cryptroot
is what provides the interactive cryptsetup password prompt.
And it contains prereqs() logic to ensure that it runs
*last* of all scripts in that '/usr/.../local-top' directory.

That is why my my_kdbrate script:
- must be in that directory /usr...local-top, so it runs before;
- cannot be placed under /etc, which would run after;
- does not need to specify any PREREQ, already managed.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David]

On Tue, 4 Jan 2022 at 08:42, David Wright  wrote:
> On Mon 03 Jan 2022 at 16:25:47 (+1100), David wrote:

> > So I now run 'kbdrate' inside the initrd. This seems to have
> > solved the problem there and in all subsequent layers.

> I presume you do this by placing something like
>   /sbin/kbdrate -r 8 -d 500 -s
> ± a shebang, into a file like
>   /etc/initramfs-tools/scripts//kbdrate.sh
> Which  is appropriate?

Hi David,

Well, you are on the right track, but it did take quite a bit more
thinking than that for me, because I had to ensure that it ran ahead
of the interactive cryptsetup password prompt script in the initrd,
which was the tricky aspect.

But it all came together quite easily. And that particular issue
might be irrelevant for you, but I will explain it anyway to demystify
some details in the scripts that I share below. And it answers your question.

Anyway, I'm glad you responded to my hint and I encourage you to try it.

See 'man initramfs-tools' for the details.

Aside: everywhere I'm using '/usr/sbin/kbdrate' your system may or may
not require that string to be changed to '/sbin/kbdrate' in any or all
places I give below. You can use a boot parameter 'break=top' to
examine the initrd environment. If I do that, '/sbin' and '/usr/sbin'
contents look the same and
  # echo $PATH
  /sbin:/usr/sbin:/bin/:/usr/bin
so I don't think it matters much. I think maybe I did just specify
'/usr/sbin' in anticipation of the future. The only detail that I have
forgotten is if there is some reason why I have used '/sbin/kbdrate'
in script #2 below. I can't remember.

Anyway, let's talk about the two main steps taken from 'man
initramfs-tools':
Step #1: make '/usr/sbin/kbdrate' available in the initrd filesystem.
Step #2: a script to run '/usr/sbin/kbdrate' at the right time, with
the desired arguments.

Step #1:

is done with what the manpage calls a "configuration hook script".

These contain some boilerplate that I figured out by looking at other
similar scripts in /usr/share/initramfs-tools/hooks, and I came up
with this:

#---
$ sudo cat /etc/initramfs-tools/hooks/my_kbdrate
#!/bin/sh
set -e
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
# Hooks for loading kbdrate software into the initramfs
copy_exec /sbin/kbdrate
exit 0
$
#---

The only line of real interest in that script is the 'copy_exec'
statement. And 'copy_exec' is in the 'hook-functions' file sourced in
the statement before. The rest is boilerplate that does nothing
in this case.

Once this is in place, I can use a boot parameter 'break=top'
to confirm that '/usr/sbin/kbrate' is installed in the initrd.

Step #2:

is done with what the manpage calls a "boot script" and this is what I
came up with:
#---
$ sudo cat /usr/share/initramfs-tools/scripts/local-top/my_kbdrate
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
f="/usr/sbin/kbdrate"
if [ -x "${f}" ]; then
"${f}" -d 700 -r 20 >/dev/null
fi
$
#---

There are a couple of unexpected aspects to script #2, which I will
explain ...

a) Script sequencing

or "Why has he put it under /usr ?"

All the PREREQ= and prereqs stuff is a mechanism to control the
sequencing of scripts in each subdirectory under
'*/initramfs-toos/scripts/'.

How to use that mechanism will depend on how the other scripts present
are already using it. Above I left it unused because I had to use a
different approach, so PREREQ was irrelevant and I never assigned it
any values. This seems common in other scripts too, when order does
not matter.

For my situation it was essential to ensure that Step #2 ran before
the interactive cryptsetup password prompt script in the initrd.

So I had to take note of where that occurs in the whole sequence of
different subdirectories, and ensure that my script ran before.

And a complicating factor is that 'man initramfs-tools' says:

  Please notice that PREREQ is only honored inside a single directory.
  So first the scripts in /usr/share/initramfs-tools are ordered
  according to their PREREQ values and executed. Then all scripts in
  /etc/initramfs-tools are ordered according to their PREREQ values and
  executed. This mean that currently there is no possibility to have a
  local script (/etc/initramfs-tools) get executed before one from the
  package (/usr/share/initramfs-tools).

Note the last sentence. Even though I suspect it ambiguously
overstates the problem, that explains why my script *must* be placed
in '/usr//local-top' subdirectory and not under /etc as would be
more desirable. I could not see any way to have it under /etc and
be sure that it would run early enough. I tried 

Re: couldn't build pipe-viewer with debian

[Jude DaShiell]

I put libreadline-dev on the machine since that wasn't installed and ran
the instructions in the README.md file in pipe-viewer directory and the
whole package built and installed.
Thanks for the pointer on that -dev file.  I'll have to check for those in
the future.


On Mon, 3 Jan 2022, Jude DaShiell wrote:

> I forgot to install the -dev package.  I'll try this again and see if it
> goes through.
>
>
> On Mon, 3 Jan 2022, Greg Wooledge wrote:
>
> > On Mon, Jan 03, 2022 at 07:38:25PM -0500, Jude DaShiell wrote:
> > > pipe-viewer youtube-viewer and straw-viewer cannot be built with debian.
> > > The reasons for that are each of those packages require
> > > Term::ReadLine::Gnu and Term::ReadLine::Gnu cannot be built withreadline
> > > 2.0.  That's an ancient version of readline.  I tried with readline 2.01
> > > and my x86_64 equipment wasn't recognized by that package.  The readline
> > > versions go all the way up to 8.0 by now [...]
> >
> > The version of the libreadline8 package on bullseye is 8.1-1.
> >
> > Is there any chance you're conflating the version number of GNU readline
> > (a C library provided by the bash maintainer, currently version 8.x on
> > bullseye) with some perl package that has "readline" in its name?  Or
> > that you simply forgot to install libreadline-dev?
> >
> > Could you show us the actual error message you get when you try to
> > build it?
> >
> > Also, what's wrong with the libterm-readline-gnu-perl package in Debian?
> > Is it too old or something?
> >
> > unicorn:~$ apt-cache show libterm-readline-gnu-perl
> > Package: libterm-readline-gnu-perl
> > Version: 1.37-1
> > [...]
> >
> > unicorn:~$ apt-cache show libreadline-dev
> > Package: libreadline-dev
> > Source: readline
> > Version: 8.1-1
> > [...]
> >
> >
>
>

Re: couldn't build pipe-viewer with debian

[Jude DaShiell]

I forgot to install the -dev package.  I'll try this again and see if it
goes through.


On Mon, 3 Jan 2022, Greg Wooledge wrote:

> On Mon, Jan 03, 2022 at 07:38:25PM -0500, Jude DaShiell wrote:
> > pipe-viewer youtube-viewer and straw-viewer cannot be built with debian.
> > The reasons for that are each of those packages require
> > Term::ReadLine::Gnu and Term::ReadLine::Gnu cannot be built withreadline
> > 2.0.  That's an ancient version of readline.  I tried with readline 2.01
> > and my x86_64 equipment wasn't recognized by that package.  The readline
> > versions go all the way up to 8.0 by now [...]
>
> The version of the libreadline8 package on bullseye is 8.1-1.
>
> Is there any chance you're conflating the version number of GNU readline
> (a C library provided by the bash maintainer, currently version 8.x on
> bullseye) with some perl package that has "readline" in its name?  Or
> that you simply forgot to install libreadline-dev?
>
> Could you show us the actual error message you get when you try to
> build it?
>
> Also, what's wrong with the libterm-readline-gnu-perl package in Debian?
> Is it too old or something?
>
> unicorn:~$ apt-cache show libterm-readline-gnu-perl
> Package: libterm-readline-gnu-perl
> Version: 1.37-1
> [...]
>
> unicorn:~$ apt-cache show libreadline-dev
> Package: libreadline-dev
> Source: readline
> Version: 8.1-1
> [...]
>
>

Re: why bash completion sometimes doesn't work?

[Greg Wooledge]

On Tue, Jan 04, 2022 at 02:39:24AM +, Long Wind wrote:
> 
> Thank Greg Wooledge!
> 
> it seems solved, 
> there's more whitespace between iface and device name, 
> i correct it to just one space, and bash completion works for ifup/ifdown

Might be worth a bug report.

Re: why bash completion sometimes doesn't work?

[Long Wind]

Thank Greg Wooledge!

it seems solved, 
there's more whitespace between iface and device name, 
i correct it to just one space, and bash completion works for ifup/ifdown

Re: couldn't build pipe-viewer with debian

[Greg Wooledge]

On Mon, Jan 03, 2022 at 07:38:25PM -0500, Jude DaShiell wrote:
> pipe-viewer youtube-viewer and straw-viewer cannot be built with debian.
> The reasons for that are each of those packages require
> Term::ReadLine::Gnu and Term::ReadLine::Gnu cannot be built withreadline
> 2.0.  That's an ancient version of readline.  I tried with readline 2.01
> and my x86_64 equipment wasn't recognized by that package.  The readline
> versions go all the way up to 8.0 by now [...]

The version of the libreadline8 package on bullseye is 8.1-1.

Is there any chance you're conflating the version number of GNU readline
(a C library provided by the bash maintainer, currently version 8.x on
bullseye) with some perl package that has "readline" in its name?  Or
that you simply forgot to install libreadline-dev?

Could you show us the actual error message you get when you try to
build it?

Also, what's wrong with the libterm-readline-gnu-perl package in Debian?
Is it too old or something?

unicorn:~$ apt-cache show libterm-readline-gnu-perl
Package: libterm-readline-gnu-perl
Version: 1.37-1
[...]

unicorn:~$ apt-cache show libreadline-dev
Package: libreadline-dev
Source: readline
Version: 8.1-1
[...]

Re: why bash completion sometimes doesn't work?

[Greg Wooledge]

On Mon, Jan 03, 2022 at 11:56:57PM +, Long Wind wrote:
> Thank Greg and David!
> 
> i type "ifdown ", it add lo automatically,
> wireless device isn't shown, though wireless connection works well
> 
> i think "ip a" can list wireless device

Well, it sounds like _configured_interfaces on your system only finds
"lo", whereas _available_interfaces finds a larger set.

_configured_interfaces is apparently defined in
/usr/share/bash-completion/bash_completion and includes this code:

if [[ -f /etc/debian_version ]]; then
# Debian system
COMPREPLY=($(compgen -W "$(command sed -ne 's|^iface \([^ ]\{1,\}\).*$|\
1|p' \
/etc/network/interfaces /etc/network/interfaces.d/* 2>/dev/null)" \
-- "$cur"))

If I'm reading that sed command correctly, it only works if there is
precisely ONE space between "iface" and the interface name.

Perhaps your iface lines in /etc/network/interfaces are using tabs, or
more than one space, between the word "iface" and the interface name.
If so, that's why this particular bash-completion function doesn't
return it.

It's also possible that your desired interfaces aren't defined in
/etc/network/interfaces at all.  You might be using Network-Manager
instead, on that system.  That's perfectly valid, but this bash-completion
function won't see those interfaces.

The _available_interfaces function (used by dhclient's completion function)
is very different.  It calls "ifconfig -a" or "ip link show" and then
parses names out with awk.  Or at least it tries to.  Obviously that will
give different results, if your interfaces are defined by Network-Manager,
or systemd units, or if you used liberal whitespace, etc.

Have I mentioned yet that bash-completion has some notoriety for being
fragile and a bit broken at times?  I don't use it personally.  If it
works for you, that's great.  But it's far from perfect.

couldn't build pipe-viewer with debian

[Jude DaShiell]

pipe-viewer youtube-viewer and straw-viewer cannot be built with debian.
The reasons for that are each of those packages require
Term::ReadLine::Gnu and Term::ReadLine::Gnu cannot be built withreadline
2.0.  That's an ancient version of readline.  I tried with readline 2.01
and my x86_64 equipment wasn't recognized by that package.  The readline
versions go all the way up to 8.0 by now and maybe some version that
recognizes x86_64 between 2.01 and 8.0 will be compatible with
Term::ReadLine::Gnu but I haven't found that yet.
The pipe-viewer app when it can run on a system allows for browsing and
downloading of youtube videos in a console environment and there's even a
flavor for gtk.  I didn't touch the gtk version since I'm running mostly
console on this system.  https://github.com/trizen/pipe-viewer.git is my
source for what couldn't compile.  This works in archlinux and also in
slint but not yet in debian.  It's a perl build for anyone who would like
to try it too.

Re: brltty=huge distraction for folks that don't need it.

[gene heskett]

On Monday, January 3, 2022 4:42:56 PM EST David Wright wrote:
> On Mon 03 Jan 2022 at 04:33:53 (-0500), gene heskett wrote:
> > On Sunday, January 2, 2022 10:47:08 PM EST David Wright wrote:
> > > On Sun 02 Jan 2022 at 22:31:27 (-0500), gene heskett wrote:
> > > > On Sunday, January 2, 2022 9:54:29 PM EST David Wright wrote:
> > > > > On Sun 02 Jan 2022 at 17:53:19 (-0500), gene heskett wrote:
> > > > > > Without any conscious prompting by me, te debian 11.1 netinstall
> > > > > > for
> > > > > > x86-64 systems installed and setup whatever was needed to bring
> > > > > > the
> > > > > > screen reader to life.
> > > > > 
> > > > > I think it's happened to you before, in May 2019. Was something
> > > > > plugged in when you installed your OS, that was misidentified?
> > > > 
> > > > That is a possibility I suppose as there are, and were then too at
> > > > least
> > > > 10 usb devices plugged in 100% of the time, keyboard & mouse both
> > > > wireless, 2 printers then, 1 left is an MFC so its a scanner too, a
> > > > ups, a CM11a, two cameras (one is a movie w/firewire) and 7 other
> > > > machines on net cables. That lis is incomplete so who knows what
> > > > might
> > > > be miss-id'd.
> > > 
> > > ISTR there was some sort of fast serial device involved, and the
> > > log you posted showed that it was fighting brltty, so that would
> > > appear to be the most likely candidate.
> > 
> > Hmmm, that triggers old memories, as it might be a 10 meter usb2 cable
> > with booster hubs in both ends, which formerly connected the minicom
> > program to a trs-80 color computer 3 in the basement via an rs232 card
> > plugged into its multipack interface expander. But it wasn't very fast,
> > the uart chip in it was all tapped out at 9600 baud, and rzsz was
> > limited to about 7200 baud due to its loop size being one byte, I was
> > always going to rewrite it to fully use the table lookup version of the
> > crc calcs but never found a round tuit. it was highly dependent on flow
> > control working, something that early uart chip did not do well.
> > Prolific who made the rs232<>usb convertor on the end of that cable,
> > never did quite get that right.
> > 
> > But that 2 megs of ram "coco" has now died, 35 yo electroytics
> > developing
> > high ESR so its dead now, and despite my being a CET, I'm too lazy in my
> > dotage to shotgun all the caps it it, but I believe that cable is still
> > plugged in to one of several multiport usb 2 or 3 hubs on this machine.
> > 
> > Do we still have a working usbtree like utility that might discover
> > this?
> > Such useful stuff seems to be falling off the edge in later versions of
> > linux.
> 
> I hadn't noticed that. I got a tree from   lsusb -t   and   lsusb -v
> gave me ~1000 lines despite saying that there were several devices
> it couldn't open, so information would be missing.

And I hadn't noticed it had all been merged into one util that could do it 
all so a -t gets me 21  devices and 21 errors. a -v gets me 1480 lines, but 
no culprit seems to be waving its hand at me if piped to less. Two sio 
adapter's show up but s/b two as the cm11a needs one also. heyu does its 
thing for Christmas lights and such.

> Cheers,
> David.
> 
> .


Cheers David, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

[SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 23:53 by loca...@tutanota.com:

> Jan 3, 2022, 23:08 by d...@randomstring.org:
>
>> Alright. Put this into your /etc/hosts temporarily:
>>
>> 152.195.33.23  www.usps.com tools.usps.com www.usps.gov
>>
>> That's unlikely to be an optimal IP from their CDN, but it is
>> currently working.
>>
>
> That fixed it, I got the USPS tracking page to load normally. Still not sure 
> why it worked as tools.usps.com resolves for me to 152.195.33.23:
>
> # dig tools.usps.com
> ...
> 
> ;; ANSWER SECTION:
> tools.usps.com. 42  IN  CNAME   cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net. 2078 IN  A   152.195.33.23
>

OK, I understand now what the problem was. Quite a while ago I added a line 
into the /etc/hosts to fix a temp DNS issue and completely forgot about it. So 
while DNS server was correctly resolving tools.usps.com to 152.195.33.23, my 
previous /etc/hosts entry was overriding it to 23.217.162.158 which was causing 
the certificate issue.

Thanks to everyone who responded.

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 23:08 by d...@randomstring.org:

> Alright. Put this into your /etc/hosts temporarily:
>
> 152.195.33.23  www.usps.com tools.usps.com www.usps.gov
>
> That's unlikely to be an optimal IP from their CDN, but it is
> currently working.
>

That fixed it, I got the USPS tracking page to load normally. Still not why it 
worked as tools.usps.com resolves for me to 152.195.33.23:

# dig tools.usps.com

; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45738
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 77e474050843f63a010061d38b021b182f925c475f14 (good)
;; QUESTION SECTION:
;tools.usps.com.    IN  A

;; ANSWER SECTION:
tools.usps.com. 42  IN  CNAME   cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net. 2078 IN  A   152.195.33.23

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 03 18:47:14 EST 2022
;; MSG SIZE  rcvd: 126




> Oh. Are you using DNS-over-HTTPS? 
>

I used to but I have disabled it for now. Even with DNS-over-HTTPS disabled I 
was getting the certificate error until I put 152.195.33.23 into the /etc/hosts.


Regards,

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Hi!

Em [2022-01-03 seg 10:03:08-0500], Michael Stone escreveu:

> On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
>>Indeed I use such high compression to prolong SSD lifetime.
>
> This is probably misguided and useless at best, at worst you're causing 
> additional writes because compressed data is generally hard to modify in 
> place without rewriting substantial portions.

But doesn't Btrfs compression work with small blocks?

https://btrfs.wiki.kernel.org/index.php/Compression#Are_there_speed_penalties_when_doing_random_access_to_a_compressed_file.3F

Fedora change proposal of Btrfs transparent compression by default
mentions increased flash-based media lifespan in the summary:

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression#Summary

> For reference, my main desktop which tracks debian unstable and gets
> pretty much constant updates, does package builds, etc., has after
> several years used...2% of its primary SSDs write capacity.  Most
> modern SSDs will never be used anywhere close to their limits before
> being discarded as functionally obsolete.  Just don't worry about it
> and focus on other things.

Thank you for the advice.  Indeed I should be a bit less obsessed with
certain details.  I at least dropped the idea of messing with swappiness
(as mentioned earlier in this thread) thanks to similar advice.  I have
a weakness for ricing which I must moderate.

Kind regards

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- https://www.defectivebydesign.org
- https://www.gnu.org

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[RP]

# host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

# host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 152.195.33.23
cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c


# dig tools.usps.com

; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42248
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cf068e8170694862010061d38628fa25caed2103d635 (good)
;; QUESTION SECTION:
;tools.usps.com.    IN  A

;; ANSWER SECTION:
tools.usps.com. 18  IN  CNAME   cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net. 3320 IN  A   152.195.33.23

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 03 18:26:32 EST 2022
;; MSG SIZE  rcvd: 126


Have you tried a different browser?

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Jeremy Ardley]

On 4/1/22 7:37 am, Jeremy Ardley wrote:


On 4/1/22 7:27 am, local10 wrote:



I have no problems accessing the www.usps.com , 
it's when I go to tools.usps.com that's when I have the issue:


# host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

# host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 152.195.33.23
cs1799.wpc.upsiloncdn.net has IPv6 address 
2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c




The IPV6 address you list for tools.usps.com is wildly different from 
the one I get. It's a completely different network - though that may 
be a result of resilience planning.


If you are running IPV6 it may be informative to block it at the 
firewall (I don't know of any way to block it in the browser)


The scenario I'm exploring is you may have a bad upstream IPv6 DNS server



Turns out there is a way to stop IPv6 in Firefox

https://techglimpse.com/disable-enable-ipv6-firefox-chrome-browser/


--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 23:37 by jer...@ardley.org:

> If you are running IPV6 
>

Not running IPV6.

Regards,

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Jeremy Ardley]

On 4/1/22 7:27 am, local10 wrote:



I have no problems accessing the www.usps.com , it's when 
I go to tools.usps.com that's when I have the issue:

# host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

# host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 152.195.33.23
cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c



The IPV6 address you list for tools.usps.com is wildly different from 
the one I get. It's a completely different network - though that may be 
a result of resilience planning.


If you are running IPV6 it may be informative to block it at the 
firewall (I don't know of any way to block it in the browser)


The scenario I'm exploring is you may have a bad upstream IPv6 DNS server

--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 22:42 by jer...@ardley.org:

> I too have no problems.
>
> My best guess is the OP DNS has been compromised. A simple check such as 
> using the host command should produce
>
> host usps.com
> usps.com has address 56.0.134.100
> usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.
>
> host tools.usps.com
> tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net has address 68.232.45.196
> cs1799.wpc.upsiloncdn.net has IPv6 address 
> 2606:2800:10c:b15a:cfbd:99c7:4c90:f5a0
>


I have no problems accessing the www.usps.com , it's when 
I go to tools.usps.com that's when I have the issue:

# host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

# host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 152.195.33.23
cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c


# dig tools.usps.com

; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42248
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cf068e8170694862010061d38628fa25caed2103d635 (good)
;; QUESTION SECTION:
;tools.usps.com.    IN  A

;; ANSWER SECTION:
tools.usps.com. 18  IN  CNAME   cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net. 3320 IN  A   152.195.33.23

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 03 18:26:32 EST 2022
;; MSG SIZE  rcvd: 126




# dig  cs1799.wpc.upsiloncdn.net +trace

; <<>> DiG 9.16.22-Debian <<>> cs1799.wpc.upsiloncdn.net +trace
;; global options: +cmd
.   518224  IN  NS  m.root-servers.net.
.   518224  IN  NS  a.root-servers.net.
.   518224  IN  NS  e.root-servers.net.
.   518224  IN  NS  i.root-servers.net.
.   518224  IN  NS  j.root-servers.net.
.   518224  IN  NS  b.root-servers.net.
.   518224  IN  NS  l.root-servers.net.
.   518224  IN  NS  f.root-servers.net.
.   518224  IN  NS  d.root-servers.net.
.   518224  IN  NS  h.root-servers.net.
.   518224  IN  NS  c.root-servers.net.
.   518224  IN  NS  k.root-servers.net.
.   518224  IN  NS  g.root-servers.net.
.   518224  IN  RRSIG   NS 8 0 518400 2022011617 
2022010316 9799 . WGsxB2AU5BQlYBqTc+eA4/0rvPyoftZEEHbFYipdp6K2wCpKecBnnrEE 
8/HdGAxK0gXRcgfylPCxsces7/ZAVclppfpnAPg+iiwm/y+ngRvr1EE4 
H9EQzJJKHvsnWfZhCeYOzKt868Sq7xTMHYSCMs26WKFitM/BQW4J354O 
lgzhsB/303j1HnT7QRY+byRHNaXKsh8G1P6cHBMZkOKGuyCtMGX+jNmU 
CnIxzgHrWjxde+mJ9SJKfHxWh1ZqsL9QWyyE00qeriwkF0kMO0W7Pjtj 
+2zlsXD6jjo7Y8SjjOctDLTNJPa2XvKCnRuhgSV1mBN0Hdz8CH5RQ0O4 3UacTQ==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

net.    172800  IN  NS  a.gtld-servers.net.
net.    172800  IN  NS  b.gtld-servers.net.
net.    172800  IN  NS  c.gtld-servers.net.
net.    172800  IN  NS  d.gtld-servers.net.
net.    172800  IN  NS  e.gtld-servers.net.
net.    172800  IN  NS  f.gtld-servers.net.
net.    172800  IN  NS  g.gtld-servers.net.
net.    172800  IN  NS  h.gtld-servers.net.
net.    172800  IN  NS  i.gtld-servers.net.
net.    172800  IN  NS  j.gtld-servers.net.
net.    172800  IN  NS  k.gtld-servers.net.
net.    172800  IN  NS  l.gtld-servers.net.
net.    172800  IN  NS  m.gtld-servers.net.
net.    86400   IN  DS  35886 8 2 
7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
net.    86400   IN  RRSIG   DS 8 1 86400 2022011617 
2022010316 9799 . lV9LChf+ZmsGC84XLyLtzCaRA5Z/HIy3xlhxVYKPCeE6Zj2wK6dyFk3p 
zTxto9XYVbuzwDD26zLLOkD27b8NBEnSVucdkVB+8fKAz/Y188eoCua/ 
CqYODHbyAT85QKUwBalN21PzORXMdMqf4Yp0LkqX6SeVvNlkCaOSk4CJ 
oP/q8chESaMFJ5WUeexXSdHCUpwMRbPpI+0U3E3ctTRpNtUAPQOtOnMN 
ZawH9eaXFpc2Vxitid/4SZt3nNYm2oaHX7IhBd3+JCp9q05tMfkFEDve 
21SrA3V6322E9xPa2FA3DLEb+ib7QLIuf9V8FxuhcRae3veVHwsoeZ6H ckrP8A==
;; Received 1210 bytes from 199.9.14.201#53(b.root-servers.net) in 139 ms

upsiloncdn.net. 172800  IN  NS  ns1.upsiloncdn.net.
upsiloncdn.net. 172800  IN  NS  ns2.upsiloncdn.net.
upsiloncdn.net. 172800  IN  NS  ns3.upsiloncdn.net.

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Dan Ritter]

local10 wrote: 
> Jan 3, 2022, 22:29 by d...@randomstring.org:
> 
> > Costco is definitely not the US Postal Service.
> >
> 
> No argument here.
> 
> 
> > flush caches. Restart Firefox. Check your net connection.
> >
> 
> I've done this a number of times. The connection is direct, no proxy.

Alright. Put this into your /etc/hosts temporarily:

152.195.33.23  www.usps.com tools.usps.com www.usps.gov

That's unlikely to be an optimal IP from their CDN, but it is
currently working.

Oh. Are you using DNS-over-HTTPS? 

https://support.mozilla.org/en-US/kb/firefox-dns-over-https

-dsr-

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 22:29 by d...@randomstring.org:

> Costco is definitely not the US Postal Service.
>

No argument here.


> flush caches. Restart Firefox. Check your net connection.
>

I've done this a number of times. The connection is direct, no proxy.

Regards,

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 22:30 by m...@allums.com:

> Did you click on a phishing link?
>
> Mark Allums
>

No, I have some USPS.com tracking links bookmarked and they were working fine 
until about two weeks ago. Could it be perhaps related to the Firefox upgrade 
from 78esr to 91esr?

Regards,

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Dan Ritter]

local10 wrote: 
> Jan 3, 2022, 22:11 by robe...@debian.org:
> 
> > The site works fine for me.
> >
> > In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
> > the full error output.  Then click 'Copy text to clipboard' and paste
> > the full text into an email.  Someone on the list ought to be able to
> > help diagnose further from there.
> >
> 
> 
> Weird. This is what I get:
> 
> 
> Websites prove their identity via certificates. Firefox does not trust this 
> site because it uses a certificate that is not valid for tools.usps.com. The 
> certificate is only valid for the following names: www.costco.ca 
> , costco.ca
> 

Costco is definitely not the US Postal Service.

flush caches. Restart Firefox. Check your net connection.

-dsr-

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Jeremy Ardley]

On 4/1/22 6:36 am, Charles Curley wrote:

On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
local10  wrote:


Am I the only one who's getting this error?

I am not. Vivaldi (vivaldi-stable, 5.0.2497.32-1, amd64) on bullseye.
The cert looks like:

Common Name (CN)*.usps.com
Organization (O)United States Postal Service
Organizational Unit (OU)
Common Name (CN)DigiCert SHA2 Secure Server CA
Organization (O)DigiCert Inc
Organizational Unit (OU)
Issued On   Wednesday, May 13, 2020 at 6:00:00 PM
Expires On  Monday, May 16, 2022 at 6:00:00 AM
SHA-256 Fingerprint AA 8B 94 FA D6 4D 4B 79 AE A3 23 03 78 B2 E4 97
65 8A C8 C2 CC B2 3A EC 09 C0 88 03 A9 36 26 E6
SHA-1 Fingerprint   7F 13 43 BD 73 38 23 15 81 A8 54 11 C3 13 F4 95
12 81 96 1F



I too have no problems.

My best guess is the OP DNS has been compromised. A simple check such as 
using the host command should produce


host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 68.232.45.196
cs1799.wpc.upsiloncdn.net has IPv6 address 
2606:2800:10c:b15a:cfbd:99c7:4c90:f5a0



--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 22:16 by loca...@tutanota.com:

> Jan 3, 2022, 22:11 by robe...@debian.org:
>
>> The site works fine for me.
>>
>> In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
>> the full error output.  Then click 'Copy text to clipboard' and paste
>> the full text into an email.  Someone on the list ought to be able to
>> help diagnose further from there.
>>
>
>
> Weird. This is what I get:
>
>
> Websites prove their identity via certificates. Firefox does not trust this 
> site because it uses a certificate that is not valid for tools.usps.com. The 
> certificate is only valid for the following names: www.costco.ca 
> , costco.ca
>
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
>
>
> https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890
>
> Unable to communicate securely with peer: requested domain name does not 
> match the server’s certificate.
>
> HTTP Strict Transport Security: false
> HTTP Public Key Pinning: false
>
> Certificate chain:
>
> ...
>

More info:

# cat /etc/debian_version && uname -a
11.2
Linux srv07 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 
GNU/Linux


# aptitude show firefox-esr
Package: firefox-esr
Version: 91.4.1esr-1~deb11u1
New: yes
State: installed

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Charles Curley]

On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
local10  wrote:

> Am I the only one who's getting this error?

I am not. Vivaldi (vivaldi-stable, 5.0.2497.32-1, amd64) on bullseye.
The cert looks like:

Common Name (CN)*.usps.com
Organization (O)United States Postal Service
Organizational Unit (OU)
Common Name (CN)DigiCert SHA2 Secure Server CA
Organization (O)DigiCert Inc
Organizational Unit (OU)
Issued On   Wednesday, May 13, 2020 at 6:00:00 PM
Expires On  Monday, May 16, 2022 at 6:00:00 AM
SHA-256 Fingerprint AA 8B 94 FA D6 4D 4B 79 AE A3 23 03 78 B2 E4 97
65 8A C8 C2 CC B2 3A EC 09 C0 88 03 A9 36 26 E6
SHA-1 Fingerprint   7F 13 43 BD 73 38 23 15 81 A8 54 11 C3 13 F4 95
12 81 96 1F


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Mark Allums]

Did you click on a phishing link?

Mark Allums



On 1/3/22 16:16, local10 wrote:

Jan 3, 2022, 22:11 by robe...@debian.org:


The site works fine for me.

In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
the full error output.  Then click 'Copy text to clipboard' and paste
the full text into an email.  Someone on the list ought to be able to
help diagnose further from there.



Weird. This is what I get:


Websites prove their identity via certificates. Firefox does not trust this site 
because it uses a certificate that is not valid for tools.usps.com. The certificate 
is only valid for the following names: www.costco.ca , 
costco.ca

Error code: SSL_ERROR_BAD_CERT_DOMAIN


https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890

Unable to communicate securely with peer: requested domain name does not match 
the server’s certificate.

HTTP Strict Transport Security: false
HTTP Public Key Pinning: false

Certificate chain:

-BEGIN CERTIFICATE-
MIIHTjCCBjagAwIBAgIQBOyIfmSb5tyeC53E3AQoqzANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDQxMzAwMDAwMFoXDTIyMDcxMjEy
MDAwMFowgdsxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRswGQYLKwYBBAGCNzwCAQITCldhc2hpbmd0b24xFDASBgNV
BAUTCzYwMSAwMjQgNjc0MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3Rv
bjERMA8GA1UEBxMISXNzYXF1YWgxJTAjBgNVBAoTHENvc3RjbyBXaG9sZXNhbGUg
Q29ycG9yYXRpb24xFjAUBgNVBAMTDXd3dy5jb3N0Y28uY2EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDaZN4KpbA4DhbWw+TT9c8mNUPeVKsYaysqMKJK
jVUKCx4DfAa1xWdR3l/DcMfuA3oTfFhf1X9tpL7hcCQN+jr/WKKTR9usHzjFzP1O
Q8QXPza0HjOaQbLwlO6MMrLfO/R5p1D2dhTAnGneL0ZR03DoqLIPqJT/aBEvQC2C
D5wxtm1TbooHuQ3OeUW8kOp/UY/+mT3uuf1LBz5EdjJ8A0Kc5FX6Lo54vK5Jty4X
VWASsj8W5DkLVL5k6zMUpRqKx9LEb1mYnKxYcTUQetCRBVo3zv7QUb+xNjhwEIiB
qe8g7pFgTW5FORITPoeWLCS68YwxZ/DJ7jYnouQludCKEsaPAgMBAAGjggNxMIID
bTAfBgNVHSMEGDAWgBQ901Cl1qCt7vNKYApl0yHU+PjWDzAdBgNVHQ4EFgQU34QV
E4cZWcbn/7IWLK0nuAzCU9YwIwYDVR0RBBwwGoINd3d3LmNvc3Rjby5jYYIJY29z
dGNvLmNhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYB
BQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29t
L3NoYTItZXYtc2VydmVyLWcyLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG
/WwCATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT
MAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8MHowJAYIKwYBBQUHMAh0dHA6Ly9v
Y3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNB
LmNydDAJBgNVHRMEAjAAMIIBewYKKwYBBAHWeQIEAgSCAWsEggFnAWUAdQCkuQmQ
tBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEXF1Ht6gAAAEAwBGMEQCIDR/
YSEr0iSj2uKBMQuc3YmvbFjlwH2+uEmd6NNbi9wGAiBTrfdlBpZJN6GyKMqded5g
yCxxgCV4jUtLQiw7vBUN2gB1AFYUBpov18Ls0/XhvUSyPsdGdrm8mRFcwO+UmFXW
idDdAAABcXUe3vcAAAQDAEYwRAIgJKh7x+t4g47X35aah89yser+f77yFRGzp9sj
6WryR2sCIHOa8cSDFzjBwPp3vTHAse1lJO4QGPtg/NXXfk4Veb75AHUAu9nfvB+K
cbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFxdR7etQAABAMARjBEAiBqwSAH
8sKPb4Y818r3AtnliGWrGhqgtZ0GEZWyDGf+eAIgYYVrZ8xAfrWu83TLSHemxk1E
XvOQ9k8JJHyjVRmOxpQwDQYJKoZIhvcNAQELBQADggEBAGjuhZ9ypCuzqFPHmafF
8tSty5Fb/LsQQ5i6O2A8lgG33WinpVjYbmDvlCl3vEsdkEvarGjCihJgTsb0RwZs
cNBkoFr+kNiR4lm/YnhtAd0qv8+uLJzZ1i9MmhcKuOSTgIKw368Kh0i9C3xDlsPU
jxK1rASaJxAuYBNWcPsnrO/BipRlpK8DG6XlNIUn8PzsuTVNOVf+kjdoM0rAHhVG
kagbhBbKJFLSOqLAZiXgc954wy9VIkEUHOd6Z3asMamTFSyC7wPj6rD3tkGwKKc0
NQO6pYEvkXJRJeieYtla+a+Luly3Nxi8yHWDl98N6sqKgitjCBScs4bWaILw54E3
S1c=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIEtjCCA56gAwIBAgIQDHmpRLCMEZUgkmFf4msdgzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowdTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTE0MDIGA1UEAxMrRGlnaUNlcnQgU0hBMiBFeHRlbmRlZCBW
YWxpZGF0aW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBANdTpARR+JmmFkhLZyeqk0nQOe0MsLAAh/FnKIaFjI5j2ryxQDji0/XspQUY
uD0+xZkXMuwYjPrxDKZkIYXLBxA0sFKIKx9om9KxjxKws9LniB8f7zh3VFNfgHk/
LhqqqB5LKw2rt2O5Nbd9FLxZS99RStKh4gzikIKHaq7q12TWmFXo/a8aUGxUvBHy
/Urynbt/DvTVvo4WiRJV2MBxNO723C3sxIclho3YIeSwTQyJ3DkmF93215SF2AQh
cJ1vb/9cuhnhRctWVyh+HA1BV6q3uCe7seT6Ku8hI3UarS2bhjWMnHe1c63YlC3k
8wyd7sFOYn4XwHGeLN7x+RAoGTMCAwEAAaOCAUkwggFFMBIGA1UdEwEB/wQIMAYB
Af8CAQAwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAh0dHA6Ly9vY3NwLmRp
Z2ljZXJ0LmNvbTBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsNC5kaWdpY2Vy
dC5jb20vRGlnaUNlcnRIaWdoQXNzdXJhbmNlRVZSb290Q0EuY3JsMD0GA1UdIAQ2
MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMB0GA1UdDgQWBBQ901Cl1qCt7vNKYApl0yHU+PjWDzAfBgNVHSMEGDAW
gBSxPsNpA/i/RwHUmCYaCALvY2QrwzANBgkqhkiG9w0BAQsFAAOCAQEAnbbQkIbh
hgLtxaDwNBx0wY12zIYKqPBKikLWP8ipTa18CK3mtlC4ohpNiAexKSHc59rGPCHg

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Jan 3, 2022, 22:11 by robe...@debian.org:

> The site works fine for me.
>
> In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
> the full error output.  Then click 'Copy text to clipboard' and paste
> the full text into an email.  Someone on the list ought to be able to
> help diagnose further from there.
>


Weird. This is what I get:


Websites prove their identity via certificates. Firefox does not trust this 
site because it uses a certificate that is not valid for tools.usps.com. The 
certificate is only valid for the following names: www.costco.ca 
, costco.ca

Error code: SSL_ERROR_BAD_CERT_DOMAIN


https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890

Unable to communicate securely with peer: requested domain name does not match 
the server’s certificate.

HTTP Strict Transport Security: false
HTTP Public Key Pinning: false

Certificate chain:

-BEGIN CERTIFICATE-
MIIHTjCCBjagAwIBAgIQBOyIfmSb5tyeC53E3AQoqzANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDQxMzAwMDAwMFoXDTIyMDcxMjEy
MDAwMFowgdsxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRswGQYLKwYBBAGCNzwCAQITCldhc2hpbmd0b24xFDASBgNV
BAUTCzYwMSAwMjQgNjc0MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3Rv
bjERMA8GA1UEBxMISXNzYXF1YWgxJTAjBgNVBAoTHENvc3RjbyBXaG9sZXNhbGUg
Q29ycG9yYXRpb24xFjAUBgNVBAMTDXd3dy5jb3N0Y28uY2EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDaZN4KpbA4DhbWw+TT9c8mNUPeVKsYaysqMKJK
jVUKCx4DfAa1xWdR3l/DcMfuA3oTfFhf1X9tpL7hcCQN+jr/WKKTR9usHzjFzP1O
Q8QXPza0HjOaQbLwlO6MMrLfO/R5p1D2dhTAnGneL0ZR03DoqLIPqJT/aBEvQC2C
D5wxtm1TbooHuQ3OeUW8kOp/UY/+mT3uuf1LBz5EdjJ8A0Kc5FX6Lo54vK5Jty4X
VWASsj8W5DkLVL5k6zMUpRqKx9LEb1mYnKxYcTUQetCRBVo3zv7QUb+xNjhwEIiB
qe8g7pFgTW5FORITPoeWLCS68YwxZ/DJ7jYnouQludCKEsaPAgMBAAGjggNxMIID
bTAfBgNVHSMEGDAWgBQ901Cl1qCt7vNKYApl0yHU+PjWDzAdBgNVHQ4EFgQU34QV
E4cZWcbn/7IWLK0nuAzCU9YwIwYDVR0RBBwwGoINd3d3LmNvc3Rjby5jYYIJY29z
dGNvLmNhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYB
BQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29t
L3NoYTItZXYtc2VydmVyLWcyLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG
/WwCATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT
MAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8MHowJAYIKwYBBQUHMAh0dHA6Ly9v
Y3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNB
LmNydDAJBgNVHRMEAjAAMIIBewYKKwYBBAHWeQIEAgSCAWsEggFnAWUAdQCkuQmQ
tBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEXF1Ht6gAAAEAwBGMEQCIDR/
YSEr0iSj2uKBMQuc3YmvbFjlwH2+uEmd6NNbi9wGAiBTrfdlBpZJN6GyKMqded5g
yCxxgCV4jUtLQiw7vBUN2gB1AFYUBpov18Ls0/XhvUSyPsdGdrm8mRFcwO+UmFXW
idDdAAABcXUe3vcAAAQDAEYwRAIgJKh7x+t4g47X35aah89yser+f77yFRGzp9sj
6WryR2sCIHOa8cSDFzjBwPp3vTHAse1lJO4QGPtg/NXXfk4Veb75AHUAu9nfvB+K
cbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFxdR7etQAABAMARjBEAiBqwSAH
8sKPb4Y818r3AtnliGWrGhqgtZ0GEZWyDGf+eAIgYYVrZ8xAfrWu83TLSHemxk1E
XvOQ9k8JJHyjVRmOxpQwDQYJKoZIhvcNAQELBQADggEBAGjuhZ9ypCuzqFPHmafF
8tSty5Fb/LsQQ5i6O2A8lgG33WinpVjYbmDvlCl3vEsdkEvarGjCihJgTsb0RwZs
cNBkoFr+kNiR4lm/YnhtAd0qv8+uLJzZ1i9MmhcKuOSTgIKw368Kh0i9C3xDlsPU
jxK1rASaJxAuYBNWcPsnrO/BipRlpK8DG6XlNIUn8PzsuTVNOVf+kjdoM0rAHhVG
kagbhBbKJFLSOqLAZiXgc954wy9VIkEUHOd6Z3asMamTFSyC7wPj6rD3tkGwKKc0
NQO6pYEvkXJRJeieYtla+a+Luly3Nxi8yHWDl98N6sqKgitjCBScs4bWaILw54E3
S1c=
-END CERTIFICATE-
-BEGIN CERTIFICATE-
MIIEtjCCA56gAwIBAgIQDHmpRLCMEZUgkmFf4msdgzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowdTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTE0MDIGA1UEAxMrRGlnaUNlcnQgU0hBMiBFeHRlbmRlZCBW
YWxpZGF0aW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBANdTpARR+JmmFkhLZyeqk0nQOe0MsLAAh/FnKIaFjI5j2ryxQDji0/XspQUY
uD0+xZkXMuwYjPrxDKZkIYXLBxA0sFKIKx9om9KxjxKws9LniB8f7zh3VFNfgHk/
LhqqqB5LKw2rt2O5Nbd9FLxZS99RStKh4gzikIKHaq7q12TWmFXo/a8aUGxUvBHy
/Urynbt/DvTVvo4WiRJV2MBxNO723C3sxIclho3YIeSwTQyJ3DkmF93215SF2AQh
cJ1vb/9cuhnhRctWVyh+HA1BV6q3uCe7seT6Ku8hI3UarS2bhjWMnHe1c63YlC3k
8wyd7sFOYn4XwHGeLN7x+RAoGTMCAwEAAaOCAUkwggFFMBIGA1UdEwEB/wQIMAYB
Af8CAQAwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAh0dHA6Ly9vY3NwLmRp
Z2ljZXJ0LmNvbTBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsNC5kaWdpY2Vy
dC5jb20vRGlnaUNlcnRIaWdoQXNzdXJhbmNlRVZSb290Q0EuY3JsMD0GA1UdIAQ2
MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMB0GA1UdDgQWBBQ901Cl1qCt7vNKYApl0yHU+PjWDzAfBgNVHSMEGDAW
gBSxPsNpA/i/RwHUmCYaCALvY2QrwzANBgkqhkiG9w0BAQsFAAOCAQEAnbbQkIbh
hgLtxaDwNBx0wY12zIYKqPBKikLWP8ipTa18CK3mtlC4ohpNiAexKSHc59rGPCHg
4xFJcKx6HQGkyhE6V6t9VypAdP3THYUYUN9XR3WhfVUgLkc3UHKMf4Ib0mKPLQNa

Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Roberto C . Sánchez]

On Mon, Jan 03, 2022 at 11:01:34PM +0100, local10 wrote:
> Hi,
> 
> Am I the only one who's getting this error? When I go to the USPS.com[1] to 
> track a package I get this "Warning: Potential Security Risk Ahead" error ( 
> Error code: SSL_ERROR_BAD_CERT_DOMAIN ). It's been like this for a couple of 
> weeks for me so it looks really strange that the USPS has fixed it after all 
> this time.
> I tried the same URL[1] in Konqueror and it also complains about the bad 
> certificate.
> 
> Any ideas? Thanks
> 

The site works fine for me.

In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
the full error output.  Then click 'Copy text to clipboard' and paste
the full text into an email.  Someone on the list ought to be able to
help diagnose further from there.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[local10]

Hi,

Am I the only one who's getting this error? When I go to the USPS.com[1] to 
track a package I get this "Warning: Potential Security Risk Ahead" error ( 
Error code: SSL_ERROR_BAD_CERT_DOMAIN ). It's been like this for a couple of 
weeks for me so it looks really strange that the USPS has fixed it after all 
this time.
I tried the same URL[1] in Konqueror and it also complains about the bad 
certificate.

Any ideas? Thanks


1 .https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890

Re: brltty=huge distraction for folks that don't need it.

[David Wright]

On Mon 03 Jan 2022 at 04:33:53 (-0500), gene heskett wrote:
> On Sunday, January 2, 2022 10:47:08 PM EST David Wright wrote:
> > On Sun 02 Jan 2022 at 22:31:27 (-0500), gene heskett wrote:
> > > On Sunday, January 2, 2022 9:54:29 PM EST David Wright wrote:
> > > > On Sun 02 Jan 2022 at 17:53:19 (-0500), gene heskett wrote:
> > > > > Without any conscious prompting by me, te debian 11.1 netinstall for
> > > > > x86-64 systems installed and setup whatever was needed to bring the
> > > > > screen reader to life.
> > > > 
> > > > I think it's happened to you before, in May 2019. Was something
> > > > plugged in when you installed your OS, that was misidentified?
> > > 
> > > That is a possibility I suppose as there are, and were then too at least
> > > 10 usb devices plugged in 100% of the time, keyboard & mouse both
> > > wireless, 2 printers then, 1 left is an MFC so its a scanner too, a
> > > ups, a CM11a, two cameras (one is a movie w/firewire) and 7 other
> > > machines on net cables. That lis is incomplete so who knows what might
> > > be miss-id'd.
> > 
> > ISTR there was some sort of fast serial device involved, and the
> > log you posted showed that it was fighting brltty, so that would
> > appear to be the most likely candidate.
> > 
> Hmmm, that triggers old memories, as it might be a 10 meter usb2 cable with 
> booster hubs in both ends, which formerly connected the minicom program to a 
> trs-80 color computer 3 in the basement via an rs232 card plugged into its 
> multipack interface expander. But it wasn't very fast, the uart chip in it 
> was all tapped out at 9600 baud, and rzsz was limited to about 7200 baud due 
> to its loop size being one byte, I was always going to rewrite it to fully 
> use the table lookup version of the crc calcs but never found a round tuit. 
> it was highly dependent on flow control working, something that early uart 
> chip did not do well. Prolific who made the rs232<>usb convertor on the end 
> of that cable, never did quite get that right.
> 
> But that 2 megs of ram "coco" has now died, 35 yo electroytics developing 
> high ESR so its dead now, and despite my being a CET, I'm too lazy in my 
> dotage to shotgun all the caps it it, but I believe that cable is still 
> plugged in to one of several multiport usb 2 or 3 hubs on this machine.
> 
> Do we still have a working usbtree like utility that might discover this? 
> Such useful stuff seems to be falling off the edge in later versions of 
> linux.

I hadn't noticed that. I got a tree from   lsusb -t   and   lsusb -v
gave me ~1000 lines despite saying that there were several devices
it couldn't open, so information would be missing.

Cheers,
David.

Re: Hyper-typematic and Firefox responsiveness in Weston.

[David Wright]

On Mon 03 Jan 2022 at 16:25:47 (+1100), David wrote:
> On Mon, 3 Jan 2022 at 14:05, David Wright  wrote:
> > On Thu 30 Dec 2021 at 19:48:05 (-0800), pe...@easthope.ca wrote:
> 
> > > In weston, keyboard response can be hyper-typematic.
> 
> > The kbdrate can be set at @reboot in root's
> > crontab to make it possible to login at a text VC more
> > easily, if it's messing up your typing passwords.
> 
> Re early setting of typematic ...
> 
> These days all my root filesystems are in LUKS containers.
> 
> And one of my laptops was so hyper-typematic that there
> was about a 50% chance of getting the 'cryptsetup open'
> password accepted when prompted by the initrd.
> 
> While this was great for security ($ADVERSARY has
> difficulty to boot the machine even if they stole the
> password!), it was a bit inconvenient. And also not
> great for security (gives $THEM multiple opportunities
> to surveil your password as you type it over and over again) ;p
> 
> So I now run 'kbdrate' inside the initrd. This seems to have
> solved the problem there and in all subsequent layers.

I presume you do this by placing something like
  /sbin/kbdrate -r 8 -d 500 -s
± a shebang, into a file like
  /etc/initramfs-tools/scripts//kbdrate.sh
Which  is appropriate?

Cheers,
David.

Re: why bash completion sometimes doesn't work?

[David Wright]

On Mon 03 Jan 2022 at 20:12:50 (+), Long Wind wrote:
> Thank Greg!  i use bash 5.0-4 and bash-completion 1:2.8-6
> all bash setting for root is default except 3 alias 
> 
>  alias rm='rm -i'
>  alias cp='cp -i'
>  alias mv='mv -i'
> 
> i type "ifdown wl" and press Tab, nothing happens
> there's only one wireless device in /etc/network/interfaces
> it shall complete command to "ifdown wlx12345" 
> 
> i've read /etc/skel/.bashrc, programmable completion seems enabled by default
> and it works for other commands, e.g. i type "dhclient enp" and Tab, it 
> becomes "dhclient enp0s1"

Type:

  ifdown 

and you should get a list that will contain at least "lo".

Cancel that line and type:

  ip a

to see what interfaces you actually have.

Cheers,
David.

Re: why bash completion sometimes doesn't work?

[Greg Wooledge]

On Mon, Jan 03, 2022 at 08:12:50PM +, Long Wind wrote:
> Thank Greg!  i use bash 5.0-4 and bash-completion 1:2.8-6

> i type "ifdown wl" and press Tab, nothing happens
> there's only one wireless device in /etc/network/interfaces
> it shall complete command to "ifdown wlx12345" 
> 
> i've read /etc/skel/.bashrc, programmable completion seems enabled by default
> and it works for other commands, e.g. i type "dhclient enp" and Tab, it 
> becomes "dhclient enp0s1" 

Well.  In this package, the completions for ifdown and dhclient
are very different.  E.g. in dhclient's completion, there's code that
looks like this:

if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W '-p -d -q -1 -r -lf -pf -cf -sf -s -g -n -nw
-w' -- "$cur" ) )
else
_available_interfaces

The ifdown completion, on the other hand, has:

if [[ $cword -eq 1 ]]; then
_configured_interfaces
COMPREPLY=( $(compgen -W '${COMPREPLY[@]}' -- "$cur") )

I wonder what the difference between _available_interfaces and
_configured_interfaces is.  Looks important.

Re: How i can resolve the problem of packages?

[William Torrez Corea]

On Sun, Oct 10, 2021 at 5:43 PM Cindy Sue Causey 
wrote:

> On 10/10/21, Dan Ritter  wrote:
> > William Torrez Corea wrote:
> >> I try execute the followings tasks but i get the same error:
> >>
> >> ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Read-only
> >> > file system
> >
> >
> >
> > Your root file system is read-only. This indicates a major
> > problem during boot.
> >
> > You'll need to fix this first. Look at logs.
>
>
> I saw that but wanted to see someone respond first. I've experienced
> read-only with hardware failures, too. The affected partition will
> become dismounted by itself then will be read-only if it remounts at
> all.
>
> Faulty USB hubs are the primary cause in my instances.That would
> involve having to spend money to fix. It's why I didn't want to type
> about this first. :)
>
> Cindy :)
> --
> Cindy-Sue Causey
> Talking Rock, Pickens County, Georgia, USA
> * runs with birdseed *
>

Why i have this type of problem?. This problem has happened with two hard
drive different, i don't know what happen.
-- 

With kindest regards, William.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Module Nvidia geforce 218 et Failed kernel module

[didier gaumet]

Désolé, mais à la lecture de tes réponses, je pense sincèrement que la
solution la plus simple et fonctionnelle pour toi c'est de réinstaller
un Debian amd64 (un vrai, pas un multiarch comme tu as) à partir d'un
media incluant les firmwares, avec de préférence le bureau KDE Plasma
(pas Trinity) pour que tu sois moins dérouté. Tout ça sans chercher à
personnaliser Debian, sans chercher à installer un pilote proprio, sans
chercher à installer des tas de logiciels, sans appliquer des recettes
piquées à droite à gauche sans bien les comprendre. Du *STANDARD*. Si
tu as besoin d'aide après ça (en config *STANDARD*) tu reviens le dire
:-)

Re: having high cpu problem related to kernel version

[_ djdisodo]

I found that this is a bug of kernel module "rtl8723ae"
and it also happens on kernel 5.10
i wasn't able to pin it out because i updated packages right after i
installed it
i was able to find related thread on askubuntu
https://askubuntu.com/questions/846830/irq-from-realtek-wifi-are-loading-cpu
typed `modprobe -r rtl8723ae` and cpu gone back to normal

i wasn't able to find any solution to this

this one, i  guess
https://github.com/torvalds/linux/tree/master/drivers/net/wireless/realtek/rtlwifi/rtl8723ae

2022년 1월 3일 (월) 오전 3:29, Nicholas Geovanis 님이 작성:

>
>
> On Fri, Dec 31, 2021, 4:27 PM _ djdisodo  wrote:
>
>> note that i'm using debian sid and xfce4
>>
>> it shows full of red bars on htop on one of the core between two(i
>> have atom n455 cpu)
>> iirc red bars means kernel threads
>>
>> i've tested using debian's boot menu so only thing changed is kernel
>> version
>> it was fine on kernel 5.10 it's happening on kernel 5.14 and 5.15
>>
>> i don't know exactly how to represent, but it isn't hard to if i just
>> do something like browsing or reading pdf it just starts to happen and
>> never stops even after i close all apps or log out
>>
>> https://asciinema.org/a/xTXqyZhg06enfrcHbuhasGJrm
>> https://asciinema.org/a/y0klCFDWSOsjjAQTUHlHM84mq
>>
>> 1st link is when it's fine(right after boot)
>>
>> 2nd link is when it happens
>>
>> there is no difference on application running between two
>>
>> xserver is unrelated it's high cpu usage is just because of more
>> updates on htop screen
>>
>
> And I think to get a better reading of the system state, you have to
> reduce the frequency of htop updates. Say down to every 3 or 4 secs to
> start.
>
> I don't see what you see in the video recordings you stored. Maybe because
> the top of the screen image you recorded seems to get corrupted towards the
> end of the video. But htop itself is taking 15% of a CPU by then.
>
>
>> if i watch htop on ctrl+alt+f1 terminal xserver isn't even on the
>> first page but htop still shows high cpu usage
>>
>> https://asciinema.org/a/l81ZO3hSHbA4jLm6fwLlIrfUS
>> recorded on ctrl+alt+f1 terminal
>> ran htop as root and enabled to show kernel threads
>> tho cpu usage of kernel threads aren't being displayed
>>
>>

Re: 8 -> 9 update changing things

[Roy J. Tellason, Sr.]

On Sunday 02 January 2022 09:56:14 pm David Wright wrote:
> On Sat 18 Dec 2021 at 11:24:34 (-0500), Roy J. Tellason, Sr. wrote:
> > On Friday 17 December 2021 11:53:20 am David Wright wrote:
> > Yeah,  except that I don't run KDE.  I do have it installed,  to be able to 
> > access certain programs that come with it,  but my desktop environment of 
> > choice is currently Xfce.
> 
> My understanding is that when you install a package like KDE,
> there's an assumption that you'll probably want to run it, and
> so it configures the system on that basis.

When I first installed I selected multiple different desktop environments,  so 
I could try them out.  I did not expect that ones that I was not running would 
have any effect in the one that I was running...
 
(snip)
> > There remains the sound issue in the virtualbox.  Could it be that Debian 
> > isn't running PulseAudio but something else?  That would account for the 
> > guest OS not being able to talk to it...
> 
> No idea; you'd have to check this for yourself. ISTR there may be
> issues with pulseaudio if it's running as a system daemon rather
> than for the logged-in user, but I don't know the details.

Running pulseaudio --start fixed that problem,  but now I show two instances of 
it runninng.

In the one that was running to start with,  the command line shown to me in 
system monitor includes "daemonize=no".  I would guess that to be the problem,  
but why is that in there?  And where do I fix it?  I also see "parent systemd" 
and after a bit of poking around in there I'm rather thoroughly confused,  not 
at all sure where I'd have to fix this.  Although 
/usr/lib/systemd/user/pulseaudioi.service seems pertinent.  Why would that have 
"daemonize=no" in there?

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Michael Stone]

On Mon, Jan 03, 2022 at 10:33:59AM -0500, Dan Ritter wrote:

Michael Stone wrote:

On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
> Indeed I use such high compression to prolong SSD lifetime.

This is probably misguided and useless at best, at worst you're causing
additional writes because compressed data is generally hard to modify in
place without rewriting substantial portions. Concerns about SSD life are
generally overblown unless you've got really unusual usage patterns (in
which case compressing things is unlikely to make a difference).


SSDs don't modify in place. The compression is probably good for
overall bandwidth of I/O, depending on CPU utilization.


I'm aware of how SSDs work. The question is how much rewriting is 
triggered by altering a byte in a compressed file, and how that 
interacts with the SSD's erase blocks and SLC cache. In most cases the 
effects are probably negligable (at least as much as any possible 
improvement from using compression) but in pathological cases it might 
increase rather than decrease write amplification. 

Anyway, there may be reasons to want to use compression on a given 
device, but SSD longevity shouldn't be one of them.


In my experience it doesn't do much for performance because in places 
*where it matters* compression is usually being done at a higher level 
anyway, and much more efficiently. That said, it can help sometimes but 
it's going to be extremely application-dependent.



For reference, my main desktop which tracks debian unstable and gets pretty
much constant updates, does package builds, etc., has after several years
used...2% of its primary SSDs write capacity. Most modern SSDs will never be
used anywhere close to their limits before being discarded as functionally
obsolete. Just don't worry about it and focus on other things.


This is largely true on desktops and laptops, not so true on
servers.


And, of course, we're talking about a laptop.

If we were talking about servers it wouldn't generally be a runtime 
concern on a modern system if write volume is accounted for when 
provisioning--there are extremely long-lived SSDs, they just cost more. 
If you put commodity laptop HDs in a server and write literally hundreds 
of TBs per day to them they also tend to fail faster than higher grade 
HDs (just without the counter telling you when they'll stop) so that's 
not a novel concern to account for when designing a system. If you're 
running servers you should probably monitor SSD health, but that's not 
different in practical terms than monitoring SMART predictive failures 
for HDs and dealing with them as necessary. In reality, even with all 
the hand-wringing about SSD write limits, modern parts are much more 
reliable than HDs. Most of the bad experiences with SSDs that get so 
much attention (excepting bad batches, which can happen with anything) 
relate to devices many generations obsolete.

Re: brltty=huge distraction for folks that don't need it.

[Charles Curley]

On Mon, 03 Jan 2022 04:33:53 -0500
gene heskett  wrote:

> Do we still have a working usbtree like utility that might discover
> this? Such useful stuff seems to be falling off the edge in later
> versions of linux.

Do you mean something like 'lsusb -t'?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Dan Ritter]

Michael Stone wrote: 
> On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:
> > Indeed I use such high compression to prolong SSD lifetime.
> 
> This is probably misguided and useless at best, at worst you're causing
> additional writes because compressed data is generally hard to modify in
> place without rewriting substantial portions. Concerns about SSD life are
> generally overblown unless you've got really unusual usage patterns (in
> which case compressing things is unlikely to make a difference).

SSDs don't modify in place. The compression is probably good for
overall bandwidth of I/O, depending on CPU utilization.


> For reference, my main desktop which tracks debian unstable and gets pretty
> much constant updates, does package builds, etc., has after several years
> used...2% of its primary SSDs write capacity. Most modern SSDs will never be
> used anywhere close to their limits before being discarded as functionally
> obsolete. Just don't worry about it and focus on other things.

This is largely true on desktops and laptops, not so true on
servers.

-dsr-

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Michael Stone]

On Mon, Jan 03, 2022 at 08:42:29AM -0300, Jorge P. de Morais Neto wrote:

Indeed I use such high compression to prolong SSD lifetime.


This is probably misguided and useless at best, at worst you're causing 
additional writes because compressed data is generally hard to modify in 
place without rewriting substantial portions. Concerns about SSD life 
are generally overblown unless you've got really unusual usage patterns 
(in which case compressing things is unlikely to make a difference).


For reference, my main desktop which tracks debian unstable and gets 
pretty much constant updates, does package builds, etc., has after 
several years used...2% of its primary SSDs write capacity. Most modern 
SSDs will never be used anywhere close to their limits before being 
discarded as functionally obsolete. Just don't worry about it and focus 
on other things.

Re: why bash completion sometimes doesn't work?

[Richmond]

Greg Wooledge  writes:

> By default, Debian installs the bash-completion package, which contains
> programmable completions for a whole bunch of commands.  This is
> enabled by dotting in a file from ~/.bashrc (the code to do this is
> at the end of /etc/skel/.bashrc, which becomes the default user ~/.bashrc
> file if you add users with "adduser").
>

Reading this has solved something which has puzzled me for some time. My
.bashrc is a leftover from when I was running Opensuse, and so bash
completion has never quite worked properly on the su command. Now I have
copied /etc/skel/.bashrc and it is working!

Re: Module Nvidia geforce 218 et Failed kernel module

[ajh-valmer]

On Monday 03 January 2022 10:43:43 didier gaumet wrote:
> Le dimanche 02 janvier 2022 à 23:23 +0100, ajh-valmer a écrit :
> > (Xorg ne semble pas se lancer).
> > Ma carte vidéo est une Nvidia geforce GE 6150 nforce 430.
> > Quel est le mode opératoire avec "xserver-xorg-video-nouveau" ?
> > je suis sous Bullseye 64 bits (Debian 11).
> 
> Commence par *ne* *pas* *squatter* un fil qui n'est pas le tien: tu as
> un problème Debian, tu crées un fil de discussion (tu aurais dû
> reprendre et continuer l'ancien) , tu ne squattes pas celui d'un autre,
> tu fous le bordel, à la fois pour lui, mais aussi pour les recherches
> futures (quelqu'un qui cherche sur internet parce qu'il a le même
> problême que toi va atterrir à 12 endroits différents parce que tu as
> fait des petits partout)   :-)  

Je remets donc le sujet de départ, désolé de mon erreur,
mais comme mon PC est en panne graphique,
je dois les écrire depuis un autre qui est toujours sous Buster,
mon MUA n'ayant pas le fil des sujets.

Grand merci pour cet Howto :

Tous les firmware nécessaire sont bien présents,
ainsi que l'effacement des fichiers blacklist dans /etc/modprobe.d/

> 1) en console sous root 
> # journactl -b -g firmware
Pas trop d'indications sinon absconses et pas visible en bout de lignes.
 
> 3) pour que le pilote libre "nouveau" puisse fonctionner correctement,
> il est préférable que le pilote proprio nvidia ait été désinstallé
> suivant les préconisations du wiki Debian si c'est un pilote proprio
> packagé par Debian. Ou désinstallé suivant les préconisations
> officielles de Nvidia si c'est un pilote proprio récupéré chez Nvidia 
# apt purge '^nvidia-.*' 
m'a tout désinstallé des paquets Nvidia.

> 4) # systemctl | grep -i graphical
>   graphical.target
> loaded active active Graphical Interface
Commande tapée, pas de réponse.

> 5) # systemctl | grep -i dm
> # dpkg-reconfigure nom_du_gestionnaire_de_connexion
Fait.

Dommage que tu ne me donnes pas le mode opératoire après la commande :
# apt install xserver-xorg-video-nouveau
Si je tape :
# apt install nvidia-driver OU apt install xserver-xorg-video-nvidia
je me vois proposer d'installer 129 fichiers,
dont de nombreux finissant par ":i386" (32 bits ?)

Voilà le topo...

A. Valmer

Re: [sujet modifié] Module Nvidia geforce 218 et Failed kernel module

[Luc Novales]

Bonjour et bonne année 2022 à toutes les personnes de la liste,


Le 27/12/2021 à 19:24, ajh-valmer a écrit :


J'ai encore des soucis :
- Carte Nvidia Geforce 218, module pas ou mal installé,
résolution trop faible (1024x768) impossible de la monter à 1024x1024.
Avant ça marchait avec le pilote proprio Nvidia.


C'est certainement parce que la version nvidia-legacy de Buster : 
https://packages.debian.org/fr/buster-backports/nvidia-legacy-340xx-driver 
supportait encore ta carte. C'est confirmé par une recherche du pilote 
de ta carte sur le site de nvidia qui renvoie la version 340.108 : 
https://www.nvidia.fr/Download/driverResults.aspx/156196/fr .


C'est le paquet nvidia-legacy-390xx-alternative : 
https://packages.debian.org/fr/bullseye/nvidia-legacy-390xx-alternative 
qui gère les anciennes cartes, dans Bullseye. Or, la GeForce 280 n'est 
déjà plus dans la liste de la version 470.94 du site Nvidia : 
https://www.nvidia.fr/Download/driverResults.aspx/184177/fr


Comme le paquet nvidia-legacy-340-driver : 
https://packages.debian.org/fr/sid/nvidia-legacy-340xx-alternative est 
encore en SID, tu peux peut-être t'en servir avec le kernel 5.10. Sinon, 
tu peux aussi essayer le script d'installation du site nvidia



Si je tente de le lancer, refus car le système dit que je dois désinstaller
un module nvidia, ce que je fais, et le message revient.

- Au boot, j'ai ce message : "Failed to start kernel module" (Quid ?).


Le module nvidia qui n'a pas compilé ?

Les logs devraient te dire de quel module exact il s'agit.

la commande :

journalctl -b -p err ```

ne te renseigne pas ?

Bonne journée,


--
*Luc Novalès*

Re: Replace line in file based on pattern

[Paul M. Foster]

On 1/2/22 11:03 PM, Greg Wooledge wrote:

On Sun, Jan 02, 2022 at 09:59:08PM -0500, Paul M. Foster wrote:

Regarding "patch", let's consider a "stock" config file from a fresh install
(call it NEW), and an existing config which is tweaked for my purposes (call
it OLD). Assume I want the stock config altered to conform to my
existing/working installation.


If you're reinstalling after a disk or system failure, you should be
able to drop the config files from your backup onto the system, either
before or after you install the software packages that use those files.


This is a fair point. In the case of a hardware failure, simply 
reinstalling working configs over the top of "stock" ones would work fine.




The scenario you seem to be imagining involves reinstalling software
packages and somehow ending up with a *different* version of the software
than you had been running on the failed system.  This isn't going
to happen if you were running Debian stable, and you reinstall Debian
stable.

The only way it would be a concern is if you're *not* running Debian
stable, or if you reinstall with something other than Debian stable.
In those cases, well, you're kinda on your own.


I am running stable. Where this situation arises is when I've been 
running for a couple of years and Debian changes to a new version (10 to 
11, for example). By that time, I have a lot of cruft on the machine, 
and I've just found it best to reinstall. And I've had it happen where a 
package changes its config, and I have to manually figure out what 
they've done, and how to compensate for it, to get back to a "working" 
(for me) state.


There are a lot of folks who like to "fiddle" with their systems 
constantly. I don't. So I'm not keen on having to manually fiddle with a 
lot of configs after an O/S version change.


Paul

Re: why bash completion sometimes doesn't work?

[Greg Wooledge]

On Mon, Jan 03, 2022 at 05:25:31AM +, Long Wind wrote:
> when i type "ifdown wl" and press Tab, it shall complete it with full device 
> name wlx12345
> i believe it's taken from /etc/network/interfaces
> but sometimes it doesn't work in buster

You're describing "programmable completion", which is an optional
feature of bash.  It's done on a per-command basis.  E.g. if you
type "cd wlx" it will not complete the wlx word using interface
names, because there is no such completion defined for the "cd" command.
Apparently there is (on your system) for "ifdown" though.

By default, Debian installs the bash-completion package, which contains
programmable completions for a whole bunch of commands.  This is
enabled by dotting in a file from ~/.bashrc (the code to do this is
at the end of /etc/skel/.bashrc, which becomes the default user ~/.bashrc
file if you add users with "adduser").

Unless told otherwise, we're going to assume you're using bash (not zsh)
as your shell, and that you've got the standard Debian ~/.bashrc file,
so that bash's programmable completion has been enabled.

If some programmable completion isn't working the way you expect, then
you need to gather some more information.  Give us the versions of
the bash and bash-completion packages that you've got installed, and
then tell us the EXACT command you typed, and what results you got by
pressing Tab.

Re: Reasonably simple setup for 1TB HDD and 250GB M.2 NVMe SSD

[Jorge P . de Morais Neto]

Em [2022-01-02 dom 23:38:48+], piorunz escreveu:

> On 02/01/2022 16:33, Jorge P. de Morais Neto wrote:
>> I am currently using compress-force=zstd:12 for the SSD and
>> compress=zstd:12 for both HDD (internal SATA and external USB3)¹.
>> Despite the strong compression level, performance is pretty good.  Yet,
>> when the system settles, I intend to reduce compression level to 9 or 6
>> (as you earlier recommended).  This should make performance even better,
>> while saving a lot of space because most data was compressed at
>> level 12.
>
> I run compress-force=zstd:6 on my fast PC, compress-force=zstd:3 on my
> server (to give it a bit more breathing space), and also same level 3 on
> my laptop. 12 is quite high for SSD, are you sure you not slowing down
> peak performance of your SSD by intense CPU usage? Or is it by design,
> to reduce number of writes to SSD?

Indeed I use such high compression to prolong SSD lifetime.  IIUC,
besides directly reducing the amount of data written, compression allows
extra over-provisioning which should reduce the write amplification
factor too.

Level 12 compression probably hurts performance a bit, but programs
still start very quickly---far quicker than they did over the HDD with
ext4.  This makes sense to me, because (IIUC) starting programs is
read-intensive and zstd decompression is fast even on high compression
levels.  And surprisingly, even dpkg package installation and updates,
which (IIUC) are write-intensive, are very quick too.

Besides, I think I rarely need top CPU power and disk throughput at the
same time.  I max out the quad-core processor when compiling Guix
packages but that happens on /tmp (tmpfs), so high Btrfs zstd
compression does no harm.  I also stress the CPU (and the integrated
GPU) on the rare occasions I play Xonotic or SuperTuxKart, and Btrfs
compression probably does no harm during 3D game rendering either.

In conclusion, my SSD is plenty quick for my needs even with very high
Btrfs zstd compression.  I care more about maximizing its lifetime than
having programs start a fraction of a second quicker when they already
start very quickly.

And when the system settles I intend to reduce Btrfs zstd compression
level to 9 or 6 in an attempt to save electricity---although I am nearly
always on AC power.

> No, I am not on this list, where is it?  Please send a link!

http://vger.kernel.org/vger-lists.html#linux-btrfs

Kind regards,
  Jorge

-- 
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 
- Please adopt free/libre formats like PDF, Org, LaTeX, ODF, Opus, WebM and 7z.
- Libre apps for AOSP (Replicant, LineageOS, etc.) and Android: F-Droid
- https://www.gnu.org/philosophy/free-sw.html "What is free software?"

Re: cpan

[Jude DaShiell]

Thanks, I had no idea that would work!


On Mon, 3 Jan 2022, Jeremy Ardley wrote:

> Pipe the output of the cpan command to less?
>
>  | less
>
> On 3/1/22 1:14 pm, Jude DaShiell wrote:
> > when displaying results from a cpan search, is it possible to limit the
> > number of displayed results to the screen size then page to the next or
> > previous set of results?
> > Something like what less does with long files that are larger than your
> > screen.
> >
>

Re: Packaging help: users and directories

[Gavin Henry]

Got access to salsa.debian.org today! Woot!

On Thu, 30 Dec 2021, 08:55 Gavin Henry,  wrote:

> Thanks!
>
> I've managed to build it. Just going through debuild now to clean up
> lintian issues and pbuilder.
>
> Suprisingly enjoyable!
>
> I've emailed the VoIP packaging group to see if I can help now that I know
> more. I'd like to look after the libosip2 package too.
>
> Gavin.
>
>
>

Re: [FIXED] Re: brltty=huge distraction for folks that don't need it.

[gene heskett]

On Monday, January 3, 2022 1:59:56 AM EST john doe wrote:
> On 1/3/2022 4:44 AM, gene heskett wrote:
> > On Sunday, January 2, 2022 9:57:05 PM EST Jean-Philippe MENGUAL wrote:
> >> Hi,
> >> 
> >> Le 02/01/2022 à 23:53, gene heskett a écrit :
> >>> Greetings All;
> >>> 
> >>> Without any conscious prompting by me, te debian 11.1 netinstall for
> >>> x86-64 systems installed and setup whatever was needed to bring the
> >>> screen reader to life.
> >> 
> >> That is strange. Should not happen. The accessibility is installed only
> >> if you press s or if you plug a braille device.
> >> 
> >>> Any thing related to a braile function that I try to remove wants to
> >>> kill
> >>> another 2 or 3 gigs of system with it.
> >> 
> >> Perhaps you can provide your /var/log/installer log somewhere to enable
> >> the team to see what happent? Better, you could report bug to
> >> debian-installer (but probably show here the log first). The log will
> >> be
> >> required anyway.
> > 
> > That's now a month back in history, and this time the dependency hell
> > did
> > not occur so My Next problem is BIQU's, their best BX 3d printer is not
> > "square". But that is not debians problem and I can, given time and
> > caffeine, fix that.
> > 
> >>> Quite distracting to a sighted user when that robotic voice, speaking
> >>> a
> >>> very broken bandwidth of what might be english, blaring out of ones
> >>> speakers 20 db louder than firefoxes audio can I am sure, find a way
> >>> to
> >>> silence this w/o destroying the rest of the system. Removing orca will
> >>> shut it up, but that leaves brltty spamming the daemon.log complaining
> >>> about a missing library every 5 seconds.  And that's close to 40
> >>> megabytes a week.
> >> 
> >> Note waiting for a good solution for packages, in your desktop, you can
> >> disable the accessibility via the control panel.
> > 
> > And where do I find this "control panel".
> > 
> >>> So, how does one shut up this useless to me, screen-reader and kill
> >>> the
> >>> log spamming at the same time?
> > 
> > Other advice has fixed that.
> > 
> >> ALso see wiki.debian.org/accessibility where you see the gsetting line
> >> to enable accessibility (type the same one replacing true with false to
> >> revert the thing).
> >> 
> >>> I think its great that folks have gone to that effort for the
> >>> sightless,
> >>> but why is that sort of stuff always made mandatory.
> >> 
> >> That is a bug I see for the first time. Hence my interest for a log, as
> >> so far no one reported it AFAIK.
> 
> The sooner you report an issue, the quicker it can be fixed for the
> comunity!!! :)
> 
> It would be nice if you could replicate the issue and file a bug report
> against the Debian Installer with the D-I logs.

I appreciate that, but that means I'd have to do a complete re-install from 
scratch, something I had to do 7 times already as its a full day per install 
even when most of the storage is now SSD's in raid10 configs. The latest 
generation of shingled spinning rust is a disaster looking for a place to 
happen.  And that's just the bare metal install, nowhere near a working 
system. To redo this system to the state its in now would take around a 
week. And I still haven't gotten my web page working.

> John Doe

Cheers John, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Écran noir après mise à jour Debian 11

[didier gaumet]

Le dimanche 02 janvier 2022 à 23:23 +0100, ajh-valmer a écrit :
[...]
> je n'arrive plus à lancer le bureau graphique (que la console en mode
> login).
> (Xorg ne semble pas se lancer).
> Ma carte vidéo est une Nvidia geforce GE 6150 nforce 430.
> 
> Quel est le mode opératoire avec "xserver-xorg-video-nouveau" ?
> (je n'ai rien trouvé de fonctionnel sur la toile malgré bien des
> recherches).
> Je rame depuis des jours...
> Faut-il installer d'autres paquets et lesquels ?
> 
> Merci d'un site explicatif (howto) qui donne la bonne solution.
> 
> A. Valmer
> 
> je suis sous Bullseye 64 bits (Debian 11).

Commence par *ne* *pas* *squatter* un fil qui n'est pas le tien: tu as
un problème Debian, tu crées un fil de discussion (tu aurais dû
reprendre et continuer l'ancien) , tu ne squattes pas celui d'un autre,
tu fous le bordel, à la fois pour lui, mais aussi pour les recherches
futures (quelqu'un qui cherche sur internet parce qu'il a le même
problême que toi va atterrir à 12 endroits différents parce que tu as
fait des petits partout)   :-)  

Pour ton problème,

Dans ton cas ça peut avoir plusieurs causes:
1) un firmware manquant pour la carte graphique
2) un module en liste noire qui fait que le pilote de ta carte n'est
pas chargé
3) le pilote graphique désiré n'est pas actif ou installé
4) un système d'exploitation pas configuré pour demarrer un session
graphique
5) un gestionnaire de de connexion absent ou pas configuré
6) ... autre cause ...

donc:

1) en console sous root 
# journactl -b -g firmware
te listera tous les évènements concernant les firmwares lors du dernier
boot. tu examines cette liste et si tu vois qu'un firmware n'a pas pu
être chargé, tu cherches si le paquet Debian contenant ce firmware est
installé et si il ne l'est pas tu l'installes.
Pour chaque firmware manquant:
# apt-file search nom_du_firmware_manquant_avec_son_extension
# apt search nom_du_paquet_ainsi_trouvé
et éventuellement
# apt install nom_du_paquet_ainsi_trouvé

2) en console sous root
# ls /etc/modprobe.d
il ne doit normalement pas y avoir autre chose que amd64-microcode-
blacklist.conf et intel-microcode-blacklist.conf dans ce répertoire. Si
il y a autre chose, tu le supprimes.

3) pour que le pilote libre "nouveau" puisse fonctionner correctement,
il est préférable que le pilote proprio nvidia ait été désinstallé
suivant les préconisations du wiki Debian si c'est un pilote proprio
packagé par Debian. Ou désinstallé suivant les préconisations
officielles de Nvidia si c'est un pilote proprio récupéré chez Nvidia 

4) # systemctl | grep -i graphical
  graphical.target
loaded active activeGraphical Interface
dans le cas présent chez moi, on voit que le système est paramétré pour
démarrer un session graphique (loaded: chargé; active: actif).
Si ce n'est pas le cas faire:
# systemctl enable graphical.target (pour que ça permette un démarrage
en graphique au prochain boot)
# systemctl start graphical.target (pour que permette une session
graphique dans la session courante)

5) # systemctl | grep -i dm
te listera des trucs sans intéret pour toi mais tu verras si est
présent tdm, gdm, lightdm, xdm, sddm, wdm (des gestionnaires de
connexion). Si tu utilises le bureau Trinity, il te faut tdm actif et
chargé, si tu utilises KDE/Plasma il te faut sddm actif et chargé,
etc...). Je simplifie un peu, ici.
En gros, tu vérifies que le gestionnaire de connexion approprié est
bien installé, sinon tu l'installes. Si il est installé tu fais un 
# dpkg-reconfigure nom_du_gestionnaire_de_connexion
car il n'est pas forcément actif (gestionnaire apr défaut)
(aussi bien lors de l'installation ou la reconfiguration, si il y a
plusieurs gestionnaires de connexion installés, tu dois choisir celui
par défaut)

***

OU ALORS,

comme déjà dit, tu ferais aussi bien de procéder à une installation
standard de Debian 11 à partir d'un média contenant les firmwares
https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
en choisissant le bureau (supporté par Debian:
KDE/Gnome/Xfce/Mate/Cinnamon/Lxde/Lxqt) qui te convient. au moins là tu
as un environnement debian fonctionnel sans complications, normalement.
Il te restera par contre ensuite à récupérer dans tes nouveaux outils
de bureau tes anciennes données (exemple: importer les mails du
courrier Trinity (Kmail, je crois) dans ton nouvel outil courrier)

Re: brltty=huge distraction for folks that don't need it.

[gene heskett]

On Sunday, January 2, 2022 10:47:08 PM EST David Wright wrote:
> On Sun 02 Jan 2022 at 22:31:27 (-0500), gene heskett wrote:
> > On Sunday, January 2, 2022 9:54:29 PM EST David Wright wrote:
> > > On Sun 02 Jan 2022 at 17:53:19 (-0500), gene heskett wrote:
> > > > Without any conscious prompting by me, te debian 11.1 netinstall for
> > > > x86-64 systems installed and setup whatever was needed to bring the
> > > > screen reader to life.
> > > 
> > > I think it's happened to you before, in May 2019. Was something
> > > plugged in when you installed your OS, that was misidentified?
> > 
> > That is a possibility I suppose as there are, and were then too at least
> > 10 usb devices plugged in 100% of the time, keyboard & mouse both
> > wireless, 2 printers then, 1 left is an MFC so its a scanner too, a
> > ups, a CM11a, two cameras (one is a movie w/firewire) and 7 other
> > machines on net cables. That lis is incomplete so who knows what might
> > be miss-id'd.
> 
> ISTR there was some sort of fast serial device involved, and the
> log you posted showed that it was fighting brltty, so that would
> appear to be the most likely candidate.
> 
Hmmm, that triggers old memories, as it might be a 10 meter usb2 cable with 
booster hubs in both ends, which formerly connected the minicom program to a 
trs-80 color computer 3 in the basement via an rs232 card plugged into its 
multipack interface expander. But it wasn't very fast, the uart chip in it 
was all tapped out at 9600 baud, and rzsz was limited to about 7200 baud due 
to its loop size being one byte, I was always going to rewrite it to fully 
use the table lookup version of the crc calcs but never found a round tuit. 
it was highly dependent on flow control working, something that early uart 
chip did not do well. Prolific who made the rs232<>usb convertor on the end 
of that cable, never did quite get that right.

But that 2 megs of ram "coco" has now died, 35 yo electroytics developing 
high ESR so its dead now, and despite my being a CET, I'm too lazy in my 
dotage to shotgun all the caps it it, but I believe that cable is still 
plugged in to one of several multiport usb 2 or 3 hubs on this machine.

Do we still have a working usbtree like utility that might discover this? 
Such useful stuff seems to be falling off the edge in later versions of 
linux.

Thanks David.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Tipografías truetype en Xorg

[Alfonso García Rodríguez]

El día 01/01/2022, a las 11:24, Roberto C. Sánchez escribió:
>
> On Sat, Jan 01, 2022 at 10:58:45AM +0100, Alfonso García Rodríguez wrote:
> 
> No me acuerdo precisamente de todos los detalles (a causa de que han
> pasado varios años desde que me ha hecho falta añadir tipografías a mi
> sistema), pero me luce extraño que estás utilizando el directorio
> /usr/share/fonts/truetype en lugar del /usr/local/share/fonts/.  El
> directorio /usr/share/fonts/truetype se utilisa por los paquetes del
> sistema y el /usr/local/share/fonts/ existe para la instalación de
> tipografías por parte del usuario o el adminstrador.

Exacto, estoy utilizando el directorio en el cual los paquetes del sistema
dejan las tipografías.

Pero por alguna razón dichos paquetes no crean los ficheros fonts.dir y
fonts.scale necesarios para que las X "carguen" las tipografías que allí 
hay guardadas.

Al menos en el caso de los paquetes que contienen nuevas tipografías
truetype.

Creo que esto se debe a que cada paquete que contiene tipografías truetype
crea una subcarpeta dentro de /usr/share/fonts/truetype/ con el nombre de la
tipografía que instala. Y mkfontscale no lee directorios recursivamente.

> Si me acuerdo bien, cuando yo añadí nuevas tipografías hace unos años,
> solo era necesario ubicar las tipografías bejo el directorio
> /usr/local/share/fonts/ y el sistema, sabiendo que ahí se depositan las
> tipografías nuevas locales, las descubre automáticamente.

En mi caso, como ya he comentado en el hilo, no ha sido automático.

Saludos y gracias a todos por vuestras respuestas.