Re: procps with sysvinit: libsystemd0 vs libelogind0

2023-10-16 Thread David Wright
On Mon 16 Oct 2023 at 16:05:48 (-0700), Bill Brelsford wrote:
> The latest version of procps (2:4.0.4-2) depends on libsystemd0, so
> upgrading 2:4.0.3-1 to it causes libsystemd0 to be installed.  But
> on my sysvinit system it conflicts with libelogind0:
> 
>   libelogind0 : Conflicts: libsystemd0 but 254.5-1 is to be installed

At least in 246.10, libelogind0 should also replace and provide
libsystemd0, which means APT shouldn't try to install libsystemd0.

Is it possible that you've unluckily updated your lists while
the repository was being updated, in which case, a brief wait
and then re-updating might fix the problem.

Cheers,
David.



Re: network bonding on Debian/Trixie

2023-10-16 Thread Igor Cicimov
On Tue, Oct 17, 2023 at 12:12 PM Gary Dale  wrote:

> On 2023-10-16 18:52, Igor Cicimov wrote:
>
> Hi,
>
> On Tue, Oct 17, 2023, 8:00 AM Gary Dale  wrote:
>
>> I'm trying to configure network bonding on an AMD64 system running
>> Debian/Trixie. I've got a wired connection and a wifi connection, both
>> of which work individually. I'd like them to work together to improve
>> the throughput but for now I'm just trying to get the bond to work.
>> However when I configure them, the wifi interface always shows down.
>>
>> # ip addr
>> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
>> group default qlen 1000
>>  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>  inet 127.0.0.1/8 scope host lo
>> valid_lft forever preferred_lft forever
>>  inet6 ::1/128 scope host noprefixroute
>> valid_lft forever preferred_lft forever
>> 2: enp10s0:  mtu 1500 qdisc mq
>> master bond0 state UP group default qlen 1000
>>  link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
>> 4: wlxc4411e319ad5:  mtu 1500 qdisc noop state DOWN
>> group default qlen 1000
>>  link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
>> 7: bond0:  mtu 1500 qdisc
>> noqueue state UP group default qlen 1000
>>  link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
>>  inet 192.168.1.20/24 brd 192.168.1.255 scope global bond0
>> valid_lft forever preferred_lft forever
>>  inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
>> valid_lft forever preferred_lft forever
>>
>> It does this even if I pull the cable from the wired connection. The
>> wifi never comes up.
>>
>> Here's the /etc/network/interfaces file:
>>
>> auto lo
>> iface lo inet loopback
>>
>> auto enp10s0
>> iface enp10s0 inet manual
>>  bond-master bond0
>>  bond-mode 1
>>
>> auto wlxc4411e319ad5
>> iface wlxc4411e319ad5 inet manual
>>  bond-master bond0
>>  bond-mode 1
>>
>> auto bond0
>> iface bond0 inet static
>>  address 192.168.1.20
>>  netmask 255.255.255.0
>>  network 192.168.1.0
>>  gateway 192.168.1.1
>>  bond-slaves enp10s0 wlxc4411e319ad5
>>  bond-mode 1
>>  bond-miimon 100
>>  bond-downdelay 200
>>  bond-updelay 200
>>
>>
>> I'd like to get it to work in a faster mode but for now the backup at
>> least allows the networking to start without the wifi. Other modes seem
>> to disable networking until both interfaces come up, which is not a good
>> design decision IMHO. At least with mode 1, the network starts.
>>
>> Any ideas on how to get the wifi to work in bonding?
>>
>
> Probably your wifi card does not support MII, check with:
>
> ~]# ethtool  wlxc4411e319ad5 | grep "Link detected:"
>
> and:
>
> ~]# cat /proc/net/bonding/bind0
>
>
> I'm assuming that no output is bad here. Still, I don't see why a device
> that works shouldn't be able to participate in a bond. As a network
> interface, the wifi device produces and responds to network traffic. Are
> you saying the bonding takes place below the driver level?
>
>
> I'm saying the bonding driver is doing its own link detection on the
presented interfaces for failover purposes. It can use ARP or MII. You can
not enable MII on an interface that does not support that functionality.
Use mii-tool to check both interfaces and see the difference.


Re: network bonding on Debian/Trixie

2023-10-16 Thread Gary Dale

On 2023-10-16 18:52, Igor Cicimov wrote:

Hi,

