Re: dmesg ... XFS (sdb1): log I/O error ...

[tomas]

On Sat, Feb 25, 2023 at 06:24:23AM +, Albretch Mueller wrote:

[...]

I can't make too much heads or tails of it, but I'd focus
my suspicions on the USB part. USB ports (both sides),
cable and especially the power source for the disk: does
it have a separate source, or does it feed on the computer's
USB?

Cheers
- 
t


signature.asc
Description: PGP signature

Re: Debian bug report etiquette

[John Crawley]

Hi Jonathan, thank you for your advice.

On 24/02/2023 07:15, Jonathan Dowland wrote:


[ honouring Reply-To as set ]

Thanks, I'll drop that header in future.


Debian Python Team maintain a huge number of packages (>2,000). Things
can very easily slip through the cracks.

Indeed, and everyone's extra busy now with the upcoming bookworm release.


If you want to make it as easy as possible for someone with sufficient
privileges to upload a fix, you could fork/clone that repository, make
the necessary changes to the packaging source to include the patch (put
it in debian/patches, make any other necessary changes), and raise a
"Merge Request" on Salsa, pointing back at the Debian bug. Then the work
required to integrate the fix is as small as possible.

I've done this. [1]


Have you tried emailing the python packaging maintainers? They're listed
as Debian Python Team , although I'm not
sure where that mail goes. You could try that and if you hear nothing,
consider one of the Uploaders named on the package: they're the actual
humans who have looked after it.

If there's no response in a week or so I'll send an email.


You could consider adjusting the bug's Severity. Is the
relevant bit of Debian Policy that is violated described as a "must" or
"required" directive (or similar)? In which case raising the bug
severity to "serious" would be appropriate, and also cause the package
to be flagged for dropping from Bookworm unless the bug is resolved

Debian Policy 11.8.3 says:

To be an x-terminal-emulator, a program must:
Support the command-line option -e command, which creates a new terminal window 
and runs the specified command.
 may be multiple arguments, which form the argument list to the 
executed program.

I've sent a mail to cont...@bugs.debian.org to bump the severity to serious.


I'm curious therefore what is it about this particular bug that has
grabbed your attention?

I help to manage a small Debian derivative. [2] Our default terminal emulator 
used to be Terminator, and some of our users still like it. The recent issue 
has broken one of our utilities, if run with x-terminal-emulator set to 
terminator.

Thanks again!

[1] https://salsa.debian.org/python-team/packages/terminator/-/merge_requests/4
[2] https://wiki.debian.org/Derivatives/Census/BunsenLabs

--
John

dmesg ... XFS (sdb1): log I/O error ...

[Albretch Mueller]

I have been "heavily" downloading data from archive.org which I
actually need for my own corpora research from two different places.
One offering me 1.5MiB/s and the other 0.5MiB/s download speed.

Is my hard drive actually failing? (smartctl tells me it doesn't seem
to be the case) or are they or my ISP somehow hacking into my computer
to "motivate" such apparent errors?

How could I check either case? I have read about XFS needing special
care, but I would like to have a better idea of the source of such
errors first.

this is what I see on the screen when the drive is disconnected
somehow, but I always reconnected by clicking on its sign using the
GUI just fine. It doesn't sound like a failing drive either.

What could possibly going on?

$ kf.solid.backends.udisks2: Error getting props:
"org.freedesktop.DBus.Error.UnknownMethod" "No such interface
“org.freedesktop.DBus.Properties” on object at path
/org/freedesktop/UDisks2/drives/..."
...
$ sudo systemctl --user --failed
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and
$XDG_RUNTIME_DIR not defined (consider using --machine=@.host
--user to connect to bus of other user)

$ sudo dmesg
...
[22565.451321] usb-storage 1-1:1.0: USB Mass Storage device detected
[22565.451467] scsi host3: usb-storage 1-1:1.0
[22566.457236] scsi 3:0:0:0: Direct-Access ST16000N M001G-2KK103
   PQ: 0 ANSI: 5
[22566.457527] sd 3:0:0:0: Attached scsi generic sg2 type 0
[22566.457823] sd 3:0:0:0: [sdb] Very big device. Trying to use READ
CAPACITY(16).
[22566.457997] sd 3:0:0:0: [sdb] 31251759104 512-byte logical blocks:
(16.0 TB/14.6 TiB)
[22566.458365] sd 3:0:0:0: [sdb] Write Protect is off
[22566.458369] sd 3:0:0:0: [sdb] Mode Sense: 28 00 00 00
[22566.458640] sd 3:0:0:0: [sdb] No Caching mode page found
[22566.458644] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[22566.538074]  sdb: sdb1 sdb2
[22566.583373] sd 3:0:0:0: [sdb] Attached SCSI disk
[22575.515358] XFS (sdb1): Mounting V5 Filesystem
[22575.742880] XFS (sdb1): Starting recovery (logdev: internal)
[22575.919197] XFS (sdb1): Ending recovery (logdev: internal)
[22575.932002] xfs filesystem being mounted at
/media/user/77d8da74-a690-481a-86d5-9beab5a8e842 supports timestamps
until 2038 (0x7fff)
[22582.368977] usb 1-1: USB disconnect, device number 21
[22582.380548] XFS (sdb1): Unmounting Filesystem
[22582.380594] XFS (sdb1): log I/O error -5
[22582.380603] XFS (sdb1): xfs_do_force_shutdown(0x2) called from line
1211 of file fs/xfs/xfs_log.c. Return address = 9651f22d
[22582.380604] XFS (sdb1): Log I/O Error Detected. Shutting down filesystem
[22582.380605] XFS (sdb1): Please unmount the filesystem and rectify
the problem(s)
[22582.380608] XFS (sdb1): Unable to update superblock counters.
Freespace may not be correct on next mount.
...

