Re: ID problem: "the nouveau driver"

[Felix Miata]

Vincent Lefevre composed on 2023-03-24 03:57 (UTC+0100):

> On 2023-03-23 13:38:05 -0400, Felix Miata wrote:

>> It could be the exhibition of ignorance represented by the above
>> quote leads triagers and developers to ignore many problem reports.
>> There is no such thing as "the nouveau driver" in Debian:

> This is not true. From old Xorg logs:

> [194415.365] (II) NOUVEAU driver Date:   Fri Apr 21 14:41:17 2017 -0400
> [194415.365] (II) NOUVEAU driver for NVIDIA chipset families :

That is _A_ nouveau driver, one of several, among which:
/lib/modules//kernel/drivers/gpu/drm/nouveau/nouveau.ko
/usr/lib/xorg/modules/drivers/nouveau_drv.so
/usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
/usr/lib/x86_64-linux-gnu/dri/nouveau_vieux_dri.so

Thus there can be no "the" nouveau driver without more information than usually
presented along with string "the".

>> 2-X requires *a* display driver, which in the case of NVidia GPUs depends on 
>> KMS
>> functionality provided by a nouveau kernel device driver for optimal 
>> performance.

> https://nouveau.freedesktop.org/DebianPackages.html recommends
> xserver-xorg-video-nouveau.

Of course they do. N.I.H. Check the history on the page and you will probably 
find
that language dates back to before the modesetting DIX driver was born, and
probably before KMS too. I think I already did that check last week. The
modesetting DIX and KMS changed a lot in the many years since.

> However, it seems that a "modesetting" module is loaded by default:

If no appropriate DDX driver is available, absent specific configuration to do
otherwise, the modesetting DIX loads and stays loaded, as long as an appropriate
KMS module is loaded and functional, which *.modeset=0 and nomodeset disable.


-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: ID problem: "the nouveau driver" (was: nvidia package wrong documentation?)

[Vincent Lefevre]

On 2023-03-23 13:38:05 -0400, Felix Miata wrote:
> It could be the exhibition of ignorance represented by the above
> quote leads triagers and developers to ignore many problem reports.
> There is no such thing as "the nouveau driver" in Debian:

This is not true. From old Xorg logs:

[194415.365] (II) NOUVEAU driver Date:   Fri Apr 21 14:41:17 2017 -0400
[194415.365] (II) NOUVEAU driver for NVIDIA chipset families :

> 2-X requires *a* display driver, which in the case of NVidia GPUs depends on 
> KMS
> functionality provided by a nouveau kernel device driver for optimal 
> performance.
> One such display driver is named nouveau, and is provided by
> xserver-xorg-video-nouveau. The Xorg server .deb provides an alternative 
> driver
> named modesetting. The modesetting driver:
> 
> A-is a newer display driver technology;
> B-does not require reverse-engineering;
> C-is the upstream default display driver;
> D-supports all GPUs for which a kernel device driver providing KMS is 
> available;
> E-is automatically employed when applicable xserver-xorg-video-* is not 
> installed.

https://nouveau.freedesktop.org/DebianPackages.html recommends
xserver-xorg-video-nouveau.

However, it seems that a "modesetting" module is loaded by default:

[685925.554] (II) LoadModule: "modesetting"
[685925.554] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[685925.554] (II) Module modesetting: vendor="X.Org Foundation"
[685925.554]compiled for 1.18.1, module version = 1.18.1
[685925.554]Module class: X.Org Video Driver
[685925.554]ABI class: X.Org Video Driver, version 20.0
[...]
[685925.555] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

This is from

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814902

(a different machine, but basically with the same config).

It seems that I haven't kept any Xorg log for the concerned machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Fwd: 'gio: Setting attribute metadata::trusted not supported'

[roger . tarani]

Excusez-moi mais avez-vous déjà utilisé 'gio set' ?? 

Comment assurez-vous la sécurité du système debian quand on utilise un GUI 
(gnome, et autre xfce4) pour faire tourner un script requérant les droits d'un 
sudoer ? 


De: "roger tarani"  
À: "Liste Debian"  
Envoyé: Mardi 14 Mars 2023 11:47:31 
Objet: 'gio: Setting attribute metadata::trusted not supported' 

Bonjour, 

Je fais suite au fil de discussion debian 11 - créer une "desktop icon"... 
simplement . 
J'avais pu, avec un script bash exécuté par un sudoer, créer un lanceur sur le 
bureau avec une icône, lui donner les droits 700 (pour le sudoer qui exécute ce 
script). Impeccable. 

A cette occasion, j'ai aussi découvert les réglages de sécurité supplémentaires 
que j'ignorais (GUI...). 
Je suis allé jusqu'à les modifier avec cette commande exécutée en tant que 
sudoer ('sudo monscript.sh'). A son tour, root ($USER, tandis que le sudoer est 
représenté par $SUDO_USER) exécuteune commande sudo : 


sudo -u "${SUDO_USER}" bash -c 'echo "${LAUNCHER}"; gio set "${LAUNCHER}" 
metadata::trusted true' &> /dev/null 


Ça semble faire exactement ce que ferait l'utilisateur avec un clic droit sur 
l'icône du lanceur "Allow launching" (ou dans le navigateur de fichiers ; clic 
droit Properties > Permissions > "Allow executing file as program"). 

Le résultat obtenu est opérationnel , sauf cachotterie du système... 
Mais le script exécuté par l'utilisateur en tant que sudoer affiche un message 
d'erreur contradictoire ou lui-même erroné (ce qui serait un comble pour un 
message d'erreur !) : 

gio: Setting attribute metadata::trusted not supported 

D'où le &> /dev/null pour masquer ce message. 

Je veux m'assurer que ce qui marche aujourd'hui marchera, durablement, sur le 
système visé de l'utilisateur (debian 11, également). 

Comment expliquer que le changement est fait alors qu'un message suggère que 
cela n'est pas supporté ? (d'ailleurs : quoi, par quoi, pourquoi ?) 
Comment diagnostiquer ça ? 