On Tue, Oct 17, 2023, 8:00 AM Gary Dale  wrote:

I'm trying to configure network bonding on an AMD64 system running
Debian/Trixie. I've got a wired connection and a wifi connection,
both
of which work individually. I'd like them to work together to improve
the throughput but for now I'm just trying to get the bond to work.
However when I configure them, the wifi interface always shows down.

# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8  scope host lo
    valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host noprefixroute
    valid_lft forever preferred_lft forever
2: enp10s0:  mtu 1500 qdisc mq
master bond0 state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
4: wlxc4411e319ad5:  mtu 1500 qdisc noop
state DOWN
group default qlen 1000
 link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
7: bond0:  mtu 1500 qdisc
noqueue state UP group default qlen 1000
 link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.20/24  brd
192.168.1.255 scope global bond0
    valid_lft forever preferred_lft forever
 inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
    valid_lft forever preferred_lft forever

It does this even if I pull the cable from the wired connection. The
wifi never comes up.

Here's the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto enp10s0
iface enp10s0 inet manual
 bond-master bond0
 bond-mode 1

auto wlxc4411e319ad5
iface wlxc4411e319ad5 inet manual
 bond-master bond0
 bond-mode 1

auto bond0
iface bond0 inet static
 address 192.168.1.20
 netmask 255.255.255.0
 network 192.168.1.0
 gateway 192.168.1.1
 bond-slaves enp10s0 wlxc4411e319ad5
 bond-mode 1
 bond-miimon 100
 bond-downdelay 200
 bond-updelay 200


I'd like to get it to work in a faster mode but for now the backup at
least allows the networking to start without the wifi. Other modes
seem
to disable networking until both interfaces come up, which is not
a good
design decision IMHO. At least with mode 1, the network starts.

Any ideas on how to get the wifi to work in bonding?


Probably your wifi card does not support MII, check with:

~]# ethtool  wlxc4411e319ad5 | grep "Link detected:"

and:

~]# cat /proc/net/bonding/bind0



I'm assuming that no output is bad here. Still, I don't see why a device 
that works shouldn't be able to participate in a bond. As a network 
interface, the wifi device produces and responds to network traffic. Are 
you saying the bonding takes place below the driver level?




procps with sysvinit: libsystemd0 vs libelogind0

2023-10-16 Thread Bill Brelsford
The latest version of procps (2:4.0.4-2) depends on libsystemd0, so
upgrading 2:4.0.3-1 to it causes libsystemd0 to be installed.  But
on my sysvinit system it conflicts with libelogind0:

  libelogind0 : Conflicts: libsystemd0 but 254.5-1 is to be installed

Should I let libsystemd0 replace libelogind0?  I don't remember if
that would cause other problems.

Thanks..  Bill



Re: network bonding on Debian/Trixie

2023-10-16 Thread Igor Cicimov
Hi,

On Tue, Oct 17, 2023, 8:00 AM Gary Dale  wrote:

> I'm trying to configure network bonding on an AMD64 system running
> Debian/Trixie. I've got a wired connection and a wifi connection, both
> of which work individually. I'd like them to work together to improve
> the throughput but for now I'm just trying to get the bond to work.
> However when I configure them, the wifi interface always shows down.
>
> # ip addr
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>  inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
>  inet6 ::1/128 scope host noprefixroute
> valid_lft forever preferred_lft forever
> 2: enp10s0:  mtu 1500 qdisc mq
> master bond0 state UP group default qlen 1000
>  link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
> 4: wlxc4411e319ad5:  mtu 1500 qdisc noop state DOWN
> group default qlen 1000
>  link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
> 7: bond0:  mtu 1500 qdisc
> noqueue state UP group default qlen 1000
>  link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
>  inet 192.168.1.20/24 brd 192.168.1.255 scope global bond0
> valid_lft forever preferred_lft forever
>  inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
> valid_lft forever preferred_lft forever
>
> It does this even if I pull the cable from the wired connection. The
> wifi never comes up.
>
> Here's the /etc/network/interfaces file:
>
> auto lo
> iface lo inet loopback
>
> auto enp10s0
> iface enp10s0 inet manual
>  bond-master bond0
>  bond-mode 1
>
> auto wlxc4411e319ad5
> iface wlxc4411e319ad5 inet manual
>  bond-master bond0
>  bond-mode 1
>
> auto bond0
> iface bond0 inet static
>  address 192.168.1.20
>  netmask 255.255.255.0
>  network 192.168.1.0
>  gateway 192.168.1.1
>  bond-slaves enp10s0 wlxc4411e319ad5
>  bond-mode 1
>  bond-miimon 100
>  bond-downdelay 200
>  bond-updelay 200
>
>
> I'd like to get it to work in a faster mode but for now the backup at
> least allows the networking to start without the wifi. Other modes seem
> to disable networking until both interfaces come up, which is not a good
> design decision IMHO. At least with mode 1, the network starts.
>
> Any ideas on how to get the wifi to work in bonding?
>