$ sudo blkid
...
/dev/sdb1: UUID="77d8da74-a690-481a-86d5-9beab5a8e842"
BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="primary"
PARTUUID="f646c65f-bc46-4185-ba1e-583f157d6cb3"
...

$ sudo smartctl -l selftest /dev/sdb
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-18-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining
LifeTime(hours)  LBA_of_first_error
# 1  Extended offlineInterrupted (host reset)  00%   601 -
# 2  Extended offlineCompleted without error   00%96 -
# 3  Conveyance offline  Completed without error   00%74 -
# 4  Short offline   Completed without error   00%74 -
# 5  Extended offlineAborted by host   90%73 -
# 6  Short offline   Completed without error   00% 0 -

$

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Jeffrey Walton]

On Fri, Feb 24, 2023 at 9:51 PM David Wright  wrote:
>
> On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote:
> >  [...]
> I see you rebooted, and you get the same address. It's ambiguous as
> to why: it could have been stored, which makes things more efficient
> when a number of machines start up and don't have to renegotiate;
> or it could have been recomputed anew by a pseudorandom process on a
> host-dependent seed, which would generate the same sequence of tries
> each time you boot.

APIPA's use a deterministic process to generate the random host
portion of the address. They will generate the same host portion of
the address across reboots and restarts without the need to save
state.

Jeff

Re: Virtual machine affects client screen resolution

[Max Nikulin]

On 25/02/2023 00:55, Roy J. Tellason, Sr. wrote:

On Wednesday 22 February 2023 09:24:17 pm Max Nikulin wrote:

On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:

So this got me curious,  and I tried it out.  In the terminal that's
running inside of the virtualbox instance where I'm doing emails,  it
comes back with:

:0


Have you tried to emulate multiple monitors in virtualbox?


I'm not sure what I need to do with the computer to make this happen.


VirtualBox can emulate multiple monitors, they may be represented as 
several windows on the same physical device. It is convenient to test 
behavior of applications in the configuration with multiple monitors. 
There is an option in VM configuration UI.



But in a terminal which is running on the host Debian system,  it comes back 
with:

:0.0

I wonder why the difference?


My guess is that it may depend on graphics adapter and its driver.


It's an older machine with a VGA output being used.  I assume that I'll
need to get some kind of a card with an HDMI output and a cable to make
that happen.  No idea what the driver is,  probably nothing special.


It does not matter if it is special or not. My guess (that may be wrong) 
that even noveau vs. nvidia may behave differently. I have never gone 
deeper, since I do not remember any problem with setting DISPLAY=:0 when 
it was necessary. Driver in use should appear in Xorg.0.log, e.g.


(II) modeset(0): [DRI2]   DRI driver: i965


I have heard that a display may have several screens (it is not the same as 
multiple monitors that show
different regions of the same display and screen). I have never tried such 
configuration.


Are you referring to multiple desktops?  I have that going,  for sure.


My impression is that multiple screens of a display is not the same as 
virtual desktops (and not the same as multiple monitors). I am not 
familiar with X11 protocol so closely. Frankly speaking, I has a hope 
that somebody will post a proper link. My curiosity is not strong enough 
yet to filter search engine results myself.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[David Wright]

On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote:
> On Fri, Feb 24, 2023 at 01:25:55PM -0600, David Wright wrote:
> > On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> > > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> 
>   
> 
> > > > 
> > > > I mean IPv4 link local addresses 169.254.x.y. My impression is that
> > > > avahi-autoipd was created for the cases when there is no point to setup
> > > > centralized DHCP server. On the other hand I agree that a router (and so
> > > > DHCP out of the box) is more wide spread configuration than connecting a
> > > > couple of devices directly or through a switch.
> > > 
> > > I think so, too. 
> > 
> > Well, you typically only get a level of Recommended for avahi-autoipd
> > when you install on a laptop, which is a reasonable choice for the
> > debian-installer to make. Otherwise it's either a Suggests, or the
> > sysadmin has to choose it off their own bat. But I guess their are
> > a lot of laptops, now they are affordable, that aren't really used
> > in the way they were intended, but just as more flexible desktops.
> 
> Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
> 
> Ideas how to avoid it are  welcome.
> 
> 
> 
> $ dpkg -l '*avahi*ip*'
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name   Version  Architecture Description
> +++-==---=
> un  avahi-autoipd(no description available)
> $ uptime
>  22:45:25 up 1 min,  1 user,  load average: 0.02, 0.04, 0.05
> $ ip route | grep system
> 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 
> $ 
> 