Y a-t-il un rapport à explorer avec pkexec ou lxqt-sudo (et les anciens 
gksu/gksudo, obsolètes) à explorer ? (dont je ne connais quasiment rien à part 
les noms, puisque je n'ai jamais eu besoin de GUI...) 

Autrement dit, comment assure-t-on la sécurité du système debian quand on 
utilise un GUI (gnome, et autre xfce4) pour faire tourner un script requérant 
les droits d'un sudoer ? 

Merci. 

Re: differences between hwclock <-> date due to time zone issues? ...

[David Wright]

On Thu 23 Mar 2023 at 21:41:40 (+), Albretch Mueller wrote:
>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?

You're in my time zone, aren't you, so your hardware clock (UTC)
should be five hours ahead of the system clock (CDT). What are
the two times on your system?

  # hwclock --verbose
  hwclock from util-linux 2.36.1
  System Time: 1679611469.019755
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1650159782 seconds after 1969
  Last calibration done at 1650159782 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ...got clock tick
→ Time read from Hardware Clock: 2023/03/23 22:44:30
  Hw clock time : 2023/03/23 22:44:30 = 1679611470 seconds since 1969
  Time since last adjustment is 29451688 seconds
  Calculated Hardware Clock drift is 0.00 seconds
→ 2023-03-23 17:44:28.998946-05:00
  # 

Cheers,
David.

Re: differences between hwclock <-> date due to time zone issues? ...

[Cindy Sue Causey]

On 3/23/23, Cindy Sue Causey  wrote:
> On 3/23/23, Albretch Mueller  wrote:
>>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
>> the time 5 hours. hwclock tells me it worked fine but the terminal
>> windows opened before and after running hwclock still give me the
>> "old" time setting?
>>
>> _HRS_PM=-5
>>
< snipped for brevity >
>
> just battled this topic a couple months ago but can't remember which
> operating system. It was fixed INSTANTLY by creating /etc/adjtime (if
> it doesn't already exist) then entering the following:
>
> 0.0 0 0.0
> 0
> UTC
>
> Once saved, it takes just a few seconds then, BAM, there it is!
> Everything matches.. IF the hardware clock is set to universal time.
>
< snipped for brevity >

Not quite. I forgot to say you also need to issue the following
command afterward:

# dpkg-reconfigure tzdata

That's where you get to pick your timezone which is the other thing I
forgot to mention. I saw Stefan referenced the topic so I wasn't going
to create any more noise until I realized I'd left off tzdata. The
good news there is the Debian debootstrap link covers that, too:

https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176

Next time I'll try to remember to fully read my own offered resource
before hitting "Send".

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: differences between hwclock <-> date due to time zone issues? ...

[Cindy Sue Causey]

On 3/23/23, Albretch Mueller  wrote:
>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?
>
> _HRS_PM=-5
>
> ###
> #
> https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
> _DTS=$(date +%s)
> echo "// __ \$_DTS: |${_DTS}|";
> _DTF=$(date --date @${_DTS})
> echo "// __ \$_DTF: |${_DTF}|";
>
> _NEW_DTS=$((_DTS+3600*_HRS_PM))
> echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";
>
> # Convert the number of seconds back to date
> _NEW_DTF=$(date --date @${_NEW_DTS})
> echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";
>
> which hwclock
>
> sudo hwclock --show
> sudo hwclock --debug --set --date "${_NEW_DTF}"
> sudo hwclock --show
>
> date
>
> // __ $_DTS: |1679606975|
> // __ $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
> // __ $_NEW_DTS: |1679588975|
> // __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
> hwclock from util-linux 2.36.1
> Thu 23 Mar 2023 09:29:35 PM UTC
> $ sudo hwclock --show
> 2023-03-23 16:30:23.685781+00:00
> $ date
> Thu 23 Mar 2023 09:31:40 PM UTC


I left all the above because I didn't know where to safely snip. I
just battled this topic a couple months ago but can't remember which
operating system. It was fixed INSTANTLY by creating /etc/adjtime (if
it doesn't already exist) then entering the following:

0.0 0 0.0
0
UTC

Once saved, it takes just a few seconds then, BAM, there it is!
Everything matches.. IF the hardware clock is set to universal time.

Knowing to do that comes from an uncountable number of debootstrap'ed
Debian releases. The step can be found here under the "D.3.4.3.
Setting Timezone" heading:

https://www.debian.org/releases/wheezy/amd64/apds03.html.en#idp7856176

If your hardware clock is not UTC, I've never gone there so I don't
know. My CHOICE is UTC because a tip many years ago advised that doing
so helps our computers stay in sync more seamlessly with the rest of
the World. Whether that's true or not, I don't know that, either, but
going this route sure has taken the pain out of the local time keeping
end of all of this *for me*. :)

Cindy :)

Notable: If /etc/adjtime exists and has data that is anything other
than the 0.0s in there, my experience has been that occurs when I
don't have my hardware clock set up properly. When I go the UTC/0.0
route, my file never changes. That data, those numbers, is/are the
computer doing its own thing trying to keep things aligned based on
.e.g our correct and incorrect date commands issued via programs like
hwclock.
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: differences between hwclock <-> date due to time zone issues? ...

[Stefan Monnier]

>  I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?

The hardware clock is an "external" device which the Linux kernel
typically uses in very limited ways:
1- it reads it at boot to figure out what is the current time to
   initialize the system's own time.
2- it adjusts it every once in a while when the system's time is
   presumed to be more precise (because it's using NTP).

If you want to change the system's time, then change the system's time,
not the hardware clock.

To change the system's time, use `date` (see `man date` for the format
of its arguments).

But changing the system's time is very rarely a good idea.

If you want to change the time based on timezone issues, then change the
*timezone* rather than the time this way your running applications won't
be subjected to time travel, which tends to cause all kinds of odd
behaviors because suddenly the timer that was supposed to fire after
a handful of seconds suddenly waits 5h, or the timeout that should only
fire when there's really no answer after 2min fires right away because
it thinks 5h have passed.  Oh, and connections on the internet may fail
when your machine's time is to too far out of sync (and 5h *is* far),
since some authentication algorithms rely on time constraints.

Note that the timezone is not a system-wide setting.  Every process can
use its own timezone, e.g. by setting the `TZ` environment variable.
Try for example `TZ=UTC date` and then `TZ=Pacific/Samoa date`.
Browse /usr/share/zoneinfo/ to see the list of timezones your system
knows about.


Stefan

differences between hwclock <-> date due to time zone issues? ...

[Albretch Mueller]

 I am using this (yes, visually cr@ppy ;-)) code snippet to set back
the time 5 hours. hwclock tells me it worked fine but the terminal
windows opened before and after running hwclock still give me the
"old" time setting?

_HRS_PM=-5

###
# 
https://stackoverflow.com/questions/1092631/get-current-time-in-seconds-since-the-epoch-on-linux-bash
_DTS=$(date +%s)
echo "// __ \$_DTS: |${_DTS}|";
_DTF=$(date --date @${_DTS})
echo "// __ \$_DTF: |${_DTF}|";

_NEW_DTS=$((_DTS+3600*_HRS_PM))
echo "// __ \$_NEW_DTS: |${_NEW_DTS}|";

# Convert the number of seconds back to date
_NEW_DTF=$(date --date @${_NEW_DTS})
echo "// __ \$_NEW_DTF: |${_NEW_DTF}|";

which hwclock

sudo hwclock --show
sudo hwclock --debug --set --date "${_NEW_DTF}"
sudo hwclock --show

date

// __ $_DTS: |1679606975|
// __ $_DTF: |Thu 23 Mar 2023 09:29:35 PM UTC|
// __ $_NEW_DTS: |1679588975|
// __ $_NEW_DTF: |Thu 23 Mar 2023 04:29:35 PM UTC|
hwclock from util-linux 2.36.1
Thu 23 Mar 2023 09:29:35 PM UTC
$ sudo hwclock --show
2023-03-23 16:30:23.685781+00:00
$ date
Thu 23 Mar 2023 09:31:40 PM UTC

Re: exim failure

[peter]

Header lines not handled by Web interface.
In-reply-to: 
References: <5674e986a67af53a04b27f08cd161...@easthope.ca> 



From: David Wright 
Date: Wed, 22 Mar 2023 17:06:20 -0500

What are the contents of /etc/exim4/update-exim4.conf.conf, the
configuration file?


# /etc/exim4/update-exim4.conf.conf
#
# Most of the heading comments removed.
#
# This is a Debian specific file

dc_eximconfig_configtype='smarthost'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='dalton.invalid'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='hornby.islandhosting.com::465'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'


I assumed you just stared at the screen until this timeout appeared.


My thought was "broken configuration".


