Re: random number generator missing after upgrade

[Björn Persson]

davidson wrote:
>  Debian Bug #1041007
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041007#10

Yes, that seems to be exactly my problem. So it's not intentionally
disabled. Then I can hope that it may be fixed some day. Thanks for
your help.

Björn Persson


pgpRmFKPdRagm.pgp
Description: OpenPGP digital signatur

Re: why would ping and traceroute give you different IP addresses?

[Geert Stappers]

On Tue, Aug 15, 2023 at 05:02:49AM +, Albretch Mueller wrote:
> site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> 
> $ site="download.gluonhq.com"
> date
> time ping "${site}" -c 4
> time traceroute "${site}"
> Mon 14 Aug 2023 11:54:19 PM UTC
> PING s3-website.us-east-1.amazonaws.com (54.231.134.85) 56(84) bytes of data.
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=1 
> ttl=242 time=47.8 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=2 
> ttl=242 time=54.9 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=3 
> ttl=242 time=46.2 ms
> 64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85): icmp_seq=4 
> ttl=242 time=48.1 ms
> 
> --- s3-website.us-east-1.amazonaws.com ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3004ms
> rtt min/avg/max/mdev = 46.246/49.253/54.875/3.320 ms
> 
> real  0m3.186s
> user  0m0.005s
> sys   0m0.000s
> 
> traceroute to download.gluonhq.com (52.216.228.138), 30 hops max, 60
> byte packets
>  1  _gateway (192.168.68.1)  9.267 ms  9.223 ms  8.035 ms
>  2  dsldevice.attlocal.net (192.168.1.254)  10.349 ms  10.333 ms  10.319 ms
>  3  99-178-252-1.lightspeed.stlsmo.sbcglobal.net (99.178.252.1) 33.434 ms  
> 33.420 ms  33.406 ms
>  4  71.154.70.113 (71.154.70.113)  34.515 ms  33.379 ms  38.092 ms 5  * * *
>  6  32.130.88.131 (32.130.88.131)  50.165 ms  42.200 ms  35.492 ms
>  7  * * *
   
> 22  * * *
> 23  s3-website-us-east-1.amazonaws.com (52.216.228.138)  50.960 ms
> 50.902 ms  53.215 ms
> 
> real  0m15.213s
> user  0m0.009s
> sys   0m0.000s
> $
> 

$ host download.gluonhq.com
download.gluonhq.com is an alias for 
download.gluonhq.com.s3-website-us-east-1.amazonaws.com.
download.gluonhq.com.s3-website-us-east-1.amazonaws.com is an alias for 
s3-website.us-east-1.amazonaws.com.
s3-website.us-east-1.amazonaws.com has address 52.217.163.181
s3-website.us-east-1.amazonaws.com has address 52.217.83.203
s3-website.us-east-1.amazonaws.com has address 52.217.206.181
s3-website.us-east-1.amazonaws.com has address 52.217.98.51
s3-website.us-east-1.amazonaws.com has address 16.182.72.93
s3-website.us-east-1.amazonaws.com has address 52.216.227.162
s3-website.us-east-1.amazonaws.com has address 52.216.212.237
s3-website.us-east-1.amazonaws.com has address 52.217.83.179
$ host download.gluonhq.com
download.gluonhq.com is an alias for 
download.gluonhq.com.s3-website-us-east-1.amazonaws.com.
download.gluonhq.com.s3-website-us-east-1.amazonaws.com is an alias for 
s3-website.us-east-1.amazonaws.com.
s3-website.us-east-1.amazonaws.com has address 52.217.163.181
s3-website.us-east-1.amazonaws.com has address 52.217.83.203
s3-website.us-east-1.amazonaws.com has address 52.217.206.181
s3-website.us-east-1.amazonaws.com has address 52.217.98.51
s3-website.us-east-1.amazonaws.com has address 16.182.72.93
s3-website.us-east-1.amazonaws.com has address 52.216.227.162
s3-website.us-east-1.amazonaws.com has address 52.216.212.237
s3-website.us-east-1.amazonaws.com has address 52.217.83.179
$
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

why would ping and traceroute give you different IP addresses?

[Albretch Mueller]

site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"