I see you rebooted, and you get the same address. It's ambiguous as
to why: it could have been stored, which makes things more efficient
when a number of machines start up and don't have to renegotiate;
or it could have been recomputed anew by a pseudorandom process on a
host-dependent seed, which would generate the same sequence of tries
each time you boot.

A couple of odd points:

. I notice that certain files in the openvswitch packages seem to
  generate 169.254.… addresses,
. There's a long discussion about getting the network to come up
  in the right order, which seems to suggest that there's a fair
  chance of getting it wrong.

> Silence is hard to parse

It's ironic that this is your signature. AFAICT we've been told a
total of:

. you installed package openvswitch-switch,
. 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004
  is in the routing table in the company of ?,
. configured with network-manager? and systemd-networkd?
  (not sure how they interact),
. systemd-networkd-wait-online waits for any? interface to be up,
  but the tests are flawed, and the order seems to be of no concern
  notwithstanding the long discussion mentioned.

Cheers,
David.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Max Nikulin]

On 25/02/2023 04:43, Geert Stappers wrote:

Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"

Ideas how to avoid it are  welcome.


Have you checked "journalctl --boot" for logs which component assigns 
169.254.x.y address and for various errors related to network?


I am not familiar with openvswitch (or another package that really 
created ovs-system and ovsbr0), so I have no idea how they may be 
configured (systemd-networkd, NetworkManager, netplan, ifupdown) in your 
case and how to configure them properly. Perhaps it better to ask their 
community how to avoid failure of systemd-networkd-wait-online and 
assigning of IPv4LL address.


I have realized that your problem may be more general than just 
ovs-system, I do not like the following log line and which file is not 
found is not clear for me:

feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to 
update link state, ignoring: No such file or directory

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Fri 24 Feb 2023 at 10:19:38 (+0100), daven...@tuxfamily.org wrote:
> > […]
> > vpnc_script has about eight methods available for setting up and
> > reverting resolv.conf. Which is used depends on the presence of
> > a binary, checked in turn from this list:
> > 
> >   /etc/openwrt_release  modify_resolvconf_openwrt
> >   /usr/bin/resolvectl   modify_resolved_manager
> >   /usr/bin/busctl   modify_resolved_manager_old
> >   /sbin/resolvconf  modify_resolvconf_manager
> >   /sbin/netconfig   modify_resolvconf_suse_netconfig
> >   /sbin/modify_resolvconf   modify_resolvconf_suse
> >   /usr/sbin/unbound-control modify_resolvconf_unbound
> >   otherwise modify_resolvconf_generic
> > 
> > Perhaps you could check which of those binaries you have.
> 
> I have they two resolved_manager binaries, but since systemd-resolvd
> service is disabled and stopped on my system, I highly doubt these are
> used.
> It's more likely modify_resolvconf_generic
> 
> However, I didn't notice any vnpc_script malfunction. It does what it
> is expected to do. I'm like 99% sure the problem is dhclient deleting
> and recreating /etc/resolv.conf as it sees fit, multiple times a day,
> and deleting whatever vpnc_script has put in that file.

If that's the case, then unfortunately the vnpc_script gives you no
protection against that happening. All it appears to do, when you
connect, is to write:

  #@VPNC_GENERATED@ -- this file is generated by vpnc
  # and will be overwritten by vpnc
  # as long as the above mark is intact"

at the start of resolv.conf, so that when you disconnect, it can check
if that first string is still there and, if it is, restore the previous
contents of the file.

Meanwhile, anything else might overwrite the file, and if it does,
it's likely that the vnpc_script won't even be able to restore the
previous version of the file when you disconnect.

You'll notice that none of the other functions actually reference
resolv.conf itself, but will store the real file elsewhere, and
publish it through a symlink.

> > > > But how do you manage /etc/resolv.conf with connman. I don't use it,
> > 
> > Actually I was interested in what sets up your ordinary networking,
> > the one that uses your ISP, when you're not "at work" …
> 
> - ConnMan is used to manually connect to/disconnect from wired, and
> much less often wireless (wifi, bluetooth) networks
> - dhclient is used for DHCP request

They should work with either of the resolvconf packages that Debian
supplies, resolvconf and openresolv. I use the latter, as iwd documents
that it supports it. I know there are people on this list who use connman.

> - My OpenWRT router with DHCP is used as gateway for my subnet,
> answers to DHCP requests

I do much the same, with my router (two, actually) connected to the
ISP's ethernet connector.

> - Then there's is toward my ISP's all-in-one router/modem + TV set top
> box + telephony bullshit (I don't use anything but Interne, but ISP
> enforces their "triple play bullshit so I have to do with that all in
> one device… There's no alternatives for DOCSIS, Since I can't get FTTH
> yet, which my current router doesn't support yet, either way I'm
> dependant on ISP router)