You've now got to type something. It will then talk back to you.
Try typing (ignore my indentation):

  ehlo dalton.invalid  ← that's not a typo
  mail from: pe...@easthope.ca
  rcpt to: pe...@easthope.ca
  data
  from: pe...@easthope.ca
  to: pe...@easthope.ca
  subject: hand written test 01
   ← that's a blank line
  Hand written test 01
  .← that's nothing but a fullstop 
Return

  quit


root@dalton:/home/root# exim -bh 142.103.107.137.465

 SMTP testing session as if from host 142.103.107.137
 but without any ident (RFC 1413) callback.
 This is not for real!


host in hosts_connection_nolog? no (option unset)
host in host_lookup? yes (matched "*")
looking up host name for 142.103.107.137
IP address lookup yielded "dalton.invalid"
checking addresses for dalton.invalid
  127.0.1.1
  142.103.107.137 OK
host in host_reject_connection? no (option unset)
host in sender_unqualified_hosts? no (option unset)
host in recipient_unqualified_hosts? no (option unset)
host in helo_verify_hosts? no (option unset)
host in helo_try_verify_hosts? no (option unset)
host in helo_accept_junk_hosts? no (option unset)
host in pipelining_connect_advertise_hosts? yes (matched "*")

220 dalton.invalid ESMTP Exim 4.94.2 Thu, 23 Mar 2023 10:45:12 -0700
ehlo dalton.invalid

host in dsn_advertise_hosts? no (option unset)
host in pipelining_advertise_hosts? yes (matched "*")
host in auth_advertise_hosts? yes (matched "*")
host in chunking_advertise_hosts? yes (matched "*")
host in tls_advertise_hosts? yes (matched "*")
host in smtputf8_advertise_hosts? no (end of list)

250-dalton.invalid Hello dalton.invalid [142.103.107.137]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-PIPE_CONNECT
250-CHUNKING
250-STARTTLS
250-PRDR
250 HELP
mail from: pe...@easthope.ca

using ACL "acl_check_mail"
processing "accept" (/var/lib/exim4/config.autogenerated 265)
accept: condition test succeeded in ACL "acl_check_mail"
end of ACL "acl_check_mail": ACCEPT

250 OK
rcpt to: pe...@easthope.ca