$ site="download.gluonhq.com"
date
time ping "${site}" -c 4
time traceroute "${site}"
Mon 14 Aug 2023 11:54:19 PM UTC
PING s3-website.us-east-1.amazonaws.com (54.231.134.85) 56(84) bytes of data.
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=1 ttl=242 time=47.8 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=2 ttl=242 time=54.9 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=3 ttl=242 time=46.2 ms
64 bytes from s3-website-us-east-1.amazonaws.com (54.231.134.85):
icmp_seq=4 ttl=242 time=48.1 ms

--- s3-website.us-east-1.amazonaws.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 46.246/49.253/54.875/3.320 ms

real0m3.186s
user0m0.005s
sys 0m0.000s

traceroute to download.gluonhq.com (52.216.228.138), 30 hops max, 60
byte packets
 1  _gateway (192.168.68.1)  9.267 ms  9.223 ms  8.035 ms
 2  dsldevice.attlocal.net (192.168.1.254)  10.349 ms  10.333 ms  10.319 ms
 3  99-178-252-1.lightspeed.stlsmo.sbcglobal.net (99.178.252.1)
33.434 ms  33.420 ms  33.406 ms
 4  71.154.70.113 (71.154.70.113)  34.515 ms  33.379 ms  38.092 ms
 5  * * *
 6  32.130.88.131 (32.130.88.131)  50.165 ms  42.200 ms  35.492 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  s3-website-us-east-1.amazonaws.com (52.216.228.138)  50.960 ms
50.902 ms  53.215 ms

real0m15.213s
user0m0.009s
sys 0m0.000s
$

Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

[Max Nikulin]

On 15/08/2023 04:56, kjohn...@eclypse.org wrote:

I have done additional research, and it now appears that programs that
do extensive disk writes run much slower (3-6x) in Bookworm than they
did in Bullseye.


Have you compared kernel IO schedulers? May it be a case of SSD vs HDD 
optimizing?