Everything of ours runs from my router, so the ISP's is just a
glorified modem.

Cheers,
David.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Geert Stappers]

On Fri, Feb 24, 2023 at 01:25:55PM -0600, David Wright wrote:
> On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:

  

> > > 
> > > I mean IPv4 link local addresses 169.254.x.y. My impression is that
> > > avahi-autoipd was created for the cases when there is no point to setup
> > > centralized DHCP server. On the other hand I agree that a router (and so
> > > DHCP out of the box) is more wide spread configuration than connecting a
> > > couple of devices directly or through a switch.
> > 
> > I think so, too. 
> 
> Well, you typically only get a level of Recommended for avahi-autoipd
> when you install on a laptop, which is a reasonable choice for the
> debian-installer to make. Otherwise it's either a Suggests, or the
> sysadmin has to choose it off their own bat. But I guess their are
> a lot of laptops, now they are affordable, that aren't really used
> in the way they were intended, but just as more flexible desktops.

Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"

Ideas how to avoid it are  welcome.



$ dpkg -l '*avahi*ip*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
un  avahi-autoipd(no description available)
$ uptime
 22:45:25 up 1 min,  1 user,  load average: 0.02, 0.04, 0.05
$ ip route | grep system
169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 
$ 



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: CUPS - how to match autodetected printers to physical ones

[Brian]

On Fri 24 Feb 2023 at 12:58:15 -0500, Greg Wooledge wrote:

> On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> > Try this next time you're on site:
> > 
> > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere
> 
> This worked.  I printed two copies of the single-page PDF from Chrome
> without any further problems.

Good.

As I have previous indicated, this works because the vendor
has not used ipp/canon as the resource, which it is at
liberty to do so.

A previous off-target comment was

  > My burning hatred of printers and this printing system
  > remains unquenched.

Your hatred is aimed at completely the wrong target. How
is it expected to have CUPS discover a printer when mdns
multicasting is turned off on the printer by an incompetent
sysadmin?

> I've gotta say, though, this option is a disaster:
> 
>   -E  When specified before the -d, -p, or -x options, forces the use of
>   TLS encryption on the connection to the scheduler. Otherwise, enables
>   the destination and accepts jobs; this is the same as running the
>   cupsaccept(8) and cupsenable(8) programs on the destination.
> 
> Whoever decided to overload that option in that way... yikes.

I could tell you, but perthaps you might want to find out for
yourself instead of griping. Reporting (or searching) an issue
at

  https://github.com/OpenPrinting/cups/issues

might be easier than tackling the staff of your Help Desk.

-- 
Brian.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[David Wright]

On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote:
> Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > > [Unit]
> > > > > Description=A remote mail retrieval and forwarding utility
> > > > > After=network-online.target opensmtpd.service unbound.service
> > > > > Requires=opensmtpd.service unbound.service
> > ...
> > > In case of my fetchmail setup the culprit is unbound. At the startup
> > > of unbound it takes some time to exchange keys and so on.
> > 
> > I have no experience with unbound and I am not sure at which moment it
> > notifies systemd that the service is ready. However I have found a recent
> > bug
> > https://github.com/NLnetLabs/unbound/issues/773
> > "When used with systemd-networkd, unbound does not start until
> > systemd-networkd-wait-online.service times out"
> > 
> > Perhaps the package in Debian has an older version of the unbound.service
> > file and so is not affected.
> > 
> Hi Max,
> 
> I have observed lines below in journald:
> 
> Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online.
> Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be 
> Configured.
> Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: 
> Failed with result 'exit-code'.
> Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main 
> process exited, code=exited, status=1/FAILURE
> Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: 
> Connection timed out
> Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded.
> Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run)
> Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22
> Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs.
> 
> This looks related, thank you very much!

And does anything start up after wait-online expires? (I've never used it.)

> I will have a look at the link.
> > ...
> > > > However avahi-autoipd should be started concurrently
> > > > with network configuration to assign link-local address in the case of
> > > > failure.
> > > 
> > > In a different thread - it was about IPv6 which has mutated
> > > slightly - several users claimed that the avahi-autoip is useful for
> > > their business.
> > 
> > I mean IPv4 link local addresses 169.254.x.y. My impression is that
> > avahi-autoipd was created for the cases when there is no point to setup
> > centralized DHCP server. On the other hand I agree that a router (and so
> > DHCP out of the box) is more wide spread configuration than connecting a
> > couple of devices directly or through a switch.
> 
> I think so, too. 

Well, you typically only get a level of Recommended for avahi-autoipd
when you install on a laptop, which is a reasonable choice for the
debian-installer to make. Otherwise it's either a Suggests, or the
sysadmin has to choose it off their own bat. But I guess their are
a lot of laptops, now they are affordable, that aren't really used
in the way they were intended, but just as more flexible desktops.

Cheers,
David.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Christoph Brinkhaus]

Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin:
> On 22/02/2023 23:45, Christoph Brinkhaus wrote:
> > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > [Unit]
> > > > Description=A remote mail retrieval and forwarding utility
> > > > After=network-online.target opensmtpd.service unbound.service
> > > > Requires=opensmtpd.service unbound.service
> ...
> > In case of my fetchmail setup the culprit is unbound. At the startup
> > of unbound it takes some time to exchange keys and so on.
> 
> I have no experience with unbound and I am not sure at which moment it
> notifies systemd that the service is ready. However I have found a recent
> bug
> https://github.com/NLnetLabs/unbound/issues/773
> "When used with systemd-networkd, unbound does not start until
> systemd-networkd-wait-online.service times out"
> 
> Perhaps the package in Debian has an older version of the unbound.service
> file and so is not affected.
> 
Hi Max,