using ACL "acl_check_rcpt"
processing "accept" (/var/lib/exim4/config.autogenerated 277)
check hosts = :
host in ":"? no (end of list)
accept: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 292)
check domains = +local_domains
easthope.ca in "@:localhost"? no (end of list)
easthope.ca in "+local_domains"? no (end of list)
deny: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 301)
check domains = !+local_domains
easthope.ca in "!+local_domains"? yes (end of list)
check local_parts = ^[./|] : ^.*[@%!`#&?] : ^.*/\\.\\./
peter in "^[./|] : ^.*[@%!`#&?] : ^.*/\.\./"? no (end of list)
deny: condition test failed in ACL "acl_check_rcpt"
processing "accept" (/var/lib/exim4/config.autogenerated 307)
check local_parts = postmaster
peter in "postmaster"? no (end of list)
accept: condition test failed in ACL "acl_check_rcpt"
processing "deny" (/var/lib/exim4/config.autogenerated 322)
check !acl = acl_local_deny_exceptions
 using ACL "acl_local_deny_exceptions"
 processing "accept" (/var/lib/exim4/config.autogenerated 238)
 check hosts = ${if 
exists{/etc/exim4/host_local_deny_exceptions}{/etc/exim4/host_local_deny_exceptions}{}}

host in ""? no (end of list)
 accept: condition test failed in ACL "acl_local_deny_exceptions"
 processing "accept" (/var/lib/exim4/config.autogenerated 242)
 check senders = ${if 
exists{/etc/exim4/sender_local_deny_exceptions}{/etc/exim4/sender_local_deny_exceptions}{}}

pe...@easthope.ca in ""? no (end of list)
 accept: condition test failed in ACL "acl_local_deny_exceptions"
 processing "accept" (/var/lib/exim4/config.autogenerated 246)
 check hosts = ${if 
exists{/etc/exim4/local_host_whitelist}{/etc/exim4/local_host_whitelist}{}}

host in ""? no (end of list)
 accept: condition test failed in ACL "acl_local_deny_exceptions"
 processing "accept" (/var/lib/exim4/config.autogenerated 250)
 check senders = ${if 
exists{/etc/exim4/local_sender_whitelist}{/etc/exim4/local_sender_whitelist}{}}

pe...@easthope.ca in ""? no 

Re: ID problem: "the nouveau driver" (was: nvidia package wrong documentation?)

[Felix Miata]

Vincent Lefevre composed on 2023-03-23 14:48 (UTC+0100):

> On 2023-03-22 10:50:30 +0100, Hans wrote:

>> Oh, before someone tells: I do NOT want to use nouveau!

> Though I would prefer free software, nouveau is not usable for me,
> in particular with my laptop. Remember...

>   https://lists.debian.org/debian-user/2020/05/msg00464.html

> The developers did not care to look at my bug reports (this one
> and older ones).

Quoting from the above URI:

[quote]
I use Debian/unstable with the nouveau driver
[/quote]

It could be the exhibition of ignorance represented by the above quote leads
triagers and developers to ignore many problem reports. There is no such thing 
as
"the nouveau driver" in Debian:

1-Each kernel provides *a* unique nouveau device module (driver) specifically 
for
that kernel version to provide modesetting services (KMS) and other DRM 
services.

2-X requires *a* display driver, which in the case of NVidia GPUs depends on KMS
functionality provided by a nouveau kernel device driver for optimal 
performance.
One such display driver is named nouveau, and is provided by
xserver-xorg-video-nouveau. The Xorg server .deb provides an alternative driver
named modesetting. The modesetting driver:

A-is a newer display driver technology;
B-does not require reverse-engineering;
C-is the upstream default display driver;
D-supports all GPUs for which a kernel device driver providing KMS is available;
E-is automatically employed when applicable xserver-xorg-video-* is not 
installed.

3-libdrm-nouveau2 provides a userspace interface to nouveau-specific kernel DRM
services: /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2

4-libgl1-mesa-dri provides
  /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
  /usr/lib/x86_64-linux-gnu/dri/nouveau_vieux_dri.so

5-When xserver-xorg-video-nouveau is not installed, NVidia users may see the
following:
# grep veau /var/log/Xorg.0.log
[39.971] (II) modeset(0): [DRI2]   DRI driver: nouveau
[39.971] (II) modeset(0): [DRI2]   VDPAU driver: nouveau
[39.989] (II) AIGLX: Loaded and initialized nouveau
# grep odese /var/log/Xorg.0.log | grep -v 'set(0)'
[34.877] (==) Matched modesetting as autoconfigured driver 0
[34.877] (II) LoadModule: "modesetting"
[34.904] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[34.936] (II) Module modesetting: vendor="X.Org Foundation"
[34.966] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
# inxi -S --vs
inxi 3.3.25-00 (2023-02-07)
System:
  Host: hp945 Kernel: 5.10.0-21-amd64 arch: x86_64 bits: 64 Desktop: Trinity
v: R14.0.13 Distro: Debian GNU/Linux 11 (bullseye)
# inxi -Gaz
Graphics:
  Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau
v: kernel non-free: series: 340.xx status: legacy (EOL) last:
release: 340.108 kernel: 5.4 xorg: 1.20 arch: Tesla process: 40-80nm
built: 2006-13 pcie: gen: 1 speed: 2.5 GT/s lanes: 16 ports:
active: DVI-I-1,HDMI-A-1 empty: VGA-1 bus-ID: 01:00.0 chip-ID: 10de:0a65
class-ID: 0300 temp: 67.0 C
  Display: x11 server: X.Org v: 1.20.11 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: nouveau gpu: nouveau display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
  Monitor-1: DVI-I-1 pos: right model: Dell P2213 serial: 
built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
  Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM
serial:  built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
  API: OpenGL v: 3.3 Mesa 20.3.5 renderer: NVA8 direct-render: Yes

Which nouveau is "the" nouveau???

Has use of the modesetting display driver been tested by the user with a 
"nouveau"
problem?

PS: Q: Why does a nouveau display driver exist when the default modesetting
display driver exists?
A: Because being newer, it doesn't support ancient hardware that may be 
supported
by other drivers, and determination of the optimal display driver to install 
would
be a highly complicated process that would severely bloat distribution
installation programs and yet be unreliable. Therefore, inclusion of
xserver-xorg-video-* is part of most installations. The option remains to use
/etc/X11/xorg.con* to specify a particular display driver rather than depending 
on
whether or not a particular display driver .deb is installed.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: ssh-add after graphical login

[Erwan David]

Le 23/03/2023 à 09:42, Yassine Chaouche a écrit :

Hello all,

I'd like something to run ssh-add right after I login to my desktop
(KDE).
ssh-add needs to prompt me for my passphrase,
and doesn't need any privileges.

What are my options?

Best,



I  do this way :

I create a shell script ~/bin/start-session.sh in this script I have the 
command ssh-add < -


in System Settings > Startup and Shutdown > autostart I add this script 
as a login script

Re: Debian Jessie on AWS EC2

[Janne Lauros]

Hi!

 It seems to be possible to download it locally (
https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/). First I
thought it would not be as it is not an option in web console. Thanks for
the idea.

 BR Janne

On Wed, Mar 22, 2023 at 5:56 PM Jeremy Hendricks  wrote:

> Are you able to download the snapshot locally? If so and it’s not
> encrypted somehow, maybe it can be mounted up somehow. Otherwise, you’re
> probably at the mercy of AWS.
>
> On Wed, Mar 22, 2023 at 11:24 AM Janne Lauros 
> wrote:
>
>> Hi!
>>
>>  I have a really old snapshot in EC2 that I need to make it as volume and
>> mount it to copy some files from it. Unfortunately it is based on Debian
>> Jessie AMI (https://aws.amazon.com/marketplace/pp/prodview-5pgbnftzmrgec)
>> that cannot be subscribed to anymore thus making it impossible to mount the
>> volume. Are the some known workarounds to this, perhaps a way to activate
>> the subscription after shedding some tears first?
>>
>>  BR Janne
>>
>

Re: package name just before power off

[Greg Wooledge]

On Thu, Mar 23, 2023 at 10:50:48AM -0400, John wrote:
> I get an error message which is absolutely the last thing before poweroff 
> that is NOT ever reported in kern.log nor by dmesg. 
> 
> It reads like this:
> 48.255417 DMAR: DRHD: handling fault status reg 2
> 48.255457 DMR: [DMA Read] request device [00:17.0] PASID  fault addr 
> aboe9000 [fault reason 06] PTE read access is not set
> 48.27 reboot: Power down
> 
> What pack age would this be in so I can file a bug?

Those look like kernel messages.  A Google search leads me to
 which reports a
similar (but worse) experience.  You can start there, or try your own
luck with Google searches.

If you're experiencing an actual problem, you might try contacting
the Linux kernel mailing list.  If it's just a few lines of text with
no other symptoms, personally I'd just ignore it.

Re: package name just before power off

[The Wanderer]

On 2023-03-23 at 10:50, John wrote:

> I get an error message which is absolutely the last thing before
> poweroff that is NOT ever reported in kern.log nor by dmesg.

Typically, the very last messages from before power-off would be
expected to come from the kernel, as it should be the last thing still
running.

> It reads like this:
> 48.255417 DMAR: DRHD: handling fault status reg 2
> 48.255457 DMR: [DMA Read] request device [00:17.0] PASID  fault addr 
> aboe9000 [fault reason 06] PTE read access is not set
> 48.27 reboot: Power down
> 
> What pack age would this be in so I can file a bug?

Googling for parts of these messages find multiple bug reports on
kernel.org (I've seen at least one from 2016 and one from 2019, both
apparently about the relevant messages appearing in floods), so that
seems to confirm that these messages are coming from there.

It will probably be relevant what kernel you're running.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

package name just before power off

[John]

I get an error message which is absolutely the last thing before poweroff that 
is NOT ever reported in kern.log nor by dmesg. 

It reads like this:
48.255417 DMAR: DRHD: handling fault status reg 2
48.255457 DMR: [DMA Read] request device [00:17.0] PASID  fault addr 
aboe9000 [fault reason 06] PTE read access is not set
48.27 reboot: Power down

What pack age would this be in so I can file a bug?

Note, similar problems have been reported but this is unique:
1) It only occurs at power off but not on reboot. No other handling fault 
errors reported by dmesg
2) Nothing is shown in any kern.log files probably because it is too late to 
write anything

John

Re: ssh-add after graphical login

[Vincent Lefevre]

On 2023-03-23 09:42:53 +0100, Yassine Chaouche wrote:
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
> 
> What are my options?

FYI, with zsh, I'm using wrappers so that I don't need to run ssh-add
directly: it is run automatically when needed by ssh:

  https://www.vinc17.net/unix/zsh-ssh-utils.tar.xz

This is mainly based on code I wrote in 2003, with some improvements
since.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Boot Errors

[Toni Casueps]

When you get the "invalid argument" error do you see something in the output of 
"dmesg"?
Can you try to mount it from another distro live-USB or from the Debian 
installer rescue mode?

Enviado desde Outlook Mobile


From: Michael Lee 
Sent: Thursday, March 2, 2023 4:30:47 PM
To: debian-user@lists.debian.org 
Subject: Boot Errors

While running the stable branch of 64-bit Debian, rebooted into an
alternative OS, but forgot to unmount a USB device beforhand. Shutdown
was taking too long, so forced it anyway. Now when I try to start
Linux, I get these error messages:

[1.922640] platform gpio_ich.2.auto: failed to claim resource 0:[io
0x0480-0x04ff]
[8.934607] BTRFS error (device sdc2): parent transid verify faild on
176160768 wanted 680981 found 680979
[8.934649] BTRFS error (device sdc2): failed to read block groups 1 - 5
[8.935724] BTRFS error (device sdc2): open_ctree failed
mount: mounting /dev/sdc2 on /root failed: invalid argument
failed to mount /dev/sdc2 as root file system

Then the initramfs command prompt appears. A little hard to find much
on that.

Read in the btrfs wiki that <-o ro,usebackuproot> with the mount
command could help when the "wanted" and "found" numbers were not too
far apart.

mount -t btrfs -o ro,usebackuproot /dev/sdc2
TRIED with: /sysroot
GOT: mount: mounting /dev/sdc2 on /sysroot failed: invalid argument
TRIED with: /
GOT: mount: mounting /dev/sdc2 on / failed: invalid argument
TRIED with: /root
GOT: mount: mounting /dev/sdc2 on /root failed: invalid argument