Probably your wifi card does not support MII, check with:

~]# ethtool  wlxc4411e319ad5 | grep "Link detected:"

and:

~]# cat /proc/net/bonding/bind0


network bonding on Debian/Trixie

2023-10-16 Thread Gary Dale
I'm trying to configure network bonding on an AMD64 system running 
Debian/Trixie. I've got a wired connection and a wifi connection, both 
of which work individually. I'd like them to work together to improve 
the throughput but for now I'm just trying to get the bond to work. 
However when I configure them, the wifi interface always shows down.


# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
   valid_lft forever preferred_lft forever
2: enp10s0:  mtu 1500 qdisc mq 
master bond0 state UP group default qlen 1000

    link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
4: wlxc4411e319ad5:  mtu 1500 qdisc noop state DOWN 
group default qlen 1000

    link/ether c4:41:1e:31:9a:d5 brd ff:ff:ff:ff:ff:ff
7: bond0:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000

    link/ether 3c:7c:3f:ef:15:47 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.20/24 brd 192.168.1.255 scope global bond0
   valid_lft forever preferred_lft forever
    inet6 fe80::3e7c:3fff:feef:1547/64 scope link proto kernel_ll
   valid_lft forever preferred_lft forever

It does this even if I pull the cable from the wired connection. The 
wifi never comes up.


Here's the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto enp10s0
iface enp10s0 inet manual
    bond-master bond0
    bond-mode 1

auto wlxc4411e319ad5
iface wlxc4411e319ad5 inet manual
    bond-master bond0
    bond-mode 1

auto bond0
iface bond0 inet static
    address 192.168.1.20
    netmask 255.255.255.0
    network 192.168.1.0
    gateway 192.168.1.1
    bond-slaves enp10s0 wlxc4411e319ad5
    bond-mode 1
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200


I'd like to get it to work in a faster mode but for now the backup at 
least allows the networking to start without the wifi. Other modes seem 
to disable networking until both interfaces come up, which is not a good 
design decision IMHO. At least with mode 1, the network starts.


Any ideas on how to get the wifi to work in bonding?



Re: HP RP2430 RISC sysytem

2023-10-16 Thread yxcv

On Mon, 16 Oct 2023 12:54:35 -0400
 Stefan Monnier  wrote:

2GB RAM. IT IS NOT TOO MUCH  for firefox-Monster.or OS?



Could be, I don't know.
I know that 1GB is too little (still works, but painfully so), and 
that 3GB is currently sufficient for my use-cases.

The 2GB in my smartphone seem to be just enough for limited uses
of Fennec.
Well. 2GB for a sufficient screen is small except for a screen you seen to 
use.

As far as I can judge RAM never is too large.:)



Re: HP RP2430 RISC sysytem

2023-10-16 Thread Stefan Monnier
> 2GB RAM. IT IS NOT TOO MUCH  for firefox-Monster.or OS?

Could be, I don't know.
I know that 1GB is too little (still works, but painfully so), and that
3GB is currently sufficient for my use-cases.
The 2GB in my smartphone seem to be just enough for limited uses
of Fennec.


Stefan



Re: Strange Monitor Behavior

2023-10-16 Thread The Wanderer
On 2023-10-16 at 10:17, Thomas Schmitt wrote:

> Hi,
> 
> my ~ 10 year old Iiyama ProLite X2775HDS sometimes does strange
> things when i wake it by keyboard or mouse movement after X had cut
> off itsi signal because i was inactive for a few minutes.
> 
> Either it stays black although it reported to have in nput signal
> again, or it shows an interlaced and displaced image of what fvwm is
> supposed to display. A power cycle of screen reliably brings the
> correct display.

FWIW, that "interlaced and displaced image" sounds like it could be
describing the same "fuzzy"/"blurry" thing I was trying to describe.