I have observed lines below in journald:

Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online.
Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be 
Configured.
Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed 
with result 'exit-code'.
Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: 
Connection timed out
Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded.
Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run)
Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22
Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs.

This looks related, thank you very much!
I will have a look at the link.
> ...
> > > However avahi-autoipd should be started concurrently
> > > with network configuration to assign link-local address in the case of
> > > failure.
> > 
> > In a different thread - it was about IPv6 which has mutated
> > slightly - several users claimed that the avahi-autoip is useful for
> > their business.
> 
> I mean IPv4 link local addresses 169.254.x.y. My impression is that
> avahi-autoipd was created for the cases when there is no point to setup
> centralized DHCP server. On the other hand I agree that a router (and so
> DHCP out of the box) is more wide spread configuration than connecting a
> couple of devices directly or through a switch.

I think so, too. 

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: hplip : looking for a workaround

[Erwan David]

Le 24/02/2023 à 18:41, Brian a écrit :

On Fri 24 Feb 2023 at 18:25:24 +0100, Erwan David wrote:


Le 24/02/2023 à 17:45, Brian a écrit :

On Wed 22 Feb 2023 at 17:49:13 +0100, Erwan David wrote:


Hi,

hplip seems to need a dependency, many commands end with

    File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
      distro_name = get_distro_std_name(os_name)
    ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean:
'get_distro_name'?

I opend a bug for a missing dependency, but do someone know of a workaround
? I cannot use my scanner anymore because it needs a binary plugin installed
by hplip

Your issue and a workaround has been addressed. However, knowung
the device model just might lead to a better solution.


It is a LaserJet_Pro MFP M125nw

This is a little unfortunate. My records show this device to be
capable of driverless printing, but not of driverless scanning.
The later can be ascertained by running

   avahi-browse -rt _uscan._tcp

An empty output is bad news.

It appears you have to rely on the non-free plugin and the
workaround.

Yes no problem with printing, only with scanning... (for driverless alas 
I did not find how to make it work when printer and computer are not on 
same network).

Re: CUPS - how to match autodetected printers to physical ones

[Greg Wooledge]

On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote:
> Try this next time you're on site:
> 
> lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere

This worked.  I printed two copies of the single-page PDF from Chrome
without any further problems.

I've gotta say, though, this option is a disaster:

  -E  When specified before the -d, -p, or -x options, forces the use of
  TLS encryption on the connection to the scheduler. Otherwise, enables
  the destination and accepts jobs; this is the same as running the
  cupsaccept(8) and cupsenable(8) programs on the destination.

Whoever decided to overload that option in that way... yikes.

Re: Virtual machine affects client screen resolution

[Roy J. Tellason, Sr.]

On Wednesday 22 February 2023 09:24:17 pm Max Nikulin wrote:
> 
> On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:
> > On Saturday 18 February 2023 12:17:20 am Max Nikulin wrote:
> >> echo "$DISPLAY"
> > 
> > So this got me curious,  and I tried it out.  In the terminal that's
> > running inside of the virtualbox instance where I'm doing emails,  it
> > comes back with:
> > 
> > :0
> 
> Have you tried to emulate multiple monitors in virtualbox?

Not yet.  I would like to go to multiple monitors at some point,  particularly 
once I get going with some of the CAD stuff I have installed that I really 
haven't done anything much with yet.  I'm not sure what I need to do with the 
computer to make this happen.
 
> > But in a terminal which is running on the host Debian system,  it comes 
> > back with:
> > 
> > :0.0
> > 
> > I wonder why the difference?
> 
> My guess is that it may depend on graphics adapter and its driver. 

It's an older machine with a VGA output being used.  I assume that I'll need to 
get some kind of a card with an HDMI output and a cable to make that happen.  
No idea what the driver is,  probably nothing special.

> I have heard that a display may have several screens (it is not the same as 
> multiple monitors that show
> different regions of the same display and screen). I have never tried such 
> configuration.

Are you referring to multiple desktops?  I have that going,  for sure.


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

Re: hplip : looking for a workaround

[Erwan David]

Le 24/02/2023 à 17:45, Brian a écrit :

On Wed 22 Feb 2023 at 17:49:13 +0100, Erwan David wrote:


Hi,

hplip seems to need a dependency, many commands end with

   File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
     distro_name = get_distro_std_name(os_name)
   ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean:
'get_distro_name'?