Is this a GRUB issue, a btrfs issue, or must I reinstall the operating
system, and if so where can I find out which files must be preserved in
order to maintain continuity?

Re: nvidia package wrong documentation?

[Vincent Lefevre]

On 2023-03-22 10:50:30 +0100, Hans wrote:
> What I believe is, that the documentation from NVidia might be wrong
> and Nvidia told wrong, to say 390xx is for NVS4200.

I don't know for your case, but there are inconsistencies in the
Nvidia pages. For instance, for Quadro K610M, the 470.161.03 page
https://www.nvidia.com/Download/driverResults.aspx/194637/en-us/
does not list is as supported by 470.xx (and it is not listed at
all on
https://us.download.nvidia.com/XFree86/Linux-x86_64/470.161.03/README/supportedchips.html),
but both
https://us.download.nvidia.com/XFree86/Linux-x86_64/520.56.06/README/supportedchips.html
and
https://us.download.nvidia.com/XFree86/Linux-x86_64/525.89.02/README/supportedchips.html
list it as supported by 470.xx. I'm not sure what to do, but
anyway, Debian considered that 470.xx did not support it.

> On the other hand, it might be a bug, that the 340xx can not be build with 
> newer kernels (I 
> discovered the compilation is crashing due to some missing files. I filed a 
> bugreport of this 
> almost a year ago), which inhibits users, to use newer kernel-versions.

New kernels (and new versions of the X server) introduce
incompatibilities, and then Nvidia corrects their drivers.
Unfortunately for you, 340.xx is no longer supported by
Nvidia, and 390.xx isn't supported either.

> This is a pity especially for notebooks, where you can not exchange
> the GPU.

Yes, both my laptop and my desktop machine (at my lab) from 2015
are concerned (even for the desktop machine, it will be easier
to change it, though I could still use the old machine remotely
for various kinds of work).

> Oh, before someone tells: I do NOT want to use nouveau!

Though I would prefer free software, nouveau is not usable for me,
in particular with my laptop. Remember...

  https://lists.debian.org/debian-user/2020/05/msg00464.html

The developers did not care to look at my bug reports (this one
and older ones).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ssh-add after graphical login

[Jeffrey Walton]

On Thu, Mar 23, 2023 at 8:57 AM Greg Wooledge  wrote:
>
> On Thu, Mar 23, 2023 at 08:53:48AM -0400, Jeffrey Walton wrote:
> > On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
> >  wrote:
> > >
> > > I'd like something to run ssh-add right after I login to my desktop
> > > (KDE).
> > > ssh-add needs to prompt me for my passphrase,
> > > and doesn't need any privileges.
> > >
> > > What are my options?
> >
> > You can remove the passphrase from the key. Then your agents can use
> > the key unattended (without prompting you).
>
> While this is true, it's a really awful suggestion...

Agreed. OP wanted options.

Jeff

Re: ssh-add after graphical login

[Greg Wooledge]

On Thu, Mar 23, 2023 at 08:53:48AM -0400, Jeffrey Walton wrote:
> On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
>  wrote:
> >
> > I'd like something to run ssh-add right after I login to my desktop
> > (KDE).
> > ssh-add needs to prompt me for my passphrase,
> > and doesn't need any privileges.
> >
> > What are my options?
> 
> You can remove the passphrase from the key. Then your agents can use
> the key unattended (without prompting you).

While this is true, it's a really awful suggestion.  Removing the
passphrase from the key means that if the key is ever stolen, the
thief can use it to impersonate you in any context that accepts this
key.

Re: ssh-add after graphical login

[Jeffrey Walton]

On Thu, Mar 23, 2023 at 4:43 AM Yassine Chaouche
 wrote:
>
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
>
> What are my options?

You can remove the passphrase from the key. Then your agents can use
the key unattended (without prompting you).

Removing the passphrase from the key is no different than storing the
key in a KeyChain without protection so the key can be used unattended
by an agent.

Jeff

Re: vieux profileur prof ?

[Olivier Humbert]

Bonjour


Le 2023-03-23 09:10, Basile Starynkevitch a écrit :


Quel est le paquet Debian qui installe l'utilitaire prof ...


https://www.debian.org/distrib/packages#search_contents

Bonne journée

Re: ssh-add after graphical login

[Yassine Chaouche]

Le 3/23/23 à 12:24, Greg Wooledge a écrit :

 ssh-add 

Ah!
this is what I was missing!
the whole problem was how to ssh-add in a graphical way,
now that I have found a way,
I can maybe put it in a script inside the XDG Autostart directory.
This might leave more room for the ssh-agent to start,
and the whole desktop to launch
(KDE is somewhat slow on startup)

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: pilote pour radeon HD 4680G

[ajh-valmer]

On Thursday 23 March 2023 11:21:45 Cooper Laurent wrote:
> Ce qui est rageant, c'est qu'au démarrage, grub boote en mode graphique 
plein écran, en vesa, mais le vesa du noyau n'arrive pas à dépasser 640x480 
et le pilote radeon affiche des erreurs matérielles connues

C'est anormal d'avoir le pilote vesa.
C'est le mode graphique à minima 640x480 lorsque le pilote de la carte vidéo
n'est pas reconnu.

Re: ssh-add after graphical login

[Yassine Chaouche]

Le 3/23/23 à 12:56, basti a écrit :

The ssh config inside ~/.ssh/ has an option 'AddKeysToAgent'.
Why you don't use this?

For example:

Host *
    ControlMaster auto
    ControlPath /run/user/%i/%r@%h-%p
    IdentityFile ~/.ssh/id_rsa
    ControlPersist 3600
    User root
    AddKeysToAgent yes



This is actually an excellent suggestion,
as it also greatly simplifies how I login to remote hosts!
the command line use to be
ssh user@host -p port

now all I need to do is:
ssh host

Thanks again basti!

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: ssh-add after graphical login

[Michel Verdier]

Le 23 mars 2023 Greg Wooledge a écrit :

> The only part I'm unsure of, for you, is how to ensure that this runs
> *after* your ssh agent has already been started.  I don't know how ssh
> agent startup is handled with Display Manager logins, since I don't use
> a DM, and I just start ssh-agent myself, right before running ssh-add.

I let ssh-agent call gpg-agent. So I do nothing in .ssh/config and in my
.xsession I put :

unset SSH_AGENT_PID
SSH_ASKPASS=/usr/bin/ssh-askpass
SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
export SSH_ASKPASS SSH_AUTH_SOCK

gpg-agent is launched via systemd. In .gnupg/gpg-agent.conf I put :

pinentry-program /usr/bin/pinentry-gnome3
enable-ssh-support

Re: Bullseye (Debian11) doesn't renew dhcp lease

[hans]

On 23.03.2023 09:36, h...@hanswkraus.com wrote:


Hi,

a pc with a plain vanilla Debian11 doesn't renew the dhcp lease 
automatically, I have to do it per hand (systemctl stop ifup@$1.service 
&& systemctl start ifup@$1.service).


The "/var/lib/dhcp/dhclient.lan0.leases" file:
===
default-duid "\000\001\000\001+\255\242Y|\020\311\235\007\"";
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 7200;
option routers 172.23.136.1;
option dhcp-message-type 5;
option dhcp-server-identifier 172.23.136.1;
option domain-name-servers 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 3 2023/03/22 21:43:33;
rebind 3 2023/03/22 22:28:58;
expire 3 2023/03/22 22:43:58;
}/etc/systemd/network/10-board-1G.link
lease {
interface "lan0";
fixed-address 172.23.139.11;
option subnet-mask 255.255.248.0;
option routers 172.23.136.1;
option dhcp-lease-time 7200;
option dhcp-message-type 5;
option domain-name-servers 172.23.136.1;
option dhcp-server-identifier 172.23.136.1;
option domain-name "kraush.home.arpa";
renew 4 2023/03/23 09:02:59;
rebind 4 2023/03/23 09:51:21;
expire 4 2023/03/23 10:06:21;
}
===