> In more than 99 of 100 tries it just wakes up ok, though.

Same.

> It seems not to be related to the computers to which it has been 
> attached since i got it.

I only use the monitor with one single computer, thus far, so I can't
testify on that front.

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


Re: Strange Monitor Behavior

2023-10-16 Thread Thomas Schmitt
Hi,

my ~ 10 year old Iiyama ProLite X2775HDS sometimes does strange things
when i wake it by keyboard or mouse movement after X had cut off itsi
signal because i was inactive for a few minutes.

Either it stays black although it reported to have in nput signal again,
or it shows an interlaced and displaced image of what fvwm is supposed to
display. A power cycle of screen reliably brings the correct display.

In more than 99 of 100 tries it just wakes up ok, though.
It seems not to be related to the computers to which it has been
attached since i got it.


Have a nice day :)

Thomas



Re: Strange Monitor Behavior

2023-10-16 Thread Dan Ritter
Stephen P. Molnar wrote: 
> I am running up top date Bookworm on my AMD Linux platform with a LG Monitor
> and have developed a rather strange problem.
> 
> When the system wakes up from sleep mode it has a bright pink screen. This
> seems to be a random occurrence. Turning the Monitor off and then back on
> returns the normal screen.


I have had this happen with a bad or partially-connected video cable.

-dsr-



Re: Strange Monitor Behavior

2023-10-16 Thread The Wanderer
On 2023-10-16 at 09:22, Stephen P. Molnar wrote:

> I am running up top date Bookworm on my AMD Linux platform with a LG
>  Monitor and have developed a rather strange problem.
> 
> When the system wakes up from sleep mode it has a bright pink screen.
>  This seems to be a random occurrence. Turning the Monitor off and
> then back on returns the normal screen.
> 
> The monitor card is a Visiontek  Radeon HD 5450.

That sounds peripherally similar to a behavior I've occasionally seen; I
haven't seen the pink screen, but I *have* seen the monitor wake up to a
state of producing a "fuzzy" or "blurry" display. As with what you
describe, the behavior persists until the monitor is power-cycled, and
clears after that (until the next time).

I've always interpreted that as being an issue with the monitor, not
with the GPU or with the controlling software. If that's correct, and
the issue you're seeing is of the same type, then the exact model of the
monitor you're seeing the pink screen with would probably be relevant.

(I don't remember offhand whether the behavior I'm describing was seen
with my current monitor or with a previous one, so I can't provide the
exact model for my own case either, although I can state that both
candidates are Dell units.)

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


Strange Monitor Behavior

2023-10-16 Thread Stephen P. Molnar
I am running up top date Bookworm on my AMD Linux platform with a LG 
Monitor and have developed a rather strange problem.


When the system wakes up from sleep mode it has a bright pink screen. 
This seems to be a random occurrence. Turning the Monitor off and then 
back on returns the normal screen.


The monitor card is a Visiontek  Radeon HD 5450.

Googling brings mixed returns as to the problem.

I would appreciate guidance in this matter.

Thanks in advance.

--
Stephen P. Molnar, Ph.D.
https://insilicochemistry.net
(614)312-7528 (c)
Skype:  smolnar1



Problem with postgresql-12-crons timezone

2023-10-16 Thread Elke Hofmann
Dear community

I write as I am not sure if the issue I report is caused by Debian.
On 23-10-10 we upgraded our Debian bullseye servers to version 11.8. Along came 
a new version of postgresql-12-cron:
postgresql-12-cron 1.6.0-1.pgdg110+1
pg_cron executes jobs one day too early since then.
I opened an issue here: https://github.com/citusdata/pg_cron/issues/290
We reproduced the problem with postgresql 13/ postgresql-13-cron.
We could fix the problem temporarily with setting cron.timezone to 'GMT+24' in 
/etc/postgresql//main/postgresql.conf
Thank you in advance for any advice
Best, Elke Hofmann



Fachhochschule Nordwestschweiz FHNW
Hochschule für Life Sciences

Prof. Elke Hofmann
Leiterin Applikationsentwicklung/Datenmanagement Ausbildung
Co-Verantwortliche Studierendenprojekte
Hofackerstrasse 30
4132 Muttenz

T +41 061 228 54 01
M +41 78 600 47 39 (SMS)

elke.hofm...@fhnw.ch
www.fhnw.ch/de/personen/elke-hofmann