I opend a bug for a missing dependency, but do someone know of a workaround
? I cannot use my scanner anymore because it needs a binary plugin installed
by hplip

Your issue and a workaround has been addressed. However, knowung
the device model just might lead to a better solution.


It is a LaserJet_Pro MFP M125nw

Re: hplip : looking for a workaround

[Erwan David]

Le 22/02/2023 à 18:46, Celejar a écrit :

On Wed, 22 Feb 2023 17:49:13 +0100
Erwan David  wrote:


Hi,

hplip seems to need a dependency, many commands end with

    File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
      distro_name = get_distro_std_name(os_name)
    ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean:
'get_distro_name'?

I opend a bug for a missing dependency, but do someone know of a
workaround ? I cannot use my scanner anymore because it needs a binary
plugin installed by hplip

This is your bug:

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

but this earlier bug discussion contains a workaround (I haven't tried
it):

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

FTR, here's the upstream bug:

https://bugs.launchpad.net/hplip/+bug/2003739

Thanks the workaround in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029459 worked.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Max Nikulin]

On 22/02/2023 23:45, Christoph Brinkhaus wrote:

Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:

On 22/02/2023 01:26, Christoph Brinkhaus wrote:

[Unit]
Description=A remote mail retrieval and forwarding utility
After=network-online.target opensmtpd.service unbound.service
Requires=opensmtpd.service unbound.service

...

In case of my fetchmail setup the culprit is unbound. At the startup
of unbound it takes some time to exchange keys and so on.


I have no experience with unbound and I am not sure at which moment it 
notifies systemd that the service is ready. However I have found a 
recent bug

https://github.com/NLnetLabs/unbound/issues/773
"When used with systemd-networkd, unbound does not start until 
systemd-networkd-wait-online.service times out"


Perhaps the package in Debian has an older version of the 
unbound.service file and so is not affected.


...

However avahi-autoipd should be started concurrently
with network configuration to assign link-local address in the case of
failure.


In a different thread - it was about IPv6 which has mutated
slightly - several users claimed that the avahi-autoip is useful for
their business.


I mean IPv4 link local addresses 169.254.x.y. My impression is that 
avahi-autoipd was created for the cases when there is no point to setup 
centralized DHCP server. On the other hand I agree that a router (and so 
DHCP out of the box) is more wide spread configuration than connecting a 
couple of devices directly or through a switch.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:
> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Then use one of the methods listed at 
to address that, and see if it fixes the problem.

The simplest one to test would be
.  It doesn't
involve installing any new packages.

If your testing is successful (e.g. a whole day goes by and the
resolv.conf file is not unexpectedly altered), then things get a little
bit trickier.  If I understand correctly, you're working on a laptop,
and your desired configuration is:

 * At boot time, allow the DHCP client to set up resolv.conf.

 * Once that has been done, disallow all further modifications of
   resolv.conf by the DHCP client.

 * Allow modifications of resolv.conf by vpnc_script at any time.

The tricky part here is how to write a function that determines whether
dhclient should be allowed to modify the file ("is it boot time") or not.
Perhaps you could use something awful like "if the system uptime is less
than 5 minutes, allow it".

Another hack that comes to mind would be writing something that removes
the resolv.conf file at shutdown time.  Then, the dhclient hook function
would allow dhclient to write the file if and only if it doesn't exist.

Or... the reverse of this.  Keep a second file which serves as a flag
indicating that the resolv.conf file has already been configured once.
Remove this flag at boot time (make sure that happens *early*, before
dhclient is started), and then write your dhclient hook function to
allow the modification if and only if the flag file doesn't exist.  Then
create the flag file after doing the modification.

I'm not sure which of those is the least bad.  Maybe you can come up
with some other ideas.

Re: dell OptiPlex

[Dan Ritter]

Matthew Norris wrote: 
> Hi everyone!
> Matt here. Years ago I had Debian on a disk with an awesome package and I
> told myself I was always going to start again. I have been out of
> circulation for some time. I have this Dell Optiplex with 32 RAM and an SSD
> with an Intel  i5-4590 CPU. Can I install and use Debian as my daily
> driver? If so, show me the way. I would like to put it on a stick first
> maybe. I appreciate your help.


Yes; I have a similar machine from HP which has been my desktop
at work since 2015. (For Linux desktops, my employer doesn't
replace them automatically, only on request.)


-dsr-

Re: dell OptiPlex

[David Christensen]

On 2/24/23 00:06, Matthew Norris wrote:

Hi everyone!
Matt here. Years ago I had Debian on a disk with an awesome package and I
told myself I was always going to start again. I have been out of
circulation for some time. I have this Dell Optiplex with 32 RAM and an SSD
with an Intel  i5-4590 CPU. Can I install and use Debian as my daily
driver? If so, show me the way. I would like to put it on a stick first
maybe. I appreciate your help.
thanks,
Matt



That should be more than enough computer for a Debian graphical desktop.
Which model Optiplex?  What type of SSD?  Size?