I don't run network manager, the configuration files:
/etc/systemd/network/10-board-1G.link ==

# RJ45, 1G, on board

[Match]
MACAddress=7c:10:c9:9d:07:22

[Link]
Name=lan0
===

/etc/network/interfaces.d/lan0 
# /etc/network/interfaces.d/lan0

auto lan0
allow-hotplug lan0
iface lan0 inet dhcp
iface lan0 inet6 dhcp
===

Any help appreciated, Hans


By the way: this is a secondary IP connection. The primary one has a 
valid_lft "forever" and with that I don't have any problems.

Re: ssh-add after graphical login

[basti]

The ssh config inside ~/.ssh/ has an option 'AddKeysToAgent'.
Why you don't use this?

For example:

Host *
   ControlMaster auto
   ControlPath /run/user/%i/%r@%h-%p
   IdentityFile ~/.ssh/id_rsa
   ControlPersist 3600
   User root
   AddKeysToAgent yes

See man ssh_config

On 23.03.23 09:42, Yassine Chaouche wrote:

Hello all,

I'd like something to run ssh-add right after I login to my desktop
(KDE).
ssh-add needs to prompt me for my passphrase,
and doesn't need any privileges.

What are my options?

Best,

Re: ssh-add after graphical login

[Greg Wooledge]

On Thu, Mar 23, 2023 at 09:42:53AM +0100, Yassine Chaouche wrote:
> I'd like something to run ssh-add right after I login to my desktop
> (KDE).
> ssh-add needs to prompt me for my passphrase,
> and doesn't need any privileges.
> 
> What are my options?

On Debian you can create a ~/.xsessionrc file which is executed by
/bin/sh when starting an X session, either by DM login or startx.

Inside that file, you should be able to run:

ssh-add 

Re: what's the right way to resolve localhost's IPs

[Lee]

On 3/23/23, Nicolas George  wrote:
> Jeremy Ardley (12023-03-23):
>> On your second topic I don't usually run firewalls on my cloud severs.
>
> But surely on a server the network configuration is static, including
> the firewall rules, isn't it?

Consider the IP addressing info coming from DHCP.  The network
configuration stays the same but the IP(v6)? address might change.

For example, Verizon is my ISP; they delegate a /56 to my router and
the router delegates /64's to the LANs.  I've got DHCP configured to
give out static host addresses to the various machines but the network
portion of the ipv6 address does change at Verizon's whim .. which
requires firewall rule changes because I haven't figured out how to
automatically plug in the newly delegated /64 into the firewall rules
for that lan :(

Regards,
Lee

Re: good freedom-respecting computer for running Debian

[Lionel Élie Mamane]

On Wed, Mar 22, 2023 at 06:05:48PM -0500, Nate Bargmann wrote:
> * On 2023 22 Mar 14:06 -0500, Lionel Élie Mamane wrote:

>> Well, I was trying to see if one could get reasonable hardware that
>> doesn't have untrustable stuff like Intel ME and AMD PSP, (...)

> I understand.  I know there was a lot of speculation about it a
> couple years back or so but has it been conclusively determined that
> it acts in any nefarious manner?

While the question of:

 * Whether it acts nefariously on purpose by decision of Intel
   (whether that is credible to me depends on what one means by
"nefariously"; the Sony rootkit was "nefarious" in my opinion)

 * Whether your particular piece of hardware that you got was
   "intercepted" and changed to spy on you (like was routinely done
   e.g. on Cisco and telco hardware leaving the USA...)

 * Whether it still contains security bugs allowing an undetectable
   firmware rootkit to be installed without Intel's collaboration, and
   without access to Intel's signing keys

is at this point speculative, the fact that it allowed, for a long
time, installation of undetectable firmware rootkit is not.
https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine.pdf

I'd prefer a platform where the firmware is auditable (notwithstanding
the better wish for free software that I can modify), thank you very
much. This is becoming steadily more important; Russia and China don't
(our should not...) trust technology coming from the USA (for good
reasons), maybe from "the Western World" in general. In turn, China,
with its ever deeper "integration" between state intelligence and
technology companies... would/should "we the Western World" trust it?

If USA & Germany could, for decades, subvert the security of Crypto
AG, do we really want to "trust" that Intel, AMD, ... Oppo/OnePlus,
Huawei, Xiamo and ... Lenovo ... and ... IBM ... are not subverted?

If ASML collaborates with the USA to "block" Chinese capacity in chip
production, can we trust that NXP does not collaborate with USA
intelligence, in a world where we have known for decades that they
perform worldwide mass surveillance, injection of backdoors in
cryptography standards, etc?


Look at the situation and recent events around UEFI secure
boot... Microsoft is the sole gatekeeper to who/what can boot on an
amd64 PC out of the box (they are the _only_ ones whose bootloader
signing keys are in the firmware "out of the box"). It starts
innocuous enough, they setup a service where they (I assume for a
fee...) audit your bootloader and sign it. The whole GNU/Linux / free
OS ecosystem has done efforts to make their work in doing that, and
managing revocation / blocklisting of known vulnerable bootloader
versions, easier. They, by fiat, suddenly they decide that ... no, on
a certified machine, any non-Microsoft bootloader signed by Microsoft
_is_ _not_ allowed out of the box.
https://mjg59.dreamwidth.org/60248.html


So, no, having Intel, AMD, etc being the stewards... may have worked
OK for some time, but I don't want to lock us collectively into that,
if we can avoid it.

Lionel

Re : Re: Re : pilote pour radeon HD 4680G

[Cooper Laurent]

Merci d'avoir eu la gentillesse de vous pencher sur mon problème.

J'avais effectivement des firmware manquant. Mais l'installation de ces 
firmwares provoque une autre erreur. On se retrouve avec une regression connue 
sur ces cartes mobiles peu courantes et vieilles

Ce qui est rageant, c'est qu'au démarrage, grub boote en mode graphique plein 
écran, en vesa, mais le vesa du noyau n'arrive pas à dépasser 640x480 et le 
pilote radeon affiche des erreurs matérielles connues

À priori, avec une debian 9 ou 10 , ça pourrait passer. Il va falloir que je me 
penche sur les essais

Merci encore