grep '' /sys/block/*/queue/scheduler

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Max Nikulin]

On 14/08/2023 07:30, Nate Bargmann wrote:

I have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.


I do not know how it is arranged in Gnome, but I hope my observations 
still might be helpful.



systems on my LAN and was greeted with a password prompt for the
corresponding public key


To be precise, it is the passphrase do decrypt your *private* key. A 
public key may be known to anybody. Private key is a secret that allows 
to prove that you have it without disclosing of this private key. 
Encryption using a passphrase is a means to mitigate consequences if the 
private key is stolen.


An ssh agent opens a socket and exposes its location through an 
environment variable (perhaps using "systemctl set-environment", but I 
am not sure). Try


env | grep SSH

There are multiple implementations of SSH agents: openssh, gpg, 
keepassxc(?), perhaps gnome has more (seahorse? I am unsure concerning 
the role of secrets service). It may happen that in your case multiple 
instances are running:


/usr/lib/systemd/user/ssh-agent.service
/usr/lib/systemd/user/gpg-agent-ssh.socket
/etc/X11/Xsession.d/90x11-common_ssh-agent

GUI prompt may be just a proxy to an actual ssh agent. It just listens 
its socket and displaying a password prompt on demand and passing other 
messages literally.



Now, while typing this email all keyring PIDs have vanished!


It may be a way to minimize RAM usage. The agent may be a 
socket-activated process.


systemctl --user list-sockets

Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue 
what is really happening in your case.


I suggest you to add "f" option to "ps" to see process tree. It may help 
to find details concerning starting of particular agent.


   ps xwwf

P.S. At certain moment gnome designers decided that password prompt must 
be a modal dialog completely blocking interaction with any other 
applications (including 3rd party password manager). For me it was 
another reason to avoid gnome. I am aware that X11 protocol allows to 
sniff keyboard events and a measure against it is grabbing input. 
However I believe mouse still may be a way to call an external password 
manager. After all, there are may be an option to temporary suspend 
keyboard grabbing. I learned about multiple ways to start a ssh agent 
during initialization of user session when I was trying to figure out 
which way GUI prompt is implemented and if a more flexible dialog could 
be used instead.

Re: Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

[Stefan Monnier]

> I have done additional research, and it now appears that programs that do
> extensive disk writes run much slower (3-6x) in Bookworm than they did in
> Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting
> an SQL backup of a Bacula database from Postgresql (backup file about 3 GB).
> Operations that perform extensive reads (a Bacula backup operation to
> magnetic tape, 600 GB) seem to run at the same speed as before.
>
> At the moment, this is a 32-bit PAE system.  I don't know of an obvious
> reason why that would matter.  At the time of the upgrade, the system memory
> was enlarged from 16 to 32GB, in anticipation of converting the system from
> i386 to amd64.

FWIW, I've had very serious write performance issues on my Thinkpad T61
(8GB RAM + SSD) when using a 32bit PAE kernel (occasionally below 1MB/s,
tho not reliably reproducible, e.g. not right after boot).

Those problems disappeared when I switched to an amd64 kernel (while
keeping the userland 32bit).

https://serverfault.com/questions/996495/writes-throttled-to-500kb-s

Your symptoms seem quite different, but with 16GB of RAN, I'd strongly
suggest you try an amd64 kernel, just in case.


Stefan

Re: Cannot install Debian 12.1 on VirtualBox

[Piscium]

On Mon, 14 Aug 2023 at 12:47, Andrey Dogadkin  wrote:

> Should you specifically need UEFI next time, an alternative solution
> can be to temporarily disable KVM paravirtualization (default for
> Linux-based guests). It can be reenabled back after you are done with
> installation. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036310

Thanks for that! I think I had searched the bug list but somehow did
not find that bug. Glad to know that it has already been reported.
There is plenty of detail in there so no need for me to add to it. I
did a quick test a few minutes ago and can confirm that disabling
paravirtualization fixes the issue, as stated in the last comment in
the bug report. So it is good that there are two workarounds, and this
one is better than disabling EFI in some use cases.

Disk writes much slower in Bookworm i386 [Was: svnadmin dump ...]

[kjohnson]

I have done additional research, and it now appears that programs that do 
extensive disk writes run much slower (3-6x) in Bookworm than they did in 
Bullseye.  The two cases I have observed are 'svnadmin dump', and extracting an 
SQL backup of a Bacula database from Postgresql (backup file about 3 GB).  
Operations that perform extensive reads (a Bacula backup operation to magnetic 
tape, 600 GB) seem to run at the same speed as before.

At the moment, this is a 32-bit PAE system.  I don't know of an obvious reason 
why that would matter.  At the time of the upgrade, the system memory was 
enlarged from 16 to 32GB, in anticipation of converting the system from i386 to 
amd64.

Suggestions for tracking this down would be welcome.

Ken


Sent: Thursday, August 10, 2023 12:04 PM
To: 'debian-user@lists.debian.org'
Subject: svnadmin dump much slower in Bookworm

A set of svnadmin dump commands that run as part of a backup procedure seem to 
be _much_ slower in Bookworm than in Bullseye.  Prior to the upgrade to 
Bullseye, these commands took slightly less than one hour.  After the upgrade, 
similar commands (dumping a few more revisions) require more than six hours.  
The script that performs these commands has not been changed.  Has anyone else 
seen this problem?

Thanks,

Ken
 
 

Please could we calm down? [WAS List administrators - request]

[Andrew M.A. Cater]

People,

I'm not claiming any huge authority here: I'm a volunteer here and a reader
and contributor.

Recent threads have got out of hand, at least in part.

It is *really helpful* to be constructive and to try and put yourself in
someone else's place. There have been long rambling threads, some degree
of discontent and personal attacks. 

These don't help those reading this list for the first time. They don't help
the reputation of this list for long rambling threads that don't go anywhere.
They don't help people who actually come here seeking help for a Debian
problem.

Can I ask people to reconsider immediate responses to threads if you can
avoid it - sit on your hands for six hours or so and see if anyone else
jumps in before adding more UNLESS you can help someone immediately.

I post the FAQ every month in an effort to explain how this list might work.
Debian is odd because we still use mailing lists. Not everyone knows
to avoid top-posting, how to formulate a clear reply.

The Code of Conduct applies here as elsewhere in Debian: try and make this
a welcoming, useful place. You never know who you might help or who might
be driven away by someone's bad attitude.

Can we try this for a couple of days, please? If you can't add help 
immediately,maybe wait?

With thanks for your consideration

Andy

Andy Cater

Re: random number generator missing after upgrade

[davidson]

On Mon, 14 Aug 2023 Björn Persson wrote:

David Wright wrote:

On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:

Other functions in the same source file create /dev/tpm0, and it looks
like the random number generator should get registered together with
the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
the value of that option?


$ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
/boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
$


Thanks. And look at that:

# grep CONFIG_HW_RANDOM_TPM /boot/config-*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
# grep CONFIG_HW_RANDOM_TPM /boot/config-6.1.0-11-amd64 ; echo $?
1

So apparently randomness from a TPM is completely disabled in Debian 12
regardless of manufacturer. Next question: Why?


Debian Bug #1041007
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041007#10

 Message #10
 From: Vincent Blut
 [...]
 Subject: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG 
support (CONFIG_HW_RANDOM_TPM)
 Date: Sat, 29 Jul 2023 00:33:35 +0200

 [...]
 Indeed, this regression compared to the kernel provided in bullseye
 is due to a configuration issue.
 For HW_RANDOM_TPM to be enabled, the TCG_TPM and HW_RANDOM config
 symbols are required but there is a subtlety in the way they have to
 be built. If TCG_TPM is built-in then HW_RANDOM must not be loadable
 (built as a module).

 If we take a look at the kernel configuration files prior being
 constructed, we can see that both TCG_TPM and HW_RANDOM config
 symbols should be built as modules:

 $ grep -Er "TCG_TPM|HW_RANDOM="
 arm64/config:CONFIG_TCG_TPM=m
 kernelarch-x86/config:CONFIG_TCG_TPM=m
 config:CONFIG_HW_RANDOM=m
 config.cloud:CONFIG_TCG_TPM=m

 However after these files have been constructed, the TCG_TPM config
 symbol is no longer provided as module but built-in:

 $ grep TCG_TPM /boot/config-6.3.0-1-amd64
 CONFIG_TCG_TPM=y

 This change is what causes HW_RANDOM_TPM to be disabled and is
 probably due to

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=644f17412f5acf01a19af9d04a92193
 [...]

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Mailing list unsubscription requests and identificatio

[gene heskett]

On 8/14/23 12:24, zithro wrote:

On 12 Aug 2023 04:39, gene heskett wrote:

On 8/11/23 21:10, Larry Martell wrote:
Larry, whom I've known for 20 years, is only echoing.
  Are you really an engineer ?!


No, I am not an EE, but I am a Certified Electronics Technician, a 
much rarer breed of cat than your run of the mill EE.  We teach EE's 
how to get their hands dirty in the real world. Teaching them things 
their tenured by mistake prof's didn't.


Ok, so you should follow specs and best practices, right ?

Who is a random person to you? You’re new to this list, so you have 
no clue who is who here.


Thanks Larry. Take care & stay well, both of you.


The list is public since the start.

But I admit my post was misleading, lacking some transition between my 
objections to Gene and the remainder.


Gene is far from the random people I ranted about, and it doesn't take 
long to know he's rather a top poster, respectful and polite.


Gene, if you took it personnaly, I sincerely apologize.
That was really NOT my intent.

And I didn't take it that way, but I did try to fix the missing 
attribution.  NP IOW, take care & stay well.



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: setting up network with a hosts file, but your way

[gene heskett]

On 8/14/23 12:04, zithro wrote:

On 12 Aug 2023 20:49, gene heskett wrote:

ipv6:
There is no ipv6 service within 100 miles, so I should set a /proc 
command to kill ipv6, so whats the official syntax? for that.


I don't know if there is another method, I'll give you mine, which 
consists in telling the kernel to completely disable IPv6, in the kernel 
command line.


Edit "/etc/default/grub", on the line "GRUB_CMDLINE_LINUX" (or 
"GRUB_CMDLINE_LINUX_DEFAULT", depending on your config), add :


   ipv6.disable=1

Don't forget to run "update-grub", then reboot.

If it worked, you will find in the syslog :
"IPv6: Loaded, but administratively disabled, reboot required to enable".

If you're not using GRUB, you will have to find where kernel options 
should be entered (also called kernel command line).


Thanks zithro, but it appears that it is no longer needed, just follow 
Gregs recipe and it works.


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: Cannot install Debian 12.1 on VirtualBox

[Andrey Dogadkin]

On Sat, 2023-08-12 at 23:26 +0100, Piscium wrote:

> That was it, EFI! Normally when I install an OS on VB for the first
> time, if it does not work with EFI I disable it, or vice versa.
> However in this case I created this VM long ago, so it never occurred
> to be that it would go backwards, so to speak, from working with EFI
> to not working! Oh well, in hindsight it is obvious. Sometimes one
> misses what is in front of one's nose! One reason I missed it is
> because in my past experience if it does not boot due to EFI or not
> EFI, it stops at the very beginning, unlike in this case where I got
> to the first screen that has the menu for graphical install, etc.

Should you specifically need UEFI next time, an alternative solution
can be to temporarily disable KVM paravirtualization (default for
Linux-based guests). It can be reenabled back after you are done with
installation. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036310

Re: random number generator missing after upgrade

[Björn Persson]

David Wright wrote:
> On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:
> > Other functions in the same source file create /dev/tpm0, and it looks
> > like the random number generator should get registered together with
> > the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
> > the value of that option?  
> 
> $ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
> /boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
> /boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
> $ 

Thanks. And look at that:

# grep CONFIG_HW_RANDOM_TPM /boot/config-*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
# grep CONFIG_HW_RANDOM_TPM /boot/config-6.1.0-11-amd64 ; echo $?
1

So apparently randomness from a TPM is completely disabled in Debian 12
regardless of manufacturer. Next question: Why?

Björn Persson


pgppuJfr4uqri.pgp
Description: OpenPGP digital signatur

Re: List administrators - request for intervention - was - Re: Mailing list unsubscription requests and identificatio

[davidson]

On Mon, 14 Aug 2023 Bret Busby wrote:

On 14/8/23 03:36, davidson wrote:

On Sun, 13 Aug 2023 Andy Smith wrote:

Hello,

On Sun, Aug 13, 2023 at 12:12:49AM +, davidson wrote:

The foregoing demonstration is meant to show how, using alpine's
threaded mode, I minimise my irritation with threads that I find
irrelevant to my interests


Unfortunately no matter how advanced your MUA is, it doesn't help
against prolific posters who derail nearly every thread with
copious amounts of irrelevance and outright false information.


This is a higher bar than merely neutralising the disruption (to
one's own use of the list) caused by a popular thread that one has
little interest in.

And here, my instincts are screaming "Leave it here. Stop
now. Leave well enough alone for the sake of all that is holy!"

However, and speaking only for myself, I'll bite:

Being able to see a thread's messages structured as a tree of
message headers (author, subject) can indeed help me infer quite a
bit about what's going on, before I bother to dig in and actually
read any of the messages' content.

For example, let P and Q be two regularly prolific participants, P
with exceptionally high signal-to-noise contributions, and Q a hot
willfully clueless mess. If there is a branch of the tree that is
just a chain of back-and-forth between P and Q --Q.P.Q.P.Q...--
then I know what's going on in there and so some OTHER branch will
be my first destination, unless I'm in the mood for a laugh.


You can easily see from looking at most of the large threads here,
the points at which they go off the rails and the common factors
involved there.


I can indeed. Without seeing the tree structure, I do not think it
would be so easy to see.


It is a difficult problem to solve as mailing lists like this tend
to promote a volume-wins approach,


You may be correct, but this isn't clear to me. (Unless the object
of the game is to annoy the greatest number of participants.)


and the baseline user will not have an advanced MUA nor necessarily
the experience to know that they're reading nonsense.


When I conquer the world, you will know because /etc/motd will
contain something like this:

   Don't enter commands you don't understand, and you won't
   understand the commands unless you read the manual. If you read
   the manual, you STILL may not understand the
   commands. Nevertheless, keep trying, Curious Human. We are
   rooting for you!


Things get easier when you use an advanced MUA, so people should
invest the time to do so, but let's not pretend that this will avoid
a mega-thread next time some outlandish thread hijack by one of the
usual suspects happens.


My point was simply this: threads I've lost interest in (regardless
of size) are a single line in my mailbox, provided I do not delete
its initial message.


Does this particular thread go much better if you assume that
everyone participating (except the OP, who doesn't know how to
unsubscribe, or how to spell it) is fully competent at efficiently
managing email but still posts as they posted?


Funnily enough, if you look carefully, you can see some utterly
slapstick confusion of that very nature in this thread, over who is to
blame for posting a red-herring link to the Alpine Linux distro
mailing list:

%<---
 18159 Thursday   glenn green(6K) . UNUBSCRIBE
 ...   ............
[1] 18192 Yesterday  fjd (7K) .   |  \-Alpine was
[2] 18193 Yesterday  Bret Busby  (8K) .   ||-Re: Alpi
[6] 18194  5:55  fjd (7K) || |-Re: Al
[7] 18195  6:11  fjd (8K) || \-Re: Al
[3] 18196 Yesterday  Jeffrey Walton  (7K) .   |\-Re: Alpi
[4] 18197 Yesterday  Greg Wooledge   (5K) .   |  \-Re: Al
[5] 18198  2:41  Bret Busby  (9K) .   |\-Re:
 18199 Yesterday  David Wright   (6K) |  \-Re

--->%

Somebody requests a link to an alpine MUA forum or mailing list.
  [1] https://lists.debian.org/debian-user/2023/08/msg00333.html

Somebody posts a link to an alpine MUA mailing list.
  [2] https://lists.debian.org/debian-user/2023/08/msg00341.html

Somebody else posts a red-herring link, to a mailing list concerning
the linux distro called Alpine Linux.
  [3] https://lists.debian.org/debian-user/2023/08/msg00355.html

Then Greg points out, in reply to the red-herring poster, that they
have posted a red herring. <-- Here is where the tree structure view
is illuminating.
  [4] https://lists.debian.org/debian-user/2023/08/msg00356.html

And then the person who had posted the CORRECT link in the first
place apologises for posting the wrong one, and posts the very same
correct link once again. <-- This p

issue after Kernel upgrade

[Tim McConnell]

Hi List, 
I upgraded my Kernel and now after restarting my computer I have to go
into /proc/sys/user/max_*_namespaces and modify the value to something
other than 0 (zero). Where do I file a bug? 
I'm on Debian Stable with Kernel version 6.1.0-11-amd64 if it helps
any. 
Thanks! 
-- 
Tim McConnell 

Re: List administrators - request for intervention - was - Re: Mailing list unsubscription requests and identificatio

[davidson]

On Sun, 13 Aug 2023 Jeffrey Walton wrote:

On Sun, Aug 13, 2023 at 4:33 PM davidson  wrote:

[...]
Somebody else posts a red-herring link, to a mailing list concerning
the linux distro called Alpine Linux.
 [3] https://lists.debian.org/debian-user/2023/08/msg00355.html

Then Greg points out, in reply to the red-herring poster, that they
have posted a red herring. <-- Here is where the tree structure view
is illuminating.
 [4] https://lists.debian.org/debian-user/2023/08/msg00356.html
[...]
(The person who really HAD posted the red herring says nothing.)


What would you have me say? Greg made the correction.


I laid out the details of the process leading to the three-car
miscommunication pileup because it serves as a handy illustrative
example, in response to a question about whether knowledge of thread
structure could affect participant decisions.

Description, not prescription. I'm not here to tell consenting adults
what to do.


Do you really need more fodder from me?


Nope. For my part I am fully up to speed.

But have you noticed the other fellow in this thread, who is now
calling me a malicious liar for giving you all the credit, and openly
fantasising about how underground debian justice-league ninjas are
about to break into my house, delete my account, and swap the taps in
my shower?

Looks like I'm in for a real Amélie Poulain job, it does. But the
joke's on him; I get the taps confused every time anyways, so at worst
I won't notice a thing.


But I'll give you what you want...


I'm not a priest. And, just for the record since you seem to have read
me otherwise, I happen to think everyone's behavior so far has been
pretty normal human behavior, given reasonable assumptions about what
each knew at the time of their respective contributions.

The sheer normality of it is what makes it a good example, and perfect
comedy.


I sincerely apologize for posting an incorrect link to an Alpine
mailing list.  I am so sorry I troubled you for it.  I hope you can
find it in your heart to forgive me for the transgression, and the
inconvenience I caused to all members of the list.


I welcome your evident sarcasm here as a sign that we both agree that
the miscommunication event in question was a very normal one.

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

Re: Mailing list unsubscription requests and identificatio

[zithro]

On 12 Aug 2023 04:39, gene heskett wrote:

On 8/11/23 21:10, Larry Martell wrote:
Larry, whom I've known for 20 years, is only echoing.
  Are you really an engineer ?!


No, I am not an EE, but I am a Certified Electronics Technician, a much 
rarer breed of cat than your run of the mill EE.  We teach EE's how to 
get their hands dirty in the real world. Teaching them things their 
tenured by mistake prof's didn't.


Ok, so you should follow specs and best practices, right ?

Who is a random person to you? You’re new to this list, so you have no 
clue who is who here.


Thanks Larry. Take care & stay well, both of you.


The list is public since the start.

But I admit my post was misleading, lacking some transition between my 
objections to Gene and the remainder.


Gene is far from the random people I ranted about, and it doesn't take 
long to know he's rather a top poster, respectful and polite.


Gene, if you took it personnaly, I sincerely apologize.
That was really NOT my intent.

--
++
zithro / Cyril

Re: setting up network with a hosts file, but your way

[zithro]

On 12 Aug 2023 20:49, gene heskett wrote:

ipv6:
There is no ipv6 service within 100 miles, so I should set a /proc 
command to kill ipv6, so whats the official syntax? for that.


I don't know if there is another method, I'll give you mine, which 
consists in telling the kernel to completely disable IPv6, in the kernel 
command line.


Edit "/etc/default/grub", on the line "GRUB_CMDLINE_LINUX" (or 
"GRUB_CMDLINE_LINUX_DEFAULT", depending on your config), add :


  ipv6.disable=1

Don't forget to run "update-grub", then reboot.

If it worked, you will find in the syslog :
"IPv6: Loaded, but administratively disabled, reboot required to enable".

If you're not using GRUB, you will have to find where kernel options 
should be entered (also called kernel command line).


--
++
zithro / Cyril

Re: random number generator missing after upgrade

[David Wright]

On Mon 14 Aug 2023 at 11:26:13 (+0200), Björn Persson wrote:

> Other functions in the same source file create /dev/tpm0, and it looks
> like the random number generator should get registered together with
> the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
> the value of that option?

$ grep CONFIG_HW_RANDOM_TPM /boot/config-5.10.0-2*
/boot/config-5.10.0-23-amd64:CONFIG_HW_RANDOM_TPM=y
/boot/config-5.10.0-24-amd64:CONFIG_HW_RANDOM_TPM=y
$ 

Cheers,
David.

Re: random number generator missing after upgrade

[Björn Persson]

Anders Andersson wrote:
> On Sun, Aug 13, 2023 at 11:09 PM Björn Persson  wrote:
> > Jeffrey Walton wrote:  
> > > Maybe related to 
> > > https://www.phoronix.com/news/Linux-Disables-RNG-AMD-fTPMs  
> >
> > Not likely. That article is about a firmware TPM that comes with newer
> > Ryzen processors. Older Ryzens supposedly don't have it. The processor
> > in my APU2 is a GX-412TC, not a Ryzen at all, and my TPM is a discrete
> > chip from Infineon. The change in question is supposed to disable the
> > random number generator only if the TPM lists AMD as its manufacturer.  
> 
> I agree that the patch looks ok, but I remember being hit by a kernel
> change that inadvertently changed the behavior on other systems too
> (ECC RAM background scrubbing), but nobody really noticed because it
> was not in much use.
> 
> I suspect that the case of having an external TPM on an AMD system is
> such an unusual case, and I couldn't trace exactly where that patch
> checked the AMD string, so perhaps it's picking up the AMD string
> earlier on, and decides to disable all TPM on the AMD system. At least
> the timing of the problem and the patch is suspicious.

I see the 6.1 branch contains the first attempt at working around the
stutter problem, which disables randomness only from certain known
broken firmware versions:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=linux-6.1.y#n510

It's supposed to log a warning when it takes effect:
"AMD fTPM version 0x%llx causes system stutter; hwrng disabled\n"
That message does not appear in my logs.

The new workaround, which disables randomness from all AMD firmware TPUs
and doesn't log, can be in effect only if it has been backported to
Debian's kernel very recently. That does not seem to be the case, if
this is the right way to look for backports:
https://salsa.debian.org/kernel-team/linux/-/commits/bookworm/

I'll check what the manufacturer number is on my system, if I can
figure out how to get at it.

Björn Persson


pgp1FtuqAK5To.pgp
Description: OpenPGP digital signatur

Re: random number generator missing after upgrade

[Björn Persson]

Dan Ritter wrote:
> OK, either boot to the old kernel and look for an rng kernel
> module,

The only loaded module with "rng" in its name is "rng_core". That one
is present in both kernels, but four TPM-related modules are absent
from Linux 6.1:

# uname -v
#1 SMP Debian 5.10.179-3 (2023-07-27)
# lsmod | egrep -i 'rng|tpm'
tpm_crb20480  0
tpm_tis16384  0
tpm_tis_core   28672  1 tpm_tis
tpm73728  3 tpm_tis,tpm_crb,tpm_tis_core
rng_core   16384  3 ccp,tpm

# uname -v
#1 SMP PREEMPT_DYNAMIC Debian 6.1.38-3 (2023-08-07)
# lsmod | egrep -i 'rng|tpm'
rng_core   20480  1 ccp

And yet /dev/tpm0 exists in both kernels, but disappears when I
physically remove the TPM, so the TPM is recognized to some degree even
without those modules.

Those four TPM-related modules are also present as files under
/lib/modules in Linux 5.10, but absent in Linux 6.1. The corresponding
source files still exist in the source tree. Have they been disabled in
Debian 12? Have they been moved to some "extra modules" package that I
haven't found? Or are they just not modules because they're statically
built-in?

> or identify the rng hardware a little better

As I wrote in my first email, it seems to be an Infineon SLB 9665TT2.0.
It says "SLB9665TT20" on the chip package.

These characters are also written on the package. They mean nothing to
me, but maybe they can be used to identify the hardware better:
G1946KIV
51ZA947148IA1
(It's extremely difficult to tell I from 1 though.)

> and look
> for it in the kernel sources at 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random

In that directory I don't see anything that looks relevant.

The identifier "tpm-rng-0" comes from tpm_add_hwrng in
drivers/char/tpm/tpm-chip.c, which is still there:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/tpm/tpm-chip.c?h=v6.1&id=830b3c68c1fb1e9176028d02ef86f3cf76aa2476#n517

Other functions in the same source file create /dev/tpm0, and it looks
like the random number generator should get registered together with
the TPM. It's conditional on CONFIG_HW_RANDOM_TPM. Where can I check
the value of that option?

Björn Persson


pgperdoICnD28.pgp
Description: OpenPGP digital signatur

Re: Bootloader error grub minimal bash "load the kernel first" after installing my live image via calamares installer

[Thomas Schmitt]

Hi,

please reply to the list in order to keep all readers informed.
(It would be ok to Cc my mail address, but it is not necessary.)

- Forwarded message from Sakkra Billa  -
Date: Mon, 14 Aug 2023 09:32:37 +0530
From: Sakkra Billa 
To: Thomas Schmitt 
Subject: Re: Bootloader error grub minimal bash "load the kernel first"
after installing my live image via calamares installer

Thanks for the reply. I tried debian di too but wasn't successful in that
either it said that the kernel version for live and installer were not the
same.

- End forwarded message -

The problem is out of my range of experience and probably out of the
experience of the other participants here.

So you will have to ask the Debian Installer experts what goes wrong.

  https://wiki.debian.org/DebianInstaller
proposes
  Email: debian-b...@lists.debian.org
  IRC: #debian-boot

To improve your chances for helpful replies you should give them tangible
information. At least:
- The possibile configuration of the installer,
- the commands used to bring it into the directory tree which later
  becomes the ISO content,
- the exact error messages you get from the attempt to use the installer.
  (Even if this means that you have to manually toggle them into your
   mail.)


Have a nice day :)

Thomas