First, backup your data before you do anything.  The saying is "data 
does not exist unless it exists in three places".  The first place is 
the live data-- HDD/ SSD/ RAID, internal or external, NAS, file server, 
etc.  The second place is the current backups -- HDD, external or in 
another computer.  The third place is the previous backups -- HDD, 
external or in another computer; stored off-site.  Rotate the second and 
third copies periodically.  It is wise to also burn fourth copies to 
read-only media (e.g. CD/DVD/BD-R) periodically and archive them off-site.



Understand that the computer hobby is like the collector car hobby -- 
you need at least two: one to drive while you wrench on the others.  You 
should have a current and supported Windows instance available at all times.



If you have only one computer and it has Windows 10 or 11, I suggest 
leaving Windows as-is and running Debian in a virtual machine.  Once you 
figure out keyboard mappings and switch to full screen mode, it's 99% 
the experience of a hardware install.  And, because hypervisors provide 
a known virtual hardware platform, a FOSS should "just install" and 
"just work".  I ran a Debian graphical desktop as my daily driver on 
VirtualBox on macOS for a few years; it worked very nicely.



I tried dual-boot back in the day.  Then I installed mobile racks in my 
computers, bought several drives, and put each OS instance on its own 
drive.  For operations, I only insert one OS drive at a time into each 
computer.  (My data is on other drives.)



As for USB installation, I have been putting various Linux and FreeBSD 
distributions onto SanDisk Ultra Fit USB 3.0 16 GB flash drives for many 
years (~$10).  This works well as a boot and root drive for headless 
servers, firewall/ routers, etc..  It also works as a portable graphical 
sysadmin toolbox.  But it does not work well as a daily driver -- the 
experience becomes choppy whenever the OS is writing to the flash drive. 
 A low-power 2.5" SATA SSD and USB to SATA adapter cable is a much 
better experience (~$50).  If you have more money, there are faster 
external solutions.



Download a Debian installer image:

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.6.0-amd64-netinst.iso


Burn the image to installation media:

- If the machine has a CD/DVD/BD-RW drive, an optical disc has 
advantages -- Windows machines with RW optical drives typically come 
with burning software, the checksum of the installation media should 
never change, there is less potential for confusing the target drive 
when installing Debian, and the target drive should be device node 
/dev/sda during installation and once Debian is installed and running. 
But, installation time is slower (especially on laptop slim drives).


- A USB flash drive has advantages -- compact size and faster 
installation.  But, USB flash drives are read-write (unless you have one 
with a write protect switch), so the running installer can change their 
contents, so the installation media checksum can change, so you cannot 
verify the installation media the next time you want to install.  And, 
the target drive can be device node /dev/sdb during installation and 
leave leftovers in crypttab(5) once Debian is installed and running.



Getting the ISO onto media can be a chicken-and-egg problem.  I started 
with purchased CD's.  Later, I downloaded ISO's and burned my own discs 
with Windows or Linux.  Now I burn USB flash drives with Debian or FreeBSD.



David

Re: dell OptiPlex

[Jeffrey Walton]

On Fri, Feb 24, 2023 at 3:24 AM Matthew Norris
 wrote:
>
> [...] I have this Dell Optiplex with 32 RAM and an SSD with an Intel  i5-4590 
> CPU. Can I install and use Debian as my daily driver?

Most likely. A Core i5 is a 64-bit processor circa 2014; see
https://ark.intel.com/content/www/us/en/ark/products/80815/intel-core-i54590-processor-6m-cache-up-to-3-70-ghz.html
.

I say "most likely" because I presume you won't have too much trouble
with the Dell BIOS from that era.

> If so, show me the way.

https://www.debian.org/releases/bullseye/installmanual

Jeff

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Fri, Feb 24, 2023 at 11:27:40AM +0100, daven...@tuxfamily.org wrote:

> [...] totally agree logs are better than suspicion

But please, don't take my snark all too seriously. On reread I
realize it might have sounded harsher than it was meant.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

On 2023-02-24 10:27, to...@tuxteam.de wrote:

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

However, I didn't notice any vnpc_script malfunction. It does what it 
is

expected to do. I'm like 99% sure the problem is dhclient deleting and
recreating /etc/resolv.conf as it sees fit, multiple times a day, and
deleting whatever vpnc_script has put in that file.


Instead of 99% suspicions you could just look into your 
/var/log/syslog:

dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers


Goode point. Thank you for the reminder :)

I do only partial week remote work, been in the office the last days.
So in order for the problem to happen again, I need to wait monday, only 
then I might dig into the log files.


The thing is: at first, I didn't suspect dhclient until recently (after 
I started this thread) so I need to wait for the next remote work day.
During my last days of remote work, I just used auditd to see if I can 
see process name when the file is deleted/recreated.
The event was captured by auditd but the process name was missing from 
the audit.log file, so I had no idea what's to look for., in which log 
file(s).


I'm still sure it isn't vpnc_script. vpnc_script leaves identification 
comments on the file
And dhclient is more like to know only about what my home's DHCP tells 
it, than my work's place DNS resolver, that's why I suspect dhclient.
BUT I will make sure to take some time to dig into the logs monday. Now 
that I have an idea what I'm looking for, totally agree logs are better 
than suspicion

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[tomas]