Le 21/03/23 19:52, Étienne Mollier   a écrit : 
> 
> Bonsoir,
> 
> > Le 21/03/23 15:59, Laurent COOPER  a écrit : 
> > > J'installe des debian en mode kiosk sur de vieilles machines samsung qui 
> > > embarquait un logiciel "magicinfo"
> > > 
> > > Ces postes sont fabriqués autour du chipset AMD 3310 avec la puce 
> > > graphique AMD Radeon HD 6480G
> > > 
> > > Lorsque le poste démarre, grub est bien en plein écran en 1920x1080
> > > 
> > > Mais ensuite, une fois le noyau chargé et X lancé, c'est le pilote 
> > > framebuffer qui est en oeuvre, avec une résolution toute pourrie de 
> > > 760x480 !
> > > 
> > > Si je fais un modprobe, j'ai bien le module radeon, mais il ne semble pas 
> > > convenir pour X
> > > 
> > > Si j'installe firmare-amd-graphics, j'ai un écran noir et plus aucun 
> > > affichage
> 
> Cooper Laurent, on 2023-03-21:
> > Quant au module radeon, il est bien chargé, puis :
> > [ 5.859] (II) UnloadModule: "radeon"
> > [ 5.859] (EE) Screen 0 deleted because of no matching config section.
> 
> À vue de nez, ce n'est pas un problème de paquets manquants. Il
> devrait y avoir le pilote noyau "radeon" directement embarqué
> dans linux, le xserver-xorg-video-radeon devrait contenir le
> pilote en mode utilisateur pour Xorg. Quant au microprogramme,
> firmware-amd-graphics devrait supporter la HD 6480G :
> 
>   $ apt-cache show firmware-amd-graphics | grep -E '64(0|8)0'
>  * Radeon HD IGP 6400/6500/6600 series ME microcode
>  * Radeon HD IGP 6400/6500/6600 series PFP microcode
>  * Radeon HD IGP 6200/6300/6400/6500/6600/7300 series RLC microcode
> 
> L'apparition de l'écran noir quand les microprogrammes sont
> disponibles suggère que l'accélération graphique essaie de
> démarrer mais se plante pour une raison quelconque (ou pire,
> démarre sans se rendre compte que rien ne marche visuellement).
> Est-ce que la machine est accessible à distance, par exemple
> avec ssh, quand un écran noir se produit ? Est-ce qu'il y
> aurait des informations intéressantes dans le /var/log/kern.log,
> ou la sortie de la commande dmesg, dans une telle situation ?
> 
> Peut-être qu'il pourrait s'agir d'une régression dans le support
> d'un matériel devenu moins courant. Quelles versions de Debian
> avez vous tenté ?
> 
> En espérant que ça mette sur une piste,
> -- 
> Étienne Mollier 
> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
>

Re: vieux profileur prof ?

[Basile Starynkevitch]

On 23/03/2023 10:38, Pierre Malard wrote:

Salut,

Est-ce que tu veux dire « gprof » ?
Si oui, c’est dans le paquet « binutils ».

Sinon, peux-tu apporter plus de précisions sur cette commande ?



Non, c'est bien prof et pas GNU gprof que je cherche.


Il y a quelques années, les deux existaient, et prof était beaucoup plus 
léger, moins perturbateur et moins précis que gprof.



