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)

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 (end

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: 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: 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

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: 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