On Fri, Feb 24, 2023 at 10:19:38AM +0100, daven...@tuxfamily.org wrote:

[...]

> However, I didn't notice any vnpc_script malfunction. It does what it is
> expected to do. I'm like 99% sure the problem is dhclient deleting and
> recreating /etc/resolv.conf as it sees fit, multiple times a day, and
> deleting whatever vpnc_script has put in that file.

Instead of 99% suspicions you could just look into your /var/log/syslog:
dhclient does leave enough traces there. Bonus point if you correlate
these timestamps with your resolv.conf mod time :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello,


[…]
vpnc_script has about eight methods available for setting up and
reverting resolv.conf. Which is used depends on the presence of
a binary, checked in turn from this list:

  /etc/openwrt_release  modify_resolvconf_openwrt
  /usr/bin/resolvectl   modify_resolved_manager
  /usr/bin/busctl   modify_resolved_manager_old
  /sbin/resolvconf  modify_resolvconf_manager
  /sbin/netconfig   modify_resolvconf_suse_netconfig
  /sbin/modify_resolvconf   modify_resolvconf_suse
  /usr/sbin/unbound-control modify_resolvconf_unbound
  otherwise modify_resolvconf_generic

Perhaps you could check which of those binaries you have.



I have they two resolved_manager binaries, but since systemd-resolvd 
service is disabled and stopped on my system, I highly doubt these are 
used.

It's more likely modify_resolvconf_generic

However, I didn't notice any vnpc_script malfunction. It does what it is 
expected to do. I'm like 99% sure the problem is dhclient deleting and 
recreating /etc/resolv.conf as it sees fit, multiple times a day, and 
deleting whatever vpnc_script has put in that file.





> But how do you manage /etc/resolv.conf with connman. I don't use it,


Actually I was interested in what sets up your ordinary networking,
the one that uses your ISP, when you're not "at work" …


- ConnMan is used to manually connect to/disconnect from wired, and much 
less often wireless (wifi, bluetooth) networks

- dhclient is used for DHCP request
- My OpenWRT router with DHCP is used as gateway for my subnet, answers 
to DHCP requests
- Then there's is toward my ISP's all-in-one router/modem + TV set top 
box + telephony bullshit (I don't use anything but Interne, but ISP 
enforces their "triple play bullshit so I have to do with that all in 
one device… There's no alternatives for DOCSIS, Since I can't get FTTH 
yet, which my current router doesn't support yet, either way I'm 
dependant on ISP router)





Otherwise, when VPN is disconnected, I DO want /etc/resolv.conf to be
generated according to my home router's DHCP tells the computer


… yes, that one.

Cheers,
David.

Re: Whole-disk RAID and GPT/UEFI

[David Christensen]

On 2/23/23 11:05, Tim Woodall wrote:

On Wed, 22 Feb 2023, Nicolas George wrote:

Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?



I've wanted this ...



I think only hardware raid where the bios thinks it's a single disk ...



My wants and thinking are the same.  I can and do FOSS RAID for data 
disks, but I am baffled for boot disks.



I did desktop motherboard simple hardware RAID years ago (0, 1, 10, 
JBOD; Intel Matrix Storage Technology?).  It was configured via BIOS 
Setup.  I seem to recall that both Windows and Linux saw the RAID as a 
single SATA HDD.  Under Windows, you could download an Intel driver and 
controller app to configure and/or monitor the RAID.  I do not recall a 
driver and app for Linux.



I believe my newer motherboards/ computers also include simple hardware 
RAID.  The current Intel solution is Rapid Storage Technology.  I 
believe this is enabled on my Dells via UEFI Setup -> Settings -> System 
Configuration -> SATA Operation -> "RAID On", but I have not attempted 
to build a RAID.  (Do I need the Windows driver and app?)  I have 
discovered that Linux cannot see the disks unless the setting is changed 
to "AHCI" (?), and am curious why.



I have some 2-port SATA HBA's and believe they also support simple 
hardware RAID.  I assume they have a BIOS extension/ POST hotkey 
configuration utility, with drivers and apps for Windows.  I have used 
them in BIOS computers back in the day and in UEFI computers with 
backwards compatibility, but I do not know if they would work in the 
newest UEFI-only computers; especially with Secure Boot.



Hardware is again becoming a walled garden more so every day; especially 
with Windows 11, TPM 2, and whatever Apple does.  I look forward to open 
source hardware, such as RISC-V.



David

dell OptiPlex

[Matthew Norris]

Hi everyone!
Matt here. Years ago I had Debian on a disk with an awesome package and I
told myself I was always going to start again. I have been out of
circulation for some time. I have this Dell Optiplex with 32 RAM and an SSD
with an Intel  i5-4590 CPU. Can I install and use Debian as my daily
driver? If so, show me the way. I would like to put it on a stick first
maybe. I appreciate your help.
thanks,
Matt