En fait je cherche un profileur simple (pour le moteur d'inférences 
RefPerSys  - en GPLv3+, multi-threadé, en C++, 
auquel je contribue https://github.com/RefPerSys/RefPerSys ...)



Je cherche à savoir quelles fonctions C++ consomment le plus de CPU (le 
cas test est lancé par make redump)


Il y a aussi dans certains cas un bouclage infini S'il existe une 
fonction C ou C++ qui écrit un fichier gprof.out je suis preneur






Merci

Le 23 mars 2023 à 09:10, Basile Starynkevitch 
 a écrit :


Bonjour,


Quel est le paquet Debian qui installe l'utilitaire prof compatible 
avec l'option 
 
-p de profilage de GCC  ?


(l'option -pg est plus précise, mais perturbe plus le calcul)


Merci

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page:starynkevitch.net/Basile/    
  



--
Pierre Malard

  «/ Les utopies ne sont souvent que des vérités prématurées /»
                Alphonse de Lamartine
   |\     _,,,---,,_
   /,`.-'`'   -.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) 
)-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'

- --> Ce message n’engage que son auteur <--


--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: vieux profileur prof ?

[Pierre Malard]

Salut,

Est-ce que tu veux dire « gprof » ?
Si oui, c’est dans le paquet « binutils ».

Sinon, peux-tu apporter plus de précisions sur cette commande ?

Merci

> Le 23 mars 2023 à 09:10, Basile Starynkevitch  a 
> écrit :
> 
> Bonjour,
> 
> 
> 
> Quel est le paquet Debian qui installe l'utilitaire prof compatible avec 
> l'option 
> 
>  -p de profilage de GCC  ?
> 
> (l'option -pg est plus précise, mais perturbe plus le calcul)
> 
> 
> 
> Merci
> 
> --
> Basile Starynkevitch   
> 
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/ & refpersys.org
> 

--
Pierre Malard

  « Les utopies ne sont souvent que des vérités prématurées »
  Alphonse de Lamartine
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: vieux profileur prof ? (x86-64/Debian/bookworm, C++ pour RefPerSys)

[Basile Starynkevitch]

On 23/03/2023 09:10, Basile Starynkevitch wrote:


Bonjour,


Quel est le paquet Debian qui installe l'utilitaire prof compatible 
avec l'option 
 
-p de profilage de GCC  ?


(l'option -pg est plus précise, mais perturbe plus le calcul)




J'ai la vague impression que pour GCC 12 Debian/bookworm/x86-64 les 
options -p et -pg sont identiques?



Quelqu'un peut-il confirmer? Je trouve ça surprenant!

Il y a plusieurs années c'était très différent, en précision comme en 
perturbation!



Merci

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: Doubler l'interface Ethernet d'un serveur par un adaptateur sur USB

[Sabri KHEMISSA]

Bonjour,

Il y a aussi le teaming qui est un peu plus riche en fonctionnalités que le
bonding :
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_systems_using_the_rhel_9_web_console/configuring-network-teams-using-the-web-console_system-management-using-the-rhel-9-web-console#comparison-of-network-teaming-and-bonding-features_configuring-network-teams-using-the-web-console

Au-delà des fonctionnalités, le principal avantage du bonding est qu'il
tourne au niveau Kernel : ce qui le rend beaucoup plus efficace que le
teaming.

Configuration bonding pour Debian : https://wiki.debian.org/Bonding
Configuration teaming pour Debian 11 / Debian 10 :
https://computingforgeeks.com/configure-network-nic-teaming-on-debian/

Bonne journée,

Bullseye (Debian11) doesn't renew dhcp lease

[hans]

Hi,

a pc with a plain vanilla Debian11 doesn't renew the dhcp lease 
automatically, I have to do it per hand (systemctl stop ifup@$1.service 
&& systemctl start ifup@$1.service).


The "/var/lib/dhcp/dhclient.lan0.leases" file:
===
default-duid "\000\001\000\001+\255\242Y|\020\311\235\007\"";
lease {
  interface "lan0";
  fixed-address 172.23.139.11;
  option subnet-mask 255.255.248.0;
  option dhcp-lease-time 7200;
  option routers 172.23.136.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier 172.23.136.1;
  option domain-name-servers 172.23.136.1;
  option domain-name "kraush.home.arpa";
  renew 3 2023/03/22 21:43:33;
  rebind 3 2023/03/22 22:28:58;
  expire 3 2023/03/22 22:43:58;
}/etc/systemd/network/10-board-1G.link
lease {
  interface "lan0";
  fixed-address 172.23.139.11;
  option subnet-mask 255.255.248.0;
  option routers 172.23.136.1;
  option dhcp-lease-time 7200;
  option dhcp-message-type 5;
  option domain-name-servers 172.23.136.1;
  option dhcp-server-identifier 172.23.136.1;
  option domain-name "kraush.home.arpa";
  renew 4 2023/03/23 09:02:59;
  rebind 4 2023/03/23 09:51:21;
  expire 4 2023/03/23 10:06:21;
}
===

I don't run network manager, the configuration files:
/etc/systemd/network/10-board-1G.link ==

# RJ45, 1G, on board

[Match]
MACAddress=7c:10:c9:9d:07:22

[Link]
Name=lan0
===

/etc/network/interfaces.d/lan0 
# /etc/network/interfaces.d/lan0

auto lan0
allow-hotplug lan0
iface lan0 inet dhcp
iface lan0 inet6 dhcp
===

Any help appreciated, Hans

ssh-add after graphical login

[Yassine Chaouche]

Hello all,

I'd like something to run ssh-add right after I login to my desktop
(KDE).
ssh-add needs to prompt me for my passphrase,
and doesn't need any privileges.

What are my options?

Best,

--
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche
Looking for side gigs.

Re: vieux profileur prof ?

[Basile Starynkevitch]

On 23/03/2023 09:25, Olivier Humbert wrote:

Bonjour


Le 2023-03-23 09:10, Basile Starynkevitch a écrit :


Quel est le paquet Debian qui installe l'utilitaire prof ...


https://www.debian.org/distrib/packages#search_content




Et bien je ne vois rien.

Alors, sachant que je compile http://refpersys.org/ (c'est du C++) avec 
GCC  12 et l'option -p (sur Debian/x86-64) comment 
trouver les statistiques de profilage après une exécution normale?



Merci

A

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: Doubler l'interface Ethernet d'un serveur par un adaptateur sur USB

[NoSpam]

Bonjour. Cela s'appelle du bonding

https://wiki.linuxfoundation.org/networking/bonding

Le 23/03/2023 à 08:40, Olivier a écrit :

Bonjour,

J'ai une machine distante de type NUC dont l'unique interface Ethernet
est mystérieusement devenue inutilisable.
Parallèlement à des recherches pour connaître et contrecarrer les
raisons qui l'ont rendu inutilisable, j'envisage de doubler
l'interface par un adaptateur Ethernet sur USB pour avoir un peu de
répit en cas de coup dur.

1. Cet adaptateur serait connecté sur le même switch que l'interface
Ethernet native.

2. Je préférerai que les 2 interfaces additionnent leur bande passante
et fonctionnent simultanément.

3. La configuration réseau actuelle (firewall, DHCP, VLAN...) de ces
serveurs reposant sur l'existence d'une interface réseau unique,
j'apprécierai que cette unicité logique puisse être conservée en
passant à deux interfaces.

4. En cas de défaillance d'une des deux interfaces (défaillance au
sens large, pas seulement en cas de déconnexion de l'interface),
l'autre doit pouvoir prendre le relai seule.

5. Les switchs auxquels ces serveurs sont connectés sont tous
manageables mais hétérogènes (Mikrotik sous RouterOS, Edgeswitch
d'Ubiquiti, DGS de DLink). Je peux accepter un paramétrage sur mesure
mais préférerai, bien sûr, un paramétrage côté serveur qui reste
fonctionnel en cas de remplacement d'un switch par un autre et qui
évite les catastrophes (boucles) en cas de mauvaise configuration du
switch.

Pour résumer, sur une machine donnée, j'ai une interface enpXs0 native
et une autre usbY.
Quelle fonction réseau de Debian ai-je intérêt à utiliser pour
regrouper ces deux interfaces sous une appellation brZ en respectant
les exigences ci-dessus (j'ai utilisé la notation brZ en référence aux
outils bridge mais je reste ouvert à d'autres outils, s'il y en a) ?

Slts

vieux profileur prof ?

[Basile Starynkevitch]

Bonjour,


Quel est le paquet Debian qui installe l'utilitaire prof compatible avec 
l'option 
 
-p de profilage de GCC  ?


(l'option -pg est plus précise, mais perturbe plus le calcul)


Merci

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/ & refpersys.org

Re: what's the right way to resolve localhost's IPs

[Jeremy Ardley]

On 23/3/23 15:42, Nicolas George wrote:

Jeremy Ardley (12023-03-23):

On your second topic I don't usually run firewalls on my cloud severs.

But surely on a server the network configuration is static, including
the firewall rules, isn't it?

On AWS the firewall rules are set by AWS themselves, though there is a 
console to adjust them. I normally only open up the incoming ports I am 
using. For ssh I only allow it from my personal IPv4 and IPv6 ranges


On Linode I just run bare with no firewall and only trusted services 
listening on a few ports. Linode do block outgoing port 25 and 485.


In a better world, in case my server were to be compromised, I'd set up 
to manage my outgoing such as rate limiting outgoing DNS requests and 
blocking other destination ports entirely.


I'm sure there is a list of destination ports this applies to?

--
Jeremy
(Lists)

Re: what's the right way to resolve localhost's IPs

[Nicolas George]

Jeremy Ardley (12023-03-23):
> On your second topic I don't usually run firewalls on my cloud severs.

But surely on a server the network configuration is static, including
the firewall rules, isn't it?

(Please imagine this mail set up on the Anakin/Padme meme template.)

Regards,

-- 
  Nicolas George

Doubler l'interface Ethernet d'un serveur par un adaptateur sur USB

[Olivier]

Bonjour,

J'ai une machine distante de type NUC dont l'unique interface Ethernet
est mystérieusement devenue inutilisable.
Parallèlement à des recherches pour connaître et contrecarrer les
raisons qui l'ont rendu inutilisable, j'envisage de doubler
l'interface par un adaptateur Ethernet sur USB pour avoir un peu de
répit en cas de coup dur.

1. Cet adaptateur serait connecté sur le même switch que l'interface
Ethernet native.

2. Je préférerai que les 2 interfaces additionnent leur bande passante
et fonctionnent simultanément.

3. La configuration réseau actuelle (firewall, DHCP, VLAN...) de ces
serveurs reposant sur l'existence d'une interface réseau unique,
j'apprécierai que cette unicité logique puisse être conservée en
passant à deux interfaces.

4. En cas de défaillance d'une des deux interfaces (défaillance au
sens large, pas seulement en cas de déconnexion de l'interface),
l'autre doit pouvoir prendre le relai seule.

5. Les switchs auxquels ces serveurs sont connectés sont tous
manageables mais hétérogènes (Mikrotik sous RouterOS, Edgeswitch
d'Ubiquiti, DGS de DLink). Je peux accepter un paramétrage sur mesure
mais préférerai, bien sûr, un paramétrage côté serveur qui reste
fonctionnel en cas de remplacement d'un switch par un autre et qui
évite les catastrophes (boucles) en cas de mauvaise configuration du
switch.

Pour résumer, sur une machine donnée, j'ai une interface enpXs0 native
et une autre usbY.
Quelle fonction réseau de Debian ai-je intérêt à utiliser pour
regrouper ces deux interfaces sous une appellation brZ en respectant
les exigences ci-dessus (j'ai utilisé la notation brZ en référence aux
outils bridge mais je reste ouvert à d'autres outils, s'il y en a) ?

Slts