Re: Hola!

[OddieX]

El dom., 22 de agosto de 2021 19:26, marco bernich 
escribió:

> Hola!
>
> saludo a la lista;)
>
> volviendo a Debian, despuès de un tiempo de usar arch...
>
> la cosa es que instalè la versiòn 11. He tenido varias dificultades (ha
> cambiado mucho el entorno GNOME!)  pero las he ido resolviendo... salvo, la
> suspensiòn que me cuelga la màquina...
>
> Si alguien me puede ayudar, muchas gracias!
>
> Saludos!
>


Fijate si te sirve ponerle al boot noapic, me pasaba en sistemas viejos
hace mil no me sucede, pero antes me pasaba y asi lo solucionaba.

>

Problemas con la suspensión (era: Hola!)

[Camaleón]

El 2021-08-22 a las 19:26 -0300, marco bernich escribió:

> la cosa es que instalè la versiòn 11. He tenido varias dificultades (ha
> cambiado mucho el entorno GNOME!)  pero las he ido resolviendo... salvo, la
> suspensiòn que me cuelga la màquina...
> 
> Si alguien me puede ayudar, muchas gracias!

Ármate de paciencia y revisa los registros por si encontraras alguna 
pista del error. Normalmente, los problemas con la suspensión suelen 
venir de alguna aplicación que tienes cargada y da guerra o algún 
controlador propietario. Intenta hacer las pruebas de suspensión con un 
entorno lo más limpio y básico posible para ir descartando posibles 
orígenes de conflitco (desactiva el salvapantallas, suspende sin 
tener niguna aplicación problemática abierta, intenta usar siempre 
controladores libres, sobre todo para la gráfica, desactiva el 
adaptador inalámbrico, etc...).

Aquí te paso algunas páginas con ayuda y pasos para depurar errores con 
la suspensión / hibernación:

Best practice to debug Linux* suspend/hibernate issues
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues

Debugging hibernation and suspend
https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html

Saludos,

-- 
Camaleón 

Re: smart fans

[Emanuel Berg]

> OK, I did check out the BIOS/UEFI/Setup and all five fans
> can be configured individually. There are five options.

I spoke to soon, there seems to be only one set of options for
the CPU fan, so I guess the CPU_OPT and CPU_FAN are the same
in terms of options.

Anyway now I've set all 5 to "Silent" but the temperature is
the same and to be honest I can't say it is any more silent
than before ... is it?

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

OK, I did check out the BIOS/UEFI/Setup and all five fans can
be configured individually. There are five options.

Control can be disabled, auto (the default), DC, or PWM.

Wind-up time is set to 0.

Minimum speed is 200 RPM.

Profiles were Standard (the default), Silent, Turbo,
and Manual.

I set the three case fans to Silent, let's see what
happens ...

(Maybe the "auto" control doesn't work, I can try put that
explicitely DC for the 3-pins and PWM for the 4-pins.)

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

> Temperatures of the CPU and GPU I have,
>
> #! /bin/zsh
> #
> # this file:
> #   http://user.it.uu.se/~embe8573/conf/.zsh/misc-hw
> #   https://dataswamp.org/~incal/conf/.zsh/misc-hw
>
> temperature () {
> local gpu=$(sensors -j | jq -a '.["nouveau-pci-0100"].temp1.temp1_input')
> local cpu=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
> echo "GPU ${gpu}C"
> echo "cpu ${cpu}C"
> }
> alias fans=temperature

Unparsed output of sensors(1):

$ sensors
nouveau-pci-0100
Adapter: PCI adapter
GPU core:912.00 mV (min =  +0.80 V, max =  +1.19 V)
temp1:+41.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +105.0°C, hyst =  +5.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tdie: +33.9°C  (high = +70.0°C)
Tctl: +33.9°C  

asus-isa-
Adapter: ISA adapter
cpu_fan:0 RPM

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

David Christensen wrote:

> I would figure out what Setup can do with the fans before
> messing with the Linux CPU governor. Install software to
> display temperatures, to display fan speeds, and to put the
> CPU under load.

Temperatures of the CPU and GPU I have,

#! /bin/zsh
#
# this file:
#   http://user.it.uu.se/~embe8573/conf/.zsh/misc-hw
#   https://dataswamp.org/~incal/conf/.zsh/misc-hw

temperature () {
local gpu=$(sensors -j | jq -a '.["nouveau-pci-0100"].temp1.temp1_input')
local cpu=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
echo "GPU ${gpu}C"
echo "cpu ${cpu}C"
}
alias fans=temperature

> Get a camera, a notepad, a stopwatch, and collect data as
> you work through configuring the fans in Setup.

I am not bothered by the fans when I use the computer.

When I don't use the computer and instead read, attempt to
sleep etc the fan sound is annoying enough, I have to
hibernate the computer, but then I loose the Internet
connection. Gnus, ERC and downloads scripts, e.g. this -
https://dataswamp.org/~incal/scripts/tokyo-dl - all resume
their connectivity automatically but after having that
happened 1000+ times it has started to annoy me.

So this is the use case, when I don't use the computer, I'd
like the fans to slow down as much as is safe to do. If this
can't happen dynamically as a function of the load or
temperature I'm happy to issue the commands manually, altho
that would be less safe (human factor, unpredicted events
etc) no doubt.

So if we start over ... forget about everything I said ... how
would go about this?

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

David Christensen wrote:

> Some of my other machines offer additional governors --
> "powersave" and "userspace". Run "cpufreq-info -g" to see
> what Debian offers on your motherboard.

I did install and did set it to different governors but the
fans seem to go on like the always do regardless?

CPU and GPU temperatures seemed to be the same as well...

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

didier gaumet wrote:

> I would think that pwmconfig complains that it finds 3-pins
> fans set up to PWM mode (4-pins required)
>
> Your UEFI propose either to setup your fans globally or
> individually and I think that by default the setup is
> global. This would probably be fine il all your fans were
> either 3-pins (DC mode) or 4-pins (preferably PWM mode but
> DC mode is possibility). But you have both installed.
> A solution could be, in your UEFI, to individually set up
> all your 4-pins fans to PWM mode, while setting up all your
> 3-pins fans to DC mode.

Yeah, or replace the 3-pins with 4-pins?

re: pwmconfig, here is what it says:

$ sudo pwmconfig
# pwmconfig version 3.6.0
This program will search your sensors for pulse width
modulation (pwm) controls, and test each one to see if it
controls a fan on your motherboard. Note that many
motherboards do not have pwm circuitry installed, even if your
sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm
controls. The program will attempt to restore each fan to full
speed after testing. However, it is ** very important ** that
you physically verify that the fans have been to full speed
after the program has completed.

Found the following devices:
   hwmon0 is k10temp
   hwmon1 is asus
   hwmon2 is nouveau

Found the following PWM controls:
   hwmon2/pwm1   current value: 52
hwmon2/pwm1 is currently setup for automatic speed control.
In general, automatic mode is preferred over manual mode, as
it is more efficient and it reacts faster. Are you sure that
you want to setup this output for manual control? (n) y

Giving the fans some time to reach full speed...
Found the following fan sensors:
   hwmon1/fan1_input current speed: 0 ... skipping!

There are no working fan sensors, all readings are 0.
Make sure you have a 3-wire fan connected.
You may also need to increase the fan divisors.
See doc/fan-divisors for more information.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

David Christensen wrote:

> I would disconnect the fan wire splitter, disconnect
> projector extra fan, and connect the Corsair fan directly to
> CHA_FAN1 [...]
>
> CHA_FAN1 - location? - Corsair, 120 mm 3-pin

This fan is at the rear end of the computer, high, air goes
out. This is 3-pin so should be replaced ...

> It is unwise to power external devices from a computer
> motherboard.

... but in the meantime I can connect it directly to
CHA_FAN1, sure.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[David Christensen]

On 8/22/21 5:51 PM, Emanuel Berg wrote:

OK, I did check out the BIOS/UEFI/Setup and all five fans
can be configured individually. There are five options.


I spoke to soon, there seems to be only one set of options for
the CPU fan, so I guess the CPU_OPT and CPU_FAN are the same
in terms of options.

Anyway now I've set all 5 to "Silent" but the temperature is
the same and to be honest I can't say it is any more silent
than before ... is it?



You need to collect data.

- The computer should be able to tell you temperatures and fan speeds, 
either via the OS or via Setup.


- If you have a microphone, you can use various Linux apps to make sound 
measurements.


- If you have a smart phone, you can install various apps to make sound 
measurements.



Changing settings and making measurements at idle is a starting point. 
You should also put the machine under load and make measurements.



David

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 8:51 p.m., Emanuel Berg wrote:
>> OK, I did check out the BIOS/UEFI/Setup and all five fans
>> can be configured individually. There are five options.
> 
> I spoke to soon, there seems to be only one set of options for
> the CPU fan, so I guess the CPU_OPT and CPU_FAN are the same
> in terms of options.
> 
> Anyway now I've set all 5 to "Silent" but the temperature is
> the same and to be honest I can't say it is any more silent
> than before ... is it?
> 

Silent means it will use the lowest speed possible without rising
temperature.
In "normal" situation, the speed is kept so it will achieve a good
balance between temperature and the speed of the fan.

If your computer is not installed in a very warm place and you are not
doing some intensive work then it's possible that even running at a low
speed the fans still do all the job needed.

If you take the option for let say "performance" then it will be at max
speed so the system is the coolest possible all the time.

Not sure if I said it right...

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Emanuel Berg]

David Christensen wrote:

> The motherboard user's manual says all of the fan connectors
> are 4-pin.

Indeed, I looked at one of the fan's wires instead of the
connector :$

> Changing the supply voltage of a old-school 2-wire fan will
> change the speed. These typically have 4-pin power supply
> Molex connectors and/or 2-pin 0.1" general electronics
> connectors. I connect these to Molex connectors or manual
> speed controllers, paying attention to alignment/polarity.
>
> Changing the supply voltage of a 3-pin fan, where the 3rd
> wire is tachometer feedback, will change the speed.
> I connect these to motherboard 3-pin and 4-pin fan
> connectors, paying attention to the alignment tab.
>
> Changing the supply voltage of a 4-pin fan, where the 3rd
> wire is tachometer feedback and the 4th wire is PWM speed
> control, may change the fan speed, may cause the electronics
> onboard the fan assembly to malfunction or fail, and/or may
> cause the electronics feeding the fan to malfunction or
> fail. I connect these to motherboard 4-pin fan connectors,
> paying attention to the alignment tab.
>
> Be careful when making connections. I once mis-aligned
> a 2.5" IDE HDD 40-pin power/signal adapter cable to a 2.5"
> IDE HDD and was off by one row. When I energized the power
> supply, the result was a short-circuit, smoked insulation,
> and permanently damaged hardware!

:)

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[David Christensen]

On 8/22/21 4:57 PM, Emanuel Berg wrote:

David Christensen wrote:


I would figure out what Setup can do with the fans before
messing with the Linux CPU governor. Install software to
display temperatures, to display fan speeds, and to put the
CPU under load.


Temperatures of the CPU and GPU I have,

#! /bin/zsh
#
# this file:
#   http://user.it.uu.se/~embe8573/conf/.zsh/misc-hw
#   https://dataswamp.org/~incal/conf/.zsh/misc-hw

temperature () {
 local gpu=$(sensors -j | jq -a '.["nouveau-pci-0100"].temp1.temp1_input')
 local cpu=$(sensors -j | jq -a '.["k10temp-pci-00c3"].Tdie.temp1_input')
 echo "GPU ${gpu}C"
 echo "cpu ${cpu}C"
}
alias fans=temperature


Get a camera, a notepad, a stopwatch, and collect data as
you work through configuring the fans in Setup.


I am not bothered by the fans when I use the computer.

When I don't use the computer and instead read, attempt to
sleep etc the fan sound is annoying enough, I have to
hibernate the computer, but then I loose the Internet
connection. Gnus, ERC and downloads scripts, e.g. this -
https://dataswamp.org/~incal/scripts/tokyo-dl - all resume
their connectivity automatically but after having that
happened 1000+ times it has started to annoy me.

So this is the use case, when I don't use the computer, I'd
like the fans to slow down as much as is safe to do. If this
can't happen dynamically as a function of the load or
temperature I'm happy to issue the commands manually, altho
that would be less safe (human factor, unpredicted events
etc) no doubt.

So if we start over ... forget about everything I said ... how
would go about this?



Here are various ideas:

- Set the Linux CPU governor to "powersave".

- Use the motherboard Setup utility to under-clock the CPU and/or switch 
off cores.


- Do the same for the GPU, if you can.

- Tune the CPU and chassis fans using Setup.  Try the "EZ Tuning 
Wizards".  Try the QFan "Silent" profile.  Try making a manual profile 
once you understand the options and effects.


- What about GPU fan(s)?  Power supply fan(s)?  Any other fans?

- What about HDD's?  If they are not vibration isolated, the chassis can 
act as a sounding board.


- Any other noise sources in or on the computer?

- Dress cables inside the chassis to improve airflow.

- Install sound and vibration absorbing materials inside the chassis 
--cork, rubber, foam, etc..  Various manufacturers sell materials and kits.


- Buy a "silent" chassis with doors/ covers over all openings, sound and 
vibration absorbing materials on interior surfaces, vibration-isolated 
drive cages, etc..


- Install sound absorbing materials on the surfaces around the chassis 
-- floor, wall, furniture, ceiling, etc..  Place free-standing sound 
absorbing baffles around and/or over the chassis.  Put the chassis 
inside a cabinet lined with sound-absorbing materials and a ventilation 
fan.  Carpet scraps can be an inexpensive sound-absorbing material.


- Move whatever service(s) you need running 24x7 to a VPS.

- STFW for "silent PC" to get more ideas.


David

Re: smart fans

[Emanuel Berg]

David Christensen wrote:

> Some of my other machines offer additional governors --
> "powersave" and "userspace". Run "cpufreq-info -g" to see
> what Debian offers on your motherboard.

$ cpufreq-info -g
conservative userspace powersave ondemand performance schedutil

> The user's manual:
>
> https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/ROG_STRIX_B450_F_GAMING/E14401_ROG_STRIX_B450-F_GAMING_UM_WEB.pdf

Ah, excellent, couldn't find that on the page that was linked
previously in this thread...

>> Fans are:
>> fanfront low   be quiet! Shadow Wings 2  140 mm
>>front high  be quiet! Shadow Wings 2  140 mm
>>CPU cooling tower   be quiet! Pure Wings 2120 mm  (2)
>>rearCorsair   120 mm
>>projector extra fractal Silent Series R3  140 mm
>
> What is "projector extra"?

fanfront low  be quiet! Shadow Wings 2  140 mm 3-pin[1]
   front high be quiet! Shadow Wings 2  140 mm 4-pin
   CPU cooling tower  be quiet! Pure Wings 2120 mm 4-pin (2)[2]
   rear   Corsair   120 mm 3-pin
   projector extrafractal Silent Series R3  140 mm 3-pin[3]

   The motherboard fan connectors are:
 CPU_FAN  - CPU cooling tower;
 CPU_OPT  - CPU colling tower;
 CHA_FAN1 - fan wire splitter - 3 wires - rear,
  - 2 wires - projector extra;
 CHA_FAN2 - front high;
 CHA_FAN3 - front low.
   All connectors are 4-pin. "Projector extra" is a fan
   located outside the computer.

   [1] https://www.bequiet.com/en/casefans/shadow-wings-2/1620
   "available with or without PWM control"
   [2] https://www.bequiet.com/en/casefans/449
   "Fan speed @ 100% PWM / 12V: 1500 RPM"
   [3] 
https://www.fractal-design.com/products/fans/silent/silent-series-r3-140mm/black/
   (Doesn't mention PWM.)

https://dataswamp.org/~incal/ebchw/COMPUTER

--
underground experts united
https://dataswamp.org/~incal

Re: serveur Debian testing avec deux ethernet (et routage)

[Étienne Mollier]

Bonsoir Basile,

Basile Starynkevitch, on 2021-08-22:
> Comment configurer le routage?
> 
> J'ai l'impression que la commande route est obsolète

Je pense que `route`, pour configurer le routage de la machine,
a été intégrée à la commande `ip` :

$ ip route
default via 192.168.1.254 dev enp4s0 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.100 

La documentation est disponible dans la page de manuel de
ip-route(8) [1].

[1]: https://manpages.debian.org/bullseye/iproute2/ip-route.8.en.html

Bonne soirée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: smart fans

[Emanuel Berg]

It took an even closer look at the motherboard and discovered
_all_ connectors are 4-pin. Inside the computer, 3/5 fans are
4-pin and the two on the CPU cooling tower (which are 4-pin,
so it checks out) even have "PWM" in their sticker text.

If the BIOS/UEFI setting is already PWM, and the connectors
are 4-pin, and some of the fans are, what's missing?

And this makes it is even more difficult to understand why
pwmconfig(8) asks for 3-pin fans. Because I have them -
as well!

fanfront low   be quiet! Shadow Wings 2  140 mm, 3-pin[1]
   front high  be quiet! Shadow Wings 2  140 mm, 4-pin
   CPU cooling tower   be quiet! Pure Wings 2120 mm, 4-pin (2)[2]
   rearCorsair   120 mm, 3-pin
   projector extra fractal Silent Series R3  140 mm, 3-pin[3]
   (motherboard fan connectors are:
CPU_FAN, CPU_OPT, SHA_FAN1, SHA_FAN2, SHA_FAN3 - all 4-pin)

   [1] https://www.bequiet.com/en/casefans/shadow-wings-2/1620
   "available with or without PWM control"
   [2] https://www.bequiet.com/en/casefans/449
   "Fan speed @ 100% PWM / 12V: 1500 RPM"
   [3] 
https://www.fractal-design.com/products/fans/silent/silent-series-r3-140mm/black/
   (Doesn't mention PWM.)

https://dataswamp.org/~incal/ebchw/COMPUTER

-- 
underground experts united
https://dataswamp.org/~incal

Re: Relatively boring bullseye upgrade reports

[Dan Ritter]

punk: ASrock 4x4 miniPC, AMD V1605b CPU (Zen, integrated Vega GPU)
16GB RAM, SATA SSD.

To be used as a desktop.

EFI booting, GPT partitions, ext4fs, XFCE4 desktop, totally
smooth.

If you don't have heavy GPU needs, this is a great little box.
Multiple USB3 and USB2 ports, 2 gigabit NICs, HDMI and
DisplayPort, takes either an M.2 NVMe SSD or a SATA SSD but not
both -- there's room but apparently they share the same PCIe
lanes. It was about $300 new without RAM or storage. About 4.5"
square and 2.7" high, or if you prefer, less than 12 cm square
and less than 7 cm high. Comes with a panel to click it onto 
the back of a VESA-mount on a monitor.

There are more expensive versions with Ryzen 4300U and 4500U if
you like the tiny size but somehow need more computing power. I
think that if I wanted more CPU, I would want more future
expandability, too.

-dsr-

Re: mouse pointer in changes unwanted

[Charles Curley]

On Sun, 22 Aug 2021 23:45:07 +0200
"sp...@caiway.net"  wrote:

> I use sddm as display manager, when this is started I get my chosen
> big green cursor but when I log in it changes to a small red
> mouse pointer
> 
> When I start blackbox, the green one also changes to the red

You didn't say what desktop environment you are using, e.g. XFCE,
Gnome, Cinnamon.

In XFCE, I have found it necessary to change the cursor in XFCE's
settings as well. settings-> mouse and touchpad-> theme

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 5:47 p.m., David Christensen wrote:
> On 8/22/21 2:26 PM, Emanuel Berg wrote:
>> didier gaumet wrote:
>>
>>> I would think that pwmconfig complains that it finds 3-pins
>>> fans set up to PWM mode (4-pins required)
>>>
>>> Your UEFI propose either to setup your fans globally or
>>> individually and I think that by default the setup is
>>> global. This would probably be fine il all your fans were
>>> either 3-pins (DC mode) or 4-pins (preferably PWM mode but
>>> DC mode is possibility). But you have both installed.
>>> A solution could be, in your UEFI, to individually set up
>>> all your 4-pins fans to PWM mode, while setting up all your
>>> 3-pins fans to DC mode.
>>
>> Yeah, or replace the 3-pins with 4-pins?
> 
> 
> I believe your motherboard can support both 3-pin and 4-pin fans using
> hardware/ firmware/ Setup.
> 
> 
>> re: pwmconfig, here is what it says:
>>
>> $ sudo pwmconfig
>> # pwmconfig version 3.6.0
>> This program will search your sensors for pulse width
>> modulation (pwm) controls, and test each one to see if it
>> controls a fan on your motherboard. Note that many
>> motherboards do not have pwm circuitry installed, even if your
>> sensor chip supports pwm.
>>
>> We will attempt to briefly stop each fan using the pwm
>> controls. The program will attempt to restore each fan to full
>> speed after testing. However, it is ** very important ** that
>> you physically verify that the fans have been to full speed
>> after the program has completed.
>>
>> Found the following devices:
>>     hwmon0 is k10temp
>>     hwmon1 is asus
>>     hwmon2 is nouveau
>>
>> Found the following PWM controls:
>>     hwmon2/pwm1   current value: 52
>> hwmon2/pwm1 is currently setup for automatic speed control.
>> In general, automatic mode is preferred over manual mode, as
>> it is more efficient and it reacts faster. Are you sure that
>> you want to setup this output for manual control? (n) y
>>
>> Giving the fans some time to reach full speed...
>> Found the following fan sensors:
>>     hwmon1/fan1_input current speed: 0 ... skipping!
>>
>> There are no working fan sensors, all readings are 0.
>> Make sure you have a 3-wire fan connected.
>> You may also need to increase the fan divisors.
>> See doc/fan-divisors for more information.
> 
> 
> I consider motherboard hardware/ firmware control of fans to be more
> reliable than operating system control of fans.  Using a Linux tool to
> control the fans involves several layers of complexity and, given
> closed-source motherboard hardware and firmware, the only route is
> reverse engineering; which is error-prone at best.  And, you paid for a
> motherboard that has advanced fan control features.  I would advise
> using the motherboard hardware/ firmware/ Setup utility to control your
> fans.
> 
Somewhat what I advocated since the beginning.

Seems to be much work with risks involved when there's already a working
infrastructure that does the job.

Overkill
> 
> Can you control the speed of any of the fans using Setup?
> 
> 
> David
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Hola!

[marco bernich]

Hola!

saludo a la lista;)

volviendo a Debian, despuès de un tiempo de usar arch...

la cosa es que instalè la versiòn 11. He tenido varias dificultades (ha
cambiado mucho el entorno GNOME!)  pero las he ido resolviendo... salvo, la
suspensiòn que me cuelga la màquina...

Si alguien me puede ayudar, muchas gracias!

Saludos!

Re: smart fans

[Gene Heskett]

On Sunday 22 August 2021 17:04:06 Gene Heskett wrote:

> On Sunday 22 August 2021 12:46:14 Polyna-Maude Racicot-Summerside 
wrote:
> > On 2021-08-22 10:02 a.m., Emanuel Berg wrote:
> > > tomas wrote:
> > >> I disagree. The thing poses [1] as a DC motor (2 pins power,
> > >> one tacho). I don't think you get too much control over RPM
> > >
> > > That's what you get with the 4th wire/pin? A sensor to
> > > read RPM?
> >
> > Opposite
> > 3 wire = 2 wire to drive motor + 1 wire to get speed
> > 4 wire = 2 wire to drive, 1 to get speed, 1 to modify speed
>
> I as a CET, am totally unimpressed with the miss-information being
> thrown about in this thread. A total lack of how its actually done in
> real hardware.
>
> 1. Any si diode, passing a few microamps of fwd current, is in fact an
> excellent, does not need to be calibrated, thermometer capable of 1
> degree C accuracy.  There are several million candidates buried in
> todays cpu's.
>
> 2, even a 2 wire fan can be controlled by using this voltage to
> determine the on time of a small transistor. Often down to 1% speed at
> room tmps, so other than the cost of the time at die bondout time, its
> free. The 1% minimum is actually used to help distribute the motors
> lubricant.
>
> 3, boiled down, the temp measured by this diode can be scaled to
> control the fan to maintain the device being monitored at a fixed
> maximum temp, and its done on 2 or 3 of the gates on the cpu die
> intended to be used to replace a bad gate in you cpu. Intelligently
> done at test and bondout time, it might add 10 seconds to the time
> needed to verify the rest of the chip.
>
> > > "What you can't measure, you can't control"
>
> Better, if you can measure it, you can control a 2 wite motor.
>
And I knew I couldn't get by without a typu. s/b wire.
In fact, if a motor has 3 wires, there is a good chance its a tacho wire, 
used ONLY to tell /you/ how fast its running.

> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: smart fans

[David Christensen]

On 8/22/21 2:40 PM, Emanuel Berg wrote:

David Christensen wrote:


Some of my other machines offer additional governors --
"powersave" and "userspace". Run "cpufreq-info -g" to see
what Debian offers on your motherboard.


I did install and did set it to different governors but the
fans seem to go on like the always do regardless?

CPU and GPU temperatures seemed to be the same as well...



I would figure out what Setup can do with the fans before messing with 
the Linux CPU governor.  Install software to display temperatures, to 
display fan speeds, and to put the CPU under load.  Get a camera, a 
notepad, a stopwatch, and collect data as you work through configuring 
the fans in Setup.



David

Re: smart fans

[David Christensen]

On 8/22/21 2:26 PM, Emanuel Berg wrote:

didier gaumet wrote:


I would think that pwmconfig complains that it finds 3-pins
fans set up to PWM mode (4-pins required)

Your UEFI propose either to setup your fans globally or
individually and I think that by default the setup is
global. This would probably be fine il all your fans were
either 3-pins (DC mode) or 4-pins (preferably PWM mode but
DC mode is possibility). But you have both installed.
A solution could be, in your UEFI, to individually set up
all your 4-pins fans to PWM mode, while setting up all your
3-pins fans to DC mode.


Yeah, or replace the 3-pins with 4-pins?



I believe your motherboard can support both 3-pin and 4-pin fans using 
hardware/ firmware/ Setup.




re: pwmconfig, here is what it says:

$ sudo pwmconfig
# pwmconfig version 3.6.0
This program will search your sensors for pulse width
modulation (pwm) controls, and test each one to see if it
controls a fan on your motherboard. Note that many
motherboards do not have pwm circuitry installed, even if your
sensor chip supports pwm.

We will attempt to briefly stop each fan using the pwm
controls. The program will attempt to restore each fan to full
speed after testing. However, it is ** very important ** that
you physically verify that the fans have been to full speed
after the program has completed.

Found the following devices:
hwmon0 is k10temp
hwmon1 is asus
hwmon2 is nouveau

Found the following PWM controls:
hwmon2/pwm1   current value: 52
hwmon2/pwm1 is currently setup for automatic speed control.
In general, automatic mode is preferred over manual mode, as
it is more efficient and it reacts faster. Are you sure that
you want to setup this output for manual control? (n) y

Giving the fans some time to reach full speed...
Found the following fan sensors:
hwmon1/fan1_input current speed: 0 ... skipping!

There are no working fan sensors, all readings are 0.
Make sure you have a 3-wire fan connected.
You may also need to increase the fan divisors.
See doc/fan-divisors for more information.



I consider motherboard hardware/ firmware control of fans to be more 
reliable than operating system control of fans.  Using a Linux tool to 
control the fans involves several layers of complexity and, given 
closed-source motherboard hardware and firmware, the only route is 
reverse engineering; which is error-prone at best.  And, you paid for a 
motherboard that has advanced fan control features.  I would advise 
using the motherboard hardware/ firmware/ Setup utility to control your 
fans.



Can you control the speed of any of the fans using Setup?


David

mouse pointer in changes unwanted

[sp...@caiway.net]

My mouse cursor does not follow 
update-alternatives --config x-cursor-theme


I use sddm as display manager, when this is started I get my chosen big
green cursor but when I log in it changes to a small red
mouse pointer

When I start blackbox, the green one also changes to the red

adduser test
login as test 
the cursor stays green

When I logout and get back to sddm's login screen the cursor is again
the right, big green one


So is has to be some startup thing in my home directory

I checked the .X files, could find anything

I don't where els to look

Thanks!


update-alternatives --config x-cursor-theme

* 67 /usr/share/icons/Chameleon-Mint-Large/cursor.theme 49
  manual mode


cat /etc/X11/cursors/Chameleon-Mint-Large.theme
-> /usr/share/icons/Chameleon-Mint-Large/cursor.theme

[Icon Theme]
Name=Chameleon-DarkSkyBlue Large 0.5
Comment=Cursor Theme by Giuseppe Benigno 
Inherits=Chameleon-Mint-Large
Example=left_ptr

Re: serveur Debian testing avec deux ethernet (et routage)

[Julio Herrero]

El dom, 22-08-2021 a las 22:07 +0200, Basile Starynkevitch escribió:
> Comment configurer le routage?

/etc/sysctl.conf

...
net.ipv4.ip_forward=1
...

Re: smart fans

[didier gaumet]

Le dimanche 22 août 2021 à 21:59 +0200, Emanuel Berg a écrit :
> It took an even closer look at the motherboard and discovered
> _all_ connectors are 4-pin. Inside the computer, 3/5 fans are
> 4-pin and the two on the CPU cooling tower (which are 4-pin,
> so it checks out) even have "PWM" in their sticker text.
> 
> If the BIOS/UEFI setting is already PWM, and the connectors
> are 4-pin, and some of the fans are, what's missing?
> 
> And this makes it is even more difficult to understand why
> pwmconfig(8) asks for 3-pin fans. Because I have them -
> as well!
> 
> fan    front low   be quiet! Shadow Wings 2  140 mm, 3-
> pin    [1]
>    front high  be quiet! Shadow Wings 2  140 mm, 4-pin
>    CPU cooling tower   be quiet! Pure Wings 2    120 mm, 4-pin
> (2)    [2]
>    rear    Corsair   120 mm, 3-pin
>    projector extra fractal Silent Series R3  140 mm, 3-
> pin    [3]
>    (motherboard fan connectors are:
>     CPU_FAN, CPU_OPT, SHA_FAN1, SHA_FAN2, SHA_FAN3 - all 4-pin)
[...]

I would think that pwmconfig complains that it finds 3-pins fans set up
to PWM mode (4-pins required)

Your UEFI propose either to setup your fans globally or individually
and I think that by default the setup is global. This would probably be
fine il all your fans were either 3-pins (DC mode) or 4-pins
(preferably PWM mode but DC mode is possibility). But you have both
installed. A solution could be, in your UEFI, to individually set up
all your 4-pins fans to PWM mode, while setting up all your 3-pins fans
to DC mode.

Re: smart fans

[Gene Heskett]

On Sunday 22 August 2021 12:46:14 Polyna-Maude Racicot-Summerside wrote:

> On 2021-08-22 10:02 a.m., Emanuel Berg wrote:
> > tomas wrote:
> >> I disagree. The thing poses [1] as a DC motor (2 pins power,
> >> one tacho). I don't think you get too much control over RPM
> >
> > That's what you get with the 4th wire/pin? A sensor to
> > read RPM?
>
> Opposite
> 3 wire = 2 wire to drive motor + 1 wire to get speed
> 4 wire = 2 wire to drive, 1 to get speed, 1 to modify speed
>
I as a CET, am totally unimpressed with the miss-information being thrown 
about in this thread. A total lack of how its actually done in real 
hardware.

1. Any si diode, passing a few microamps of fwd current, is in fact an 
excellent, does not need to be calibrated, thermometer capable of 1 
degree C accuracy.  There are several million candidates buried in 
todays cpu's.

2, even a 2 wire fan can be controlled by using this voltage to determine 
the on time of a small transistor. Often down to 1% speed at room tmps, 
so other than the cost of the time at die bondout time, its free. The 1% 
minimum is actually used to help distribute the motors lubricant.

3, boiled down, the temp measured by this diode can be scaled to control 
the fan to maintain the device being monitored at a fixed maximum temp, 
and its done on 2 or 3 of the gates on the cpu die intended to be used 
to replace a bad gate in you cpu. Intelligently done at test and bondout 
time, it might add 10 seconds to the time needed to verify the rest of 
the chip. 

> > "What you can't measure, you can't control"

Better, if you can measure it, you can control a 2 wite motor.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: smart fans

[David Christensen]

On 8/22/21 1:15 PM, Emanuel Berg wrote:


fanfront low  be quiet! Shadow Wings 2  140 mm 3-pin[1]
front high be quiet! Shadow Wings 2  140 mm 4-pin
CPU cooling tower  be quiet! Pure Wings 2120 mm 4-pin (2)[2]
rear   Corsair   120 mm 3-pin
projector extrafractal Silent Series R3  140 mm 3-pin[3]

The motherboard fan connectors are:
  CPU_FAN  - CPU cooling tower;
  CPU_OPT  - CPU colling tower;
  CHA_FAN1 - fan wire splitter - 3 wires - rear,
   - 2 wires - projector extra;
  CHA_FAN2 - front high;
  CHA_FAN3 - front low.
All connectors are 4-pin. "Projector extra" is a fan
located outside the computer.



I would disconnect the fan wire splitter, disconnect projector extra 
fan, and connect the Corsair fan directly to CHA_FAN1:


CPU_FAN- CPU cooling tower - be quiet! Pure Wings 2, 120 mm, 4-pin

CPU_OPT - CPU cooling tower - be quiet! Pure Wings 2, 120 mm, 4-pin

CHA_FAN1 - location? - Corsair, 120 mm 3-pin

CHA_FAN2 - front high - be quiet! Shadow Wings 2, 140 mm, 4-pin

CHA_FAN3 - front low - be quiet! Shadow Wings 2, 140 mm, 3-pin


It is unwise to power external devices from a computer motherboard.  I 
would get a 12 VDC power adapter with suitable ampere rating for the 
projector extra fan.



David

Re: smart fans

[David Christensen]

On 8/22/21 6:41 AM, to...@tuxteam.de wrote:

On Sun, Aug 22, 2021 at 09:03:51AM -0400, Polyna-Maude Racicot-Summerside wrote:

[...]


Like I already wrote, modifying voltage doesn't change speed of a motor
(fan).


I disagree. The thing poses [1] as a DC motor (2 pins power, one tacho).



[1] I'm nearly certain it's a BLDC in disguise, with some electronic goo.



What is "BLDC"?


On 8/22/21 7:25 AM, Thomas Schmitt wrote:
> A quick search with "fan voltage control" yields
> 
https://en.wikipedia.org/wiki/Computer_fan_control#Linear_voltage_regulation



Thank you -- that has the EE information I have been wanting.


David

Re: smart fans

[David Christensen]

On 8/22/21 1:39 AM, Emanuel Berg wrote:

4-pin fans wouldn't be possible because of the motherboard
sockets, I think, which are also 3-pin.



The motherboard user's manual says all of the fan connectors are 4-pin.


On 8/22/21 6:03 AM, Polyna-Maude Racicot-Summerside wrote:
> Like I already wrote, modifying voltage doesn't change speed of a motor
> (fan).


STFW here are some useful wiring diagrams for x86 ATX PC computer power 
supplies and fans:


https://www.smpspowersupply.com/connectors-pinouts.html

https://landing.coolermaster.com/faq/3-pin-and-4-pin-fan-wire-diagrams/


Changing the supply voltage of a old-school 2-wire fan will change the 
speed.  These typically have 4-pin power supply Molex connectors and/or 
2-pin 0.1" general electronics connectors.   I connect these to Molex 
connectors or manual speed controllers, paying attention to alignment/ 
polarity.



Changing the supply voltage of a 3-pin fan, where the 3rd wire is 
tachometer feedback, will change the speed.  I connect these to 
motherboard 3-pin and 4-pin fan connectors, paying attention to the 
alignment tab.



Changing the supply voltage of a 4-pin fan, where the 3rd wire is 
tachometer feedback and the 4th wire is PWM speed control, may change 
the fan speed, may cause the electronics onboard the fan assembly to 
malfunction or fail, and/or may cause the electronics feeding the fan to 
malfunction or fail.  I connect these to motherboard 4-pin fan 
connectors, paying attention to the alignment tab.



Be careful when making connections.  I once mis-aligned a 2.5" IDE HDD 
40-pin power/signal adapter cable to a 2.5" IDE HDD and was off by one 
row.  When I energized the power supply, the result was a short-circuit, 
smoked insulation, and permanently damaged hardware!



David

Re: serveur Debian testing avec deux ethernet (et routage)

[Jérémy Prego]

bonjour,

Le 22/08/2021 à 22:07, Basile Starynkevitch a écrit :



Comment configurer le routage?



routage de quoi vers quoi  ? à quoi doit avoir accès l'imprimante / 
l'ordinateur sur le réseau 1.y ?



J'ai l'impression que la commande route est obsolète


utiliser plutôt ip route du paquet iproute2

Librement.


Jerem

Re: serveur Debian testing avec deux ethernet (et routage)

[Basile Starynkevitch]

On 22/08/2021 22:12, Jérémy Prego wrote:

bonjour,

Le 22/08/2021 à 22:07, Basile Starynkevitch a écrit :



Comment configurer le routage?



routage de quoi vers quoi  ? à quoi doit avoir accès l'imprimante / 
l'ordinateur sur le réseau 1.y ?



aux machines du réseau 2.x (mais pas à Internet, vu qu'il y a un autre 
modem fibre sur 1.y, en pratique utilisé par une seulemachine)







J'ai l'impression que la commande route est obsolète


utiliser plutôt ip route du paquet iproute2

Librement.


Jerem


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

serveur Debian testing avec deux ethernet (et routage)

[Basile Starynkevitch]

Bonjour la liste

A la maison (de geek) j'ai plusieurs ordinateurs -tous sous Linux, mais 
pas forcément Debian-  et surtout de l'Ethernet (le wifi sert 
occasionnellement, surtout pour les tablettes).


J'ai un serveur (de récupération, c'était un déchet d'une boite 
d'avocats) sous Debian testing avec deux interfaces réseaux:


Voici la sortie de ifconfig pour les deux interfaces réseaux:

eno1: flags=4163  mtu 1500
    inet 192.168.2.2  netmask 255.255.255.0  broadcast 192.168.2.255
    inet6 2a01:e0a:3d0:7b50:9e8e:99ff:fe64:fcc2  prefixlen 64  
scopeid 0x0

    inet6 fe80::9e8e:99ff:fe64:fcc2  prefixlen 64  scopeid 0x20
    ether 9c:8e:99:64:fc:c2  txqueuelen 1000  (Ethernet)
    RX packets 3892  bytes 378141 (369.2 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 192  bytes 19267 (18.8 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 16

eno2: flags=4163  mtu 1500
    inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
    inet6 fe80::9e8e:99ff:fe64:fcc3  prefixlen 64  scopeid 0x20
    ether 9c:8e:99:64:fc:c3  txqueuelen 1000  (Ethernet)
    RX packets 113  bytes 13209 (12.8 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 107  bytes 10837 (10.5 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    device interrupt 17

Où 192.168.2.x contient le modem Fibre-optique Free, et 192.168.1.y est 
un réseau local (avec l'imprimante dessus), et un PC interne (en 
ethernet) dans le cabinet de mon épouse (psychologue)



Comment configurer le routage?

J'ai l'impression que la commande route est obsolète

Librement.

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

Re: smart fans

[Emanuel Berg]

OK, I was wrong, I just checked the motherboard with
a flashlight and there are fan connectors with 4 pins! I also
checked my sock drawer and - holy socks! - I found a computer
fan from AMD, it comes with a cooling tower as well so I think
it's for the CPU, anyway it has a 4-wire! So I'll just connect
it (someplace else) and see what happens. No wonder the
BIOS/UEFI had PWM and not DC the default. Let's see what
pwmconfig says now... 1s

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[David Christensen]

On 8/22/21 12:56 AM, Emanuel Berg wrote:

David Christensen wrote:


If you throttle your CPU, it will not generate as much heat:

 https://wiki.debian.org/CpuFrequencyScaling


You mean permanently or when I'm not using the computer?



Install the Debian package 'cpufrequtils'.


Use cpufreq-info(1) to get information about CPU frequency settings, 
including the governor.  Use cpufreq-set(1) to make changes.



For example, here is my daily driver laptop.  Debian offers two governor 
settings, "powersave" and "performance".  It booted up with the 
"powersave" governor.  If I were playing games, crunching numbers, etc., 
I could change the governor to "performance":


2021-08-22 11:40:22 root@dipsy ~
# cpufreq-info -g
performance powersave

2021-08-22 11:42:37 root@dipsy ~
# cpufreq-info -p
80 330 powersave

2021-08-22 11:42:44 root@dipsy ~
# cpufreq-info -f
825551

2021-08-22 11:44:50 root@dipsy ~
# cpufreq-set -g performance

2021-08-22 11:46:14 root@dipsy ~
# cpufreq-info -p
80 330 performance

2021-08-22 11:46:23 root@dipsy ~
# cpufreq-info -f
2539034


When I'm done, I can change the governor to "powersave":

2021-08-22 11:46:59 root@dipsy ~
# cpufreq-set -g powersave


Some of my other machines offer additional governors -- "powersave" and 
"userspace".  Run "cpufreq-info -g" to see what Debian offers on your 
motherboard.




Some motherboards have temperature sensors


The GPU seems to be always 41C while the CPU shows a cycle of
some 34-47C.


fan connectors (e.g. 4-pin)


Fan connectors are 3-pin!



The motherboard is Asus ROG Strix B450-F Gaming.



The user's manual:

https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/ROG_STRIX_B450_F_GAMING/E14401_ROG_STRIX_B450-F_GAMING_UM_WEB.pdf


The table "specifications summary", "Internal I/O Ports" on page xii says:

1 x 4-Pin CPU fan connector
1 x 4-Pin CPU_OPT fan connector
1 x 4-Pin AIO_PUMP connector
3 x 4-Pin Chassis fan connectors


See section 3.2.3 "QFan Control" for how to use the Setup utility to 
control fan speeds.




Fans are:

fanfront low   be quiet! Shadow Wings 2  140 mm
front high  be quiet! Shadow Wings 2  140 mm
CPU cooling tower   be quiet! Pure Wings 2120 mm  (2)
rearCorsair   120 mm
projector extra fractal Silent Series R3  140 mm



What is "projector extra"?


The "be quiet!" fans appear to be made in 3-pin and 4-pin versions.  We 
need a model number to check the Corsair fan.  The "fractal Silent 
Series R3" appears to have 3 pins:


https://www.bequiet.com/en/casefans/1625

https://www.bequiet.com/en/casefans/pure-wings-2/783

https://www.fractal-design.com/wp-content/uploads/2019/06/Silent-Series-R3-Fans-Product-Sheet-0.23-MB.pdf


You will want to identify which fan is connected to which motherboard 
connector.  See user's manual section 1.1.2 "Motherboard layout". 
Document connections using the motherboard connector names.



The Setup QFan Control should be able to control the speed of either 
3-pin or 4-pin fans.  I would try "DC Mode" for 3-pin fans and "PWM 
Mode" for 4-pin fans.




firmware settings


Where are these? The BIOS/UEFI?



See section 3.2 "BIOS setup program" of the user's manual.


David

Re: zoom client for bullseye

[Brian]

On Sun 22 Aug 2021 at 14:51:17 -0400, Jim Popovitch wrote:

> On Sun, 2021-08-22 at 14:47 -0400, Greg Wooledge wrote:
> > On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> > > On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > > > The zoom client downloaded from the zoom web page seems to have been 
> > > > written for Debian 8
> > > > 
> > > > Installing it in bullseye fails, dependency problems
> > > > 
> > > 
> > > Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> > > you need to run "apt-get -f install" to fix the dependencies.
> > 
> > If that's true, then you could simply use "apt install ./zoom*.deb" in
> > the first place.  It's undocumented, but it has been a thing for several
> > years now.
> 
> ntk, Thanks!

I wouldn't dream of disputing Greg Wooledge's advice. 'dpkg -i...' is
not a bad way to go but should *always* be folled by 'apt -f install'.
It leads to the same outcome.

-- 
Brian.

Re: zoom client for bullseye

[Brian]

On Sun 22 Aug 2021 at 14:27:12 -0400, Greg Wooledge wrote:

> On Sun, Aug 22, 2021 at 02:17:15PM -0400, Thomas George wrote:
> > The zoom client downloaded from the zoom web page seems to have been written
> > for Debian 8
> > 
> > Installing it in bullseye fails, dependency problems
> 
> There's not much we can do about that.  If you really want the standalone
> application, contact Zoom.

That's an avenue of support. Here isn't. We haven't any control over
the Zoom package.

> I'd suggest simply running the in-browser version whenever you
> need to attend a Zoom meeting.  It should work in either Firefox or
> Chrome/Chromium.

I've never done that. The flatpack version worked for me.

-- 
Brian.

Re: zoom client for bullseye

[Jim Popovitch]

On Sun, 2021-08-22 at 14:47 -0400, Greg Wooledge wrote:
> On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> > On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > > The zoom client downloaded from the zoom web page seems to have been 
> > > written for Debian 8
> > > 
> > > Installing it in bullseye fails, dependency problems
> > > 
> > 
> > Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> > you need to run "apt-get -f install" to fix the dependencies.
> 
> If that's true, then you could simply use "apt install ./zoom*.deb" in
> the first place.  It's undocumented, but it has been a thing for several
> years now.

ntk, Thanks!

-Jim P.

Re: smart fans

[Emanuel Berg]

rhkramer wrote:

> +1. A voltage controlled DC (computer fan) motor can be
> controlled / regulated down to about 40% of full rated speed
> (depending on the motor). A PWM (computer fan) motor can be
> controlled down to about 20% of full rated speed.

I found some web pages that describe the individual fans.

fanfront low   be quiet! Shadow Wings 2  140 mm   [1]
   front high  be quiet! Shadow Wings 2  140 mm
   CPU cooling tower   be quiet! Pure Wings 2120 mm  (2)  [2]
   rearCorsair   120 mm
   projector extra fractal Silent Series R3  140 mm   [3]
   (connectors are 3-pin)

   [1] https://www.bequiet.com/en/casefans/shadow-wings-2/1620
   "available with or without PWM control"
   [2] https://www.bequiet.com/en/casefans/449
   "Fan speed @ 100% PWM / 12V: 1500 RPM"
   [3] 
https://www.fractal-design.com/products/fans/silent/silent-series-r3-140mm/black/
   (Doesn't mention PWM.)

https://dataswamp.org/~incal/ebchw/COMPUTER

-- 
underground experts united
https://dataswamp.org/~incal

Re: zoom client for bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 02:37:30PM -0400, Jim Popovitch wrote:
> On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> > The zoom client downloaded from the zoom web page seems to have been 
> > written for Debian 8
> > 
> > Installing it in bullseye fails, dependency problems
> > 
> 
> Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
> you need to run "apt-get -f install" to fix the dependencies.

If that's true, then you could simply use "apt install ./zoom*.deb" in
the first place.  It's undocumented, but it has been a thing for several
years now.

Re: Debian 11 installer crashed and reboot

[Chuck Zmudzinski]

On 8/16/2021 2:30 AM, John Mok wrote:

Hi all,

Tried to install Debian 11 guest using netinst, but the installer
crashed and reboot automatically.

  Host: Xen 4.11.4 on Debian 10
Guest: Debian 11 (kernel 5.10)

Here is the steps to reproduce the problem:-
1) Either guest BIOS or OVMF boot
2) Select "Expert install" on installation menu

Then, the guest crashed and reboot.

Another try with the installer on Debian Live 11, it immediately
crashed and reboot.

Is it a installer bug or something ?

Thanks a lot.

John Mok



This problem has been reported by Philip Susi on 2021-04-27 in a
comment on linux kernel bug 207695:

https://bugzilla.kernel.org/show_bug.cgi?id=207695#c3

The kernel panic is caused by the Xen virtual keyboard.

I was able to capture a screenshot of the crash by setting
panic=60 and removing quiet from the kernel command line
on the grub menu (the kernel parameters for a grub boot
entry can be adjusted by pressing e when that grub boot
entry is highlighted, when booting with ovmf firmware).

Error message  reported by the kernel is:

failed to write 'add' to '/devices/virtual/input/input2/uevent': cannot 
allocate memory


This problem only occurs using the kernel on the installation
media, a full-featured bullseye kernel boots fine in a Xen HVM
guest.

The installer bullseye kernel also boots fine from the installer
media in a Xen PV guest.

I think the Xen HVM virtual keyboard is one provided by
Qemu. It apparently needs a larger buffer than the one
provided by the installation kernel.

Any ideas how to fix this in the installation kernel?

Chuck

Re: zoom client for bullseye

[Jim Popovitch]

On Sun, 2021-08-22 at 14:17 -0400, Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been 
> written for Debian 8
> 
> Installing it in bullseye fails, dependency problems
> 

Works for me (Deb11 + Cinnamon).  IIRC, after running dpkg -i zoom.deb
you need to run "apt-get -f install" to fix the dependencies.

hth,

-Jim P.

Re: zoom client for bullseye

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 2:17 p.m., Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been
> written for Debian 8
> 
> Installing it in bullseye fails, dependency problems
> 
What is the dependencies that fail ?
It does run on Debian Buster.
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: zoom client for bullseye

[Gokan Atmaca]

> Installing it in bullseye fails, dependency problems

Can you share the log? Or run apt -f install?


On Sun, Aug 22, 2021 at 9:25 PM Thomas George  wrote:
>
> The zoom client downloaded from the zoom web page seems to have been
> written for Debian 8
>
> Installing it in bullseye fails, dependency problems
>

Re: zoom client for bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 02:17:15PM -0400, Thomas George wrote:
> The zoom client downloaded from the zoom web page seems to have been written
> for Debian 8
> 
> Installing it in bullseye fails, dependency problems

There's not much we can do about that.  If you really want the standalone
application, contact Zoom.

I'd suggest simply running the in-browser version whenever you
need to attend a Zoom meeting.  It should work in either Firefox or
Chrome/Chromium.

zoom client for bullseye

[Thomas George]

The zoom client downloaded from the zoom web page seems to have been 
written for Debian 8


Installing it in bullseye fails, dependency problems

Re: FOSS "BIOS" (UEFI) (was: Re: smart fans)

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

> Google "Coreboot supported motherboard" ?
>
> And going to see this page as the first choice
>
> https://coreboot.org/status/board-status.html

Great, so was it on the list?

It wasn't, right?

Bummer...

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

The Wanderer wrote:

>>> See *doc/fan-divisors* for more information.
>> 
>> Yeah, but is that supposed to be a path? Or button?
>> What does it mean?
>
> It's clearly a reference to a path in the source, or native
> non-Debian-packaged build, tree of some relevant package.

OK, didn't know this notation/convention ... yes, I have it.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

tomas wrote:

> I disagree. The thing poses [1] as a DC motor (2 pins power,
> one tacho). I don't think you get too much control over RPM

That's what you get with the 4th wire/pin? A sensor to
read RPM?

"What you can't measure, you can't control"

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

>> Or what's this about fan-divisors?
>> 
>>   You may also need to increase the fan divisors.
>>   See doc/fan-divisors for more information.
>> 
> See *doc/fan-divisors* for more information.

Yeah, but is that supposed to be a path? Or button? What does
it mean?

> Maybe going out and reading this one ?

Not impossible.

-- 
underground experts united
https://dataswamp.org/~incal

Manual vs Auto-Install in APT[ was : kodi and gnome-control-center conflict on bullseye]

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 1:09 p.m., The Wanderer wrote:

> Note that if you eventually hit a command line which succeeds, you'll
> probably wind up marking all the listed packages as manually installed,
> which you may not want. It may be worth backing up your
> "manually-installed packages" state (as reported by the command
> 'apt-mark showmanual') before starting, so that after the whole thing is
> done with you can go back and mark specific packages as auto-installed.
> 

That's a great reminded that applies to many situation.
Thanks
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: kodi and gnome-control-center conflict on bullseye

[Tristan Miller]

Greetings.

On 22/08/2021 19.10, The Wanderer wrote:

What explicit version number do you suggest that I try?  Running "apt
install kodi gnome-control-center" tells me that

The following packages have unmet dependencies:
   kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be
installed
  Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to
be installed

But if I run "apt install kodi-bin=2:19.1+dfsg2-2", I am told

kodi-bin is already the newest version (2:19.1+dfsg2-2).


You need to continue specifying all of the packages in the same command
line, and repeat with new packages as necessary until it tells you an
actual reason for the failure instead of just the generic "is not going
to be installed".



Thanks; following this procedure I was eventually able to get apt into a 
state where it offered to install all the necessary dependencies for 
both kodi and gnome-control-center.


Regards,
Tristan

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: kodi and gnome-control-center conflict on bullseye

[The Wanderer]

On 2021-08-22 at 12:39, Tristan Miller wrote:

> Greetings.
> 
> On 22/08/2021 18.10, The Wanderer wrote:
> 
>> This appears to mean either that something is resulting in a
>> conflict with that version of kodi-bin, or that that version of
>> kodi-bin is not available.
>> 
>> I have:
>> 
>> $ apt-cache policy gnome-control-center kodi kodi-bin



>> What do you have available?
> 
> 
> Thanks. I get the following:
> 
> # apt-cache policy gnome-control-center kodi kodi-bin
> gnome-control-center:
>Installed: (none)
>Candidate: 1:3.38.4-1
>Version table:
>   1:3.38.4-1 500
>  500 http://deb.debian.org/debian bullseye/main amd64 Packages
> kodi:
>Installed: 2:19.1+dfsg2-2
>Candidate: 2:19.1+dfsg2-2
>Version table:
>   *** 2:19.1+dfsg2-2 500
>  500 http://deb.debian.org/debian bullseye/main amd64 Packages
>  100 /var/lib/dpkg/status
> kodi-bin:
>Installed: 2:19.1+dfsg2-2
>Candidate: 2:19.1+dfsg2-2
>Version table:
>   *** 2:19.1+dfsg2-2 500
>  500 http://deb.debian.org/debian bullseye/main amd64 Packages
>  100 /var/lib/dpkg/status

These version numbers all match mine.

This confirms that kodi-bin at the needed version number is available.

>> What I usually do in this type of situation is to start adding the
>> specified "is not going to be installed" packages to the command line,
>> with explicit version numbers included if necessary, until it stops just
>> saying "is not going to be installed" and starts telling me *why* some
>> particular package won't be installed. This is usually a Conflicts or
>> version-specific Depends or the like. From there, it's not usually
>> difficult to figure out what's causing the problem and what to do.
> 
> What explicit version number do you suggest that I try?  Running "apt 
> install kodi gnome-control-center" tells me that
> 
> The following packages have unmet dependencies:
>   kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be 
> installed
>  Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to 
> be installed
> 
> But if I run "apt install kodi-bin=2:19.1+dfsg2-2", I am told
> 
> kodi-bin is already the newest version (2:19.1+dfsg2-2).

You need to continue specifying all of the packages in the same command
line, and repeat with new packages as necessary until it tells you an
actual reason for the failure instead of just the generic "is not going
to be installed".

So,

# apt install gnome-control-center kodi kodi-bin

or

# apt install gnome-control-center kodi kodi-bin=2:19.1+dfsg2-2

and then if that just fails because of another package, add that one and
repeat.

(Based on your 'apt-cache policy' output, I don't think specifying the
explicit version number will be necessary in this case, but it may be in
some other cases.)


Note that if you eventually hit a command line which succeeds, you'll
probably wind up marking all the listed packages as manually installed,
which you may not want. It may be worth backing up your
"manually-installed packages" state (as reported by the command
'apt-mark showmanual') before starting, so that after the whole thing is
done with you can go back and mark specific packages as auto-installed.

-- 
   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: kodi and gnome-control-center conflict on bullseye

[Tristan Miller]

Greetings.

On 22/08/2021 18.10, Greg Wooledge wrote:

Do you have any packages on hold?  dpkg -l | grep ^h



No, no output from that command.


Do you have any packages pinned, either manually, or by way of some
automatic action performed by apt-listbugs?  I'm not an expert in
pinning, but maybe start with:  grep -ri pin /etc/apt



No pins listed by that command, and apt-cache policy also doesn't list 
anything under "Pinned packages".



If neither of these is the case, then I'd try:

apt-cache polisy kodi kodi-bin  # just to get some information



# apt-cache policy kodi kodi-bin
kodi:
  Installed: 2:19.1+dfsg2-2
  Candidate: 2:19.1+dfsg2-2
  Version table:
 *** 2:19.1+dfsg2-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
kodi-bin:
  Installed: 2:19.1+dfsg2-2
  Candidate: 2:19.1+dfsg2-2
  Version table:
 *** 2:19.1+dfsg2-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status



And if that looks OK, then:

apt install kodi kodi-bin



# apt install kodi kodi-bin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
kodi is already the newest version (2:19.1+dfsg2-2).
kodi-bin is already the newest version (2:19.1+dfsg2-2).
kodi-bin set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.


Or maybe:

apt -f install# with no packages, just to try to fix what's broken



# apt -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.


So it looks like none of your commands turned up anything, or any 
problems, and yet it's still not possible for me to install 
gnome-control-center.


Regards,
Tristan

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: kodi and gnome-control-center conflict on bullseye

[Tristan Miller]

Greetings.

On 22/08/2021 18.10, The Wanderer wrote:

This appears to mean either that something is resulting in a conflict
with that version of kodi-bin, or that that version of kodi-bin is not
available.

I have:

$ apt-cache policy gnome-control-center kodi kodi-bin
gnome-control-center:
   Installed: (none)
   Candidate: 1:3.38.4-1
   Version table:
  1:3.38.4-1 900
 800 http://ftp.us.debian.org/debian stable/main amd64 Packages
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages
kodi:
   Installed: (none)
   Candidate: 2:19.1+dfsg2-2
   Version table:
  2:19.1+dfsg2-2 900
 800 http://ftp.us.debian.org/debian stable/main amd64 Packages
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages
kodi-bin:
   Installed: (none)
   Candidate: 2:19.1+dfsg2-2
   Version table:
  2:19.1+dfsg2-2 900
 800 http://ftp.us.debian.org/debian stable/main amd64 Packages
 900 http://ftp.us.debian.org/debian testing/main amd64 Packages

What do you have available?



Thanks. I get the following:

# apt-cache policy gnome-control-center kodi kodi-bin
gnome-control-center:
  Installed: (none)
  Candidate: 1:3.38.4-1
  Version table:
 1:3.38.4-1 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
kodi:
  Installed: 2:19.1+dfsg2-2
  Candidate: 2:19.1+dfsg2-2
  Version table:
 *** 2:19.1+dfsg2-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
kodi-bin:
  Installed: 2:19.1+dfsg2-2
  Candidate: 2:19.1+dfsg2-2
  Version table:
 *** 2:19.1+dfsg2-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status


What I usually do in this type of situation is to start adding the
specified "is not going to be installed" packages to the command line,
with explicit version numbers included if necessary, until it stops just
saying "is not going to be installed" and starts telling me *why* some
particular package won't be installed. This is usually a Conflicts or
version-specific Depends or the like. From there, it's not usually
difficult to figure out what's causing the problem and what to do.



What explicit version number do you suggest that I try?  Running "apt 
install kodi gnome-control-center" tells me that


The following packages have unmet dependencies:
 kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be 
installed
Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to 
be installed


But if I run "apt install kodi-bin=2:19.1+dfsg2-2", I am told

kodi-bin is already the newest version (2:19.1+dfsg2-2).

Regards,
Tristan

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 12:43 p.m., Polyna-Maude Racicot-Summerside wrote:
> 
> 
> On 2021-08-22 9:41 a.m., to...@tuxteam.de wrote:
>> On Sun, Aug 22, 2021 at 09:03:51AM -0400, Polyna-Maude Racicot-Summerside 
>> wrote:
>>
>> [...]
>>
>>> Like I already wrote, modifying voltage doesn't change speed of a motor
>>> (fan).
>>
>> I disagree. The thing poses [1] as a DC motor (2 pins power, one tacho).
>> I don't think you get too much control over RPM, but putting the tacho
>> in the control loop should be possible.
>>
>> I have no idea what the motherboard/fan manufacturers actually do, though.
> Yes it is possible to modify speed of a motor by varying DC voltage. But
> this is not the case in the present situation.

I mean without resorting to adding extra hardware.

And personally I find it a bit crazy to add stuff so you can cut off
your fans without ensuring that they can also be started if temperature
rise in *autonomous* way.

I missed part of the conversation and we are now getting into a DIY
project with switches, resistor and more. In some way, developing some
way to cut the safety net.
>>
>> Cheers
>>
>> [1] I'm nearly certain it's a BLDC in disguise, with some electronic goo.
>>
>>  - t
>>
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: FOSS "BIOS" (UEFI) (was: Re: smart fans)

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 10:04 a.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>> Google "Coreboot supported motherboard" ?
>>
>> And going to see this page as the first choice
>>
>> https://coreboot.org/status/board-status.html
> 
> Great, so was it on the list?
I don't know ! Why don't you take a look yourself ?

I'm ready to help you build whatever you want. But this does not mean
that I'll be doing all the job myself.
> 
> It wasn't, right?
> 
> Bummer...
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Charles DAVID]

Salut,

Tu as regardé si le module mod_tls était activé dans 
/etc/proftpd/modules.conf ?


Tu peux lister les modules avec :

$ proftpd --list

Tu peux aussi lancer proftpd en mode debug pour avoir plus d'informations :

$ proftpd --nodaemon --debug 10

Pour valider la syntaxe de la configuration :

$ proftpd --configtest

source : http://www.proftpd.org/docs/howto/Debugging.html

Charles.

Le 22/08/2021 à 17:20, Jean-François Bachelet a écrit :

Hello folks ^^)


bon, le passage de buster à bullseye sur serveur ne se fait pas sans 
problèmes :(



dabort, mon proftpd ne voulait pas se mettre à jour : résolu en 
désinstallant tout proftpd (plus rien ne faisant référence à lui sur le 
serveur) puis install proftpd-basic qui appelle correctement les 
dépendances.


un problème de moins ;

ensuite restauration des nouvelles confs et redémarrage du serveur ;

essaie de connexion ftps avec filezilla comme ça fonctionnait sous 
buster : niet ! 'vous vous êtes déjà connecté à ce serveur en ftp over 
tls mais ce serveur ne supporte pas ftp over tls' ! un comble !



c'est quoi le problème maintenant ???


voilà les confs :


proftpd.conf :

#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes, reload proftpd after modifications, if
# it runs in daemon mode. It is not required in inetd/xinetd mode.
#

# Includes DSO modules
Include /etc/proftpd/modules.conf

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 on
# If set on you can experience a longer connection delay in many cases.

IdentLookups off


ServerName "ftp3.myownfqdn"
# Set to inetd only if you would run proftpd by inetd/xinetd/socket.
# Read README.Debian for more information on proper configuration.
ServerType standalone
DeferWelcome off

# Disable MultilineRFC2228 per 
https://github.com/proftpd/proftpd/issues/1085 


# MultilineRFC2228on
DefaultServer on
ShowSymlinks on

TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200

DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"

DenyFilter \*.*/

# Use this to jail all users in their homes
DefaultRoot ~

# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
# RequireValidShelloff

# Port 21 is the standard FTP port.
Port 21

# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
PassivePorts 49152 49252

# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
# MasqueradeAddress 1.2.3.4

# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours

# DynMasqRefresh 28800


# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at.
User proftpd
Group nogroup

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022 022
# Normally, we want files to be overwriteable.
AllowOverwrite on

# Uncomment this if you are using NIS or LDAP via NSS to retrieve 
passwords:

# PersistentPasswd off

# This is required to use both PAM-based authentication and local passwords
# AuthOrder mod_auth_pam.c* mod_auth_unix.c

# Be warned: use of this directive impacts CPU average load!
# Uncomment this if you like to see progress and transfer rate with ftpwho
# in downloads. That is not needed for uploads rates.
#
# UseSendFile off

TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log

# Logging onto /var/log/lastlog is enabled but set to off by default
#UseLastlog on

# In order to keep log file dates consistent after chroot, use timezone 
info

# from /etc/localtime. If this is not set, and proftpd is configured to
# chroot (e.g. DefaultRoot or ), it will use the non-daylight
# savings timezone regardless of whether DST is in effect.
SetEnv TZ :/etc/localtime


QuotaEngine off



Ratios off



# Delay engine reduces impact of the so-called Timing Attack described in
# http://www.securityfocus.com/bid/11430/discuss 


# It is on by default.

DelayEngine on



ControlsEngine off
ControlsMaxClients 2
ControlsLog /var/log/proftpd/controls.log
ControlsInterval 5
ControlsSocket /var/run/proftpd/proftpd.sock



AdminControlsEngine off


#
# Alternative authentication frameworks
#
#Include 

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 10:02 a.m., Emanuel Berg wrote:
> tomas wrote:
> 
>> I disagree. The thing poses [1] as a DC motor (2 pins power,
>> one tacho). I don't think you get too much control over RPM
> 
> That's what you get with the 4th wire/pin? A sensor to
> read RPM?
> 
Opposite
3 wire = 2 wire to drive motor + 1 wire to get speed
4 wire = 2 wire to drive, 1 to get speed, 1 to modify speed

> "What you can't measure, you can't control"
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 10:00 a.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>>> Or what's this about fan-divisors?
>>>
>>>   You may also need to increase the fan divisors.
>>>   See doc/fan-divisors for more information.
>>>
>> See *doc/fan-divisors* for more information.
> 
> Yeah, but is that supposed to be a path? Or button? What does
> it mean?
It means to go read in /usr/share/doc/[name of the package]/

Debian copies the doc folder into /usr/share/doc/[package name]
> 
>> Maybe going out and reading this one ?
> 
> Not impossible.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 9:41 a.m., to...@tuxteam.de wrote:
> On Sun, Aug 22, 2021 at 09:03:51AM -0400, Polyna-Maude Racicot-Summerside 
> wrote:
> 
> [...]
> 
>> Like I already wrote, modifying voltage doesn't change speed of a motor
>> (fan).
> 
> I disagree. The thing poses [1] as a DC motor (2 pins power, one tacho).
> I don't think you get too much control over RPM, but putting the tacho
> in the control loop should be possible.
> 
> I have no idea what the motherboard/fan manufacturers actually do, though.
Yes it is possible to modify speed of a motor by varying DC voltage. But
this is not the case in the present situation.
> 
> Cheers
> 
> [1] I'm nearly certain it's a BLDC in disguise, with some electronic goo.
> 
>  - t
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Relatively boring bullseye upgrade reports

[Reco]

Ok, serious things.

male: QEMU VM, remote hosting, console access is available
Primary MX, IPSec endpoint

Upgrade was tricky, because IPSec tunnel was brought down during the
upgrade. It went up, but I was required to bounce sshd from the console
nevertheless.
Replaced sysvinit with systemd-sysv while I was at it.
Replaced sslh with nginx stream config for SSH/HTTPS multiplexing.


i5378: Dell Inspiron 5378, 4Gb ram, 7th gen Intel Core, LXDE/openbox
Secondary tool of the trade

The upgrade took out my favorite Terminus font from the terminal
emulator, (no)thanks to the upgraded fontconfig. Replaced Terminus with
self-built OTB version.

The upgrade of Icecast reverted all its passwords to the default,
without any question asked. Got them back via git history (etckeeper).
I'd expect a pitfall like this from RHEL.

An internal NIC (ip link add type bridge) that I use for LXC showed
NO-CARRIER unless at least one NIC was attached to it (worked
differently in buster). Worked around that by adding dummy NIC (ip link
add type dummy) to the bridge.

LXC configs required numerous /cgroup/cgroup2/ replacements, but there's
sed for that. Luckily, I do not have to run anything RHEL-based there.
And no, I do not need that lxc-net screwing my netfilter rules.

They've renamed obexd from bluez-obexd from good and proper Debian
pathname to a horrible RH one. Had to fix my Bluetooth MAP script as the
result. A small price for the distribution unification, I suppose.


n10i5: Intel NUC N10I5, 8Gb ram, 10th gen Intel Core, LXDE/openbox
Primary tool of the trade

I forgot to clear apt pinnings before the upgrade, and was left with
self-backported mesa, vaapi and libdrm. Nothing that 'apt install -t
stable' could not handle though.
See also i5378.


There's that other VM (female, IPSec endpoint) left, and a half-dozen
servers at the office, but it can wait until my vacation ends.


My biggest surprises from all this:
- most of my custom Apparmor profiles survived OS upgrades with no
  modifications at all.
- most of custom rsyslogd filters continue to work as intended.
- and the size of vmlinuz and initrd.img did not increase that much,
  which allowed me to leave u-boot configuration untouched.


IMO - Debian 11 is a good release, transition to it is easy. Easier than
8->9 one (systemd was introduced) or 9->10 one (iptables -> nft, and
"predictable" NIC names). But then again, it's not my first rodeo.


Stuff I did beforehand just in case:

# Thanks, I do not need *that* kind of predictability
ln -sf /dev/null /etc/systemd/network/73-usb-net-by-mac.link

# And I like my logs to be human-readable
sed -r 's/#Storage=.*/Storage=volatile' /etc/systemd/journald.conf

# ARM only, what's wrong with these ppl?
systemctl mask systemd-pstore.service

# SBCs, laptop and desktop
# iostat and pidstat are cool, constant writes to /var/log/sysstat are
# not
systemctl mask sysstat-collect.timer sysstat-summary.timer

Reco

Re: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Bernard Schoenacker]

- Mail original -
> De: "Jean-François Bachelet" 
> À: debian-user-french@lists.debian.org
> Envoyé: Dimanche 22 Août 2021 18:13:00
> Objet: Re: multiples problèmes avec proftpd depuis upgrade bullseye sur 
> serveur :-(
> 
> Hello Bernard ^^)
> 
> 
> Le 22/08/2021 à 17:36, Bernard Schoenacker a écrit :
> 
> heu ! j'employais le ftpS pas le ftp... et ça marchait. sécurisé par
> TLSv1.2.
> 
> 
> passer au SFTP ça sous-entend demander à des milliers d'utilisateur
> ftpS
> d'envoyer leur clé SSH (avec l'immense boulot que ça nécessitera
> derrière)
> 
> et comme nombre d'entre eux n'ont jamais utilisé SSH (donc n'ont pas
> de
> clé et ne savent même pas ce que c'est que SSH) imagines le deuxième
> immense boulot pour les former à ça et à créer leurs clés et surtout
> les
> tonnes de mails 'au secours ça marche pô' à répondre par le
> support...
> 
> arg. tu veux ma mort ? ;)))
> 
> 
> mouais :/
> 
> c'est pas normal m'enfin ! le ftpS fonctionnait sous buster donc il
> DOIT
> aussi fonctionner sous bullseye étant donné qu'il n'a pas été
> déprécié.
> 
> 
> Jeff, horrifié ;)
> 


Bonjour,

J'ai déjà fait un essai avec sftp et filezilla et c'est transparent 
pour les $USER ...

Et vu ton patronyme, un peu de silicose ne fera pas trop de mal ;)

https://www.youtube.com/watch?v=rygifBeBKUU

https://www.youtube.com/watch?v=lBrmR8Brasw

Merci 

@+

bernard

Re: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Jean-François Bachelet]

Hello Bernard ^^)


Le 22/08/2021 à 17:36, Bernard Schoenacker a écrit :

Bonjour Jean-Fransoué,


Je te conseille de monter d'un cran en n'employant plus
le ftp directement, voici le tutoriel qui te permettra
d'augmenter la sécurité :

https://www.digitalocean.com/community/tutorials/how-to-configure-proftpd-to-use-sftp-instead-of-ftp


heu ! j'employais le ftpS pas le ftp... et ça marchait. sécurisé par 
TLSv1.2.



passer au SFTP ça sous-entend demander à des milliers d'utilisateur ftpS 
d'envoyer leur clé SSH (avec l'immense boulot que ça nécessitera derrière)


et comme nombre d'entre eux n'ont jamais utilisé SSH (donc n'ont pas de 
clé et ne savent même pas ce que c'est que SSH) imagines le deuxième 
immense boulot pour les former à ça et à créer leurs clés et surtout les 
tonnes de mails 'au secours ça marche pô' à répondre par le support...


arg. tu veux ma mort ? ;)))



et pour faire passer la pilule :

https://www.youtube.com/watch?v=44FWZ03kWog

désolé, mais je ne vois que cette solution


mouais :/

c'est pas normal m'enfin ! le ftpS fonctionnait sous buster donc il DOIT 
aussi fonctionner sous bullseye étant donné qu'il n'a pas été déprécié.




Bonne chance pour la suite

Bien à toi

Bernard


Jeff, horrifié ;)

Re: Debian 10.7 no me actualiza.

[JavierDebian]

El 21/8/21 a las 13:27, Aristobulo Pinzon escribió:

Buenas Tardes apreciados colaboradores.
Debian 10.7 no me actualiza. Me da estos mensajes y no logro saber que
debo hacer, si cambiar los repositorios del sources.list  y colocar
que? para seguir con buster uos meses más.
muchas gracias por su colaboración.




¿Qué mensajes te da?
Pegalos para verlos.

¿Cuáles son tus repositorios?
Elige uno que sea confiable, esté cerca y se actualice periódicamente.

JAP

Re: kodi and gnome-control-center conflict on bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 12:04:46PM -0400, Greg Wooledge wrote:
> If neither of these is the case, then I'd try:
> 
> apt-cache polisy kodi kodi-bin  # just to get some information

Wow, today must be Typoday.  "policy" of course.

Re: kodi and gnome-control-center conflict on bullseye

[Greg Wooledge]

On Sun, Aug 22, 2021 at 05:37:52PM +0200, Tristan Miller wrote:
> # apt install kodi gnome-control-center
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> kodi is already the newest version (2:19.1+dfsg2-2).
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be
> installed
> Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to be
> installed
> E: Unable to correct problems, you have held broken packages.

Do you have any packages on hold?  dpkg -l | grep ^h

Do you have any packages pinned, either manually, or by way of some
automatic action performed by apt-listbugs?  I'm not an expert in
pinning, but maybe start with:  grep -ri pin /etc/apt

If neither of these is the case, then I'd try:

apt-cache polisy kodi kodi-bin  # just to get some information

And if that looks OK, then:

apt install kodi kodi-bin

Or maybe:

apt -f install# with no packages, just to try to fix what's broken


In all cases, be prepared to tell apt "No" if it asks you to do something
that looks undesirable, like removing stuff you care about.

Re: kodi and gnome-control-center conflict on bullseye

[The Wanderer]

On 2021-08-22 at 11:37, Tristan Miller wrote:

> Greetings.
> 
> On 22/08/2021 17.20, The Wanderer wrote:
>> On 2021-08-22 at 10:46, Tristan Miller wrote:
>>> On my bullseye system, it doesn't seem to be possible to install both
>>> kodi and gnome-control-center as they conflict with each other.  (See
>>> below for what happens when I've got kodi installed and then try to
>>> install gnome-control-center.)
>> 
>> What happens if you instead run
>> 
>> $ apt install kodi gnome-control-center
>> 
>> ? You should either get a success (via different resolution of the
>> dependencies, which doesn't consider omitting either of the two to be an
>> acceptable solution) or an error which may help us narrow down the problem.
> 
> 
> Here's the output:
> 
> # apt install kodi gnome-control-center
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> kodi is already the newest version (2:19.1+dfsg2-2).
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>   kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be 
> installed
>  Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to 
> be installed
> E: Unable to correct problems, you have held broken packages.

Hmm.

This appears to mean either that something is resulting in a conflict
with that version of kodi-bin, or that that version of kodi-bin is not
available.

I have:

$ apt-cache policy gnome-control-center kodi kodi-bin
gnome-control-center:
  Installed: (none)
  Candidate: 1:3.38.4-1
  Version table:
 1:3.38.4-1 900
800 http://ftp.us.debian.org/debian stable/main amd64 Packages
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
kodi:
  Installed: (none)
  Candidate: 2:19.1+dfsg2-2
  Version table:
 2:19.1+dfsg2-2 900
800 http://ftp.us.debian.org/debian stable/main amd64 Packages
900 http://ftp.us.debian.org/debian testing/main amd64 Packages
kodi-bin:
  Installed: (none)
  Candidate: 2:19.1+dfsg2-2
  Version table:
 2:19.1+dfsg2-2 900
800 http://ftp.us.debian.org/debian stable/main amd64 Packages
900 http://ftp.us.debian.org/debian testing/main amd64 Packages

What do you have available?


What I usually do in this type of situation is to start adding the
specified "is not going to be installed" packages to the command line,
with explicit version numbers included if necessary, until it stops just
saying "is not going to be installed" and starts telling me *why* some
particular package won't be installed. This is usually a Conflicts or
version-specific Depends or the like. From there, it's not usually
difficult to figure out what's causing the problem and what to do.

-- 
   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: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Jean-François Bachelet]

re re Hello ^^)

Le 22/08/2021 à 17:27, Jean-François Bachelet a écrit :

re hello ^^)


note : la seule et unique différence par rapport à l'ancienne conf 
sous buster c'est



'multiline RCF2228 on'


qui est passé à 'off' par défaut


# Disable MultilineRFC2228 per 
https://github.com/proftpd/proftpd/issues/1085 


# MultilineRFC2228 on


tried to re-enable multiline but that changed nothing...


what I don't understand is WHY that worked fine under buster and not now 
under  bullseye...



Jeff

Re: kodi and gnome-control-center conflict on bullseye

[Tristan Miller]

Greetings.

On 22/08/2021 17.20, The Wanderer wrote:

On 2021-08-22 at 10:46, Tristan Miller wrote:

On my bullseye system, it doesn't seem to be possible to install both
kodi and gnome-control-center as they conflict with each other.  (See
below for what happens when I've got kodi installed and then try to
install gnome-control-center.)


What happens if you instead run

$ apt install kodi gnome-control-center

? You should either get a success (via different resolution of the
dependencies, which doesn't consider omitting either of the two to be an
acceptable solution) or an error which may help us narrow down the problem.



Here's the output:

# apt install kodi gnome-control-center
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
kodi is already the newest version (2:19.1+dfsg2-2).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 kodi : Depends: kodi-bin (>= 2:19.1+dfsg2-2) but it is not going to be 
installed
Depends: kodi-bin (< 2:19.1+dfsg2-2.1~) but it is not going to 
be installed

E: Unable to correct problems, you have held broken packages.

Regards,
Tristan

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Bernard Schoenacker]

Bonjour Jean-Fransoué,


Je te conseille de monter d'un cran en n'employant plus 
le ftp directement, voici le tutoriel qui te permettra 
d'augmenter la sécurité :

https://www.digitalocean.com/community/tutorials/how-to-configure-proftpd-to-use-sftp-instead-of-ftp

et pour faire passer la pilule :

https://www.youtube.com/watch?v=44FWZ03kWog

désolé, mais je ne vois que cette solution 

Bonne chance pour la suite

Bien à toi

Bernard

- Mail original -
> De: "Jean-François Bachelet" 
> À: debian-user-french@lists.debian.org
> Envoyé: Dimanche 22 Août 2021 17:20:42
> Objet: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur 
> :-(
> 
> Hello folks ^^)
> 
> 
> bon, le passage de buster à bullseye sur serveur ne se fait pas sans
> problèmes :(
> 
> 
> dabort, mon proftpd ne voulait pas se mettre à jour : résolu en
> désinstallant tout proftpd (plus rien ne faisant référence à lui sur
> le
> serveur) puis install proftpd-basic qui appelle correctement les
> dépendances.
> 
> un problème de moins ;
> 
> ensuite restauration des nouvelles confs et redémarrage du serveur ;
> 
> essaie de connexion ftps avec filezilla comme ça fonctionnait sous
> buster : niet ! 'vous vous êtes déjà connecté à ce serveur en ftp
> over
> tls mais ce serveur ne supporte pas ftp over tls' ! un comble !
> 
> 
> c'est quoi le problème maintenant ???
> 
> 
> voilà les confs :
> 
> 
> proftpd.conf :
> 
> #
> # /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration
> file.
> # To really apply changes, reload proftpd after modifications, if
> # it runs in daemon mode. It is not required in inetd/xinetd mode.
> #
> 
> # Includes DSO modules
> Include /etc/proftpd/modules.conf
> 
> # Set off to disable IPv6 support which is annoying on IPv4 only
> boxes.
> UseIPv6 on
> # If set on you can experience a longer connection delay in many
> cases.
> 
> IdentLookups off
> 
> 
> ServerName "ftp3.myownfqdn"
> # Set to inetd only if you would run proftpd by inetd/xinetd/socket.
> # Read README.Debian for more information on proper configuration.
> ServerType standalone
> DeferWelcome off
> 
> # Disable MultilineRFC2228 per
> https://github.com/proftpd/proftpd/issues/1085
> 
> # MultilineRFC2228on
> DefaultServer on
> ShowSymlinks on
> 
> TimeoutNoTransfer 600
> TimeoutStalled 600
> TimeoutIdle 1200
> 
> DisplayLogin welcome.msg
> DisplayChdir .message true
> ListOptions "-l"
> 
> DenyFilter \*.*/
> 
> # Use this to jail all users in their homes
> DefaultRoot ~
> 
> # Users require a valid shell listed in /etc/shells to login.
> # Use this directive to release that constrain.
> # RequireValidShelloff
> 
> # Port 21 is the standard FTP port.
> Port 21
> 
> # In some cases you have to specify passive ports range to by-pass
> # firewall limitations. Ephemeral ports can be used for that, but
> # feel free to use a more narrow range.
> PassivePorts 49152 49252
> 
> # If your host was NATted, this option is useful in order to
> # allow passive tranfers to work. You have to use your public
> # address and opening the passive ports used on your firewall as
> well.
> # MasqueradeAddress 1.2.3.4
> 
> # This is useful for masquerading address with dynamic IPs:
> # refresh any configured MasqueradeAddress directives every 8 hours
> 
> # DynMasqRefresh 28800
> 
> 
> # To prevent DoS attacks, set the maximum number of child processes
> # to 30. If you need to allow more than 30 concurrent connections
> # at once, simply increase this value. Note that this ONLY works
> # in standalone mode, in inetd mode you should use an inetd server
> # that allows you to limit maximum number of processes per service
> # (such as xinetd)
> MaxInstances 30
> 
> # Set the user and group that the server normally runs at.
> User proftpd
> Group nogroup
> 
> # Umask 022 is a good standard umask to prevent new files and dirs
> # (second parm) from being group and world writable.
> Umask 022 022
> # Normally, we want files to be overwriteable.
> AllowOverwrite on
> 
> # Uncomment this if you are using NIS or LDAP via NSS to retrieve
> passwords:
> # PersistentPasswd off
> 
> # This is required to use both PAM-based authentication and local
> passwords
> # AuthOrder mod_auth_pam.c* mod_auth_unix.c
> 
> # Be warned: use of this directive impacts CPU average load!
> # Uncomment this if you like to see progress and transfer rate with
> ftpwho
> # in downloads. That is not needed for uploads rates.
> #
> # UseSendFile off
> 
> TransferLog /var/log/proftpd/xferlog
> SystemLog /var/log/proftpd/proftpd.log
> 
> # Logging onto /var/log/lastlog is enabled but set to off by default
> #UseLastlog on
> 
> # In order to keep log file dates consistent after chroot, use
> timezone info
> # from /etc/localtime. If this is not set, and proftpd is configured
> to
> # chroot (e.g. DefaultRoot or ), it will use the
> non-daylight
> # savings timezone regardless of whether DST is in effect.
> SetEnv TZ :/etc/localtime
> 
> 

Re: multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Jean-François Bachelet]

re hello ^^)


Le 22/08/2021 à 17:20, Jean-François Bachelet a écrit :

Hello folks ^^)


bon, le passage de buster à bullseye sur serveur ne se fait pas sans 
problèmes :(



dabort, mon proftpd ne voulait pas se mettre à jour : résolu en 
désinstallant tout proftpd (plus rien ne faisant référence à lui sur 
le serveur) puis install proftpd-basic qui appelle correctement les 
dépendances.


un problème de moins ;

ensuite restauration des nouvelles confs et redémarrage du serveur ;

essaie de connexion ftps avec filezilla comme ça fonctionnait sous 
buster : niet ! 'vous vous êtes déjà connecté à ce serveur en ftp over 
tls mais ce serveur ne supporte pas ftp over tls' ! un comble !



c'est quoi le problème maintenant ???


voilà les confs :


proftpd.conf :

#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes, reload proftpd after modifications, if
# it runs in daemon mode. It is not required in inetd/xinetd mode.
#

# Includes DSO modules
Include /etc/proftpd/modules.conf

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 on
# If set on you can experience a longer connection delay in many cases.

IdentLookups off


ServerName "ftp3.myownfqdn"
# Set to inetd only if you would run proftpd by inetd/xinetd/socket.
# Read README.Debian for more information on proper configuration.
ServerType standalone
DeferWelcome off

# Disable MultilineRFC2228 per 
https://github.com/proftpd/proftpd/issues/1085 


# MultilineRFC2228on
DefaultServer on
ShowSymlinks on

TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200

DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"

DenyFilter \*.*/

# Use this to jail all users in their homes
DefaultRoot ~

# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
# RequireValidShelloff

# Port 21 is the standard FTP port.
Port 21

# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
PassivePorts 49152 49252

# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
# MasqueradeAddress 1.2.3.4

# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours

# DynMasqRefresh 28800


# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at.
User proftpd
Group nogroup

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022 022
# Normally, we want files to be overwriteable.
AllowOverwrite on

# Uncomment this if you are using NIS or LDAP via NSS to retrieve 
passwords:

# PersistentPasswd off

# This is required to use both PAM-based authentication and local 
passwords

# AuthOrder mod_auth_pam.c* mod_auth_unix.c

# Be warned: use of this directive impacts CPU average load!
# Uncomment this if you like to see progress and transfer rate with ftpwho
# in downloads. That is not needed for uploads rates.
#
# UseSendFile off

TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log

# Logging onto /var/log/lastlog is enabled but set to off by default
#UseLastlog on

# In order to keep log file dates consistent after chroot, use 
timezone info

# from /etc/localtime. If this is not set, and proftpd is configured to
# chroot (e.g. DefaultRoot or ), it will use the non-daylight
# savings timezone regardless of whether DST is in effect.
SetEnv TZ :/etc/localtime


QuotaEngine off



Ratios off



# Delay engine reduces impact of the so-called Timing Attack described in
# http://www.securityfocus.com/bid/11430/discuss 


# It is on by default.

DelayEngine on



ControlsEngine off
ControlsMaxClients 2
ControlsLog /var/log/proftpd/controls.log
ControlsInterval 5
ControlsSocket /var/run/proftpd/proftpd.sock



AdminControlsEngine off


#
# Alternative authentication frameworks
#
#Include /etc/proftpd/ldap.conf
#Include /etc/proftpd/sql.conf

#
# This is used for FTPS connections
#
Include /etc/proftpd/tls.conf

#
# This is used for SFTP connections
#
#Include /etc/proftpd/sftp.conf

#
# This is used for other add-on modules
#
#Include /etc/proftpd/dnsbl.conf
#Include /etc/proftpd/geoip.conf
#Include /etc/proftpd/snmp.conf

#
# Useful to keep VirtualHost/VirtualRoot directives 

Re: smart fans

[Hans]

Am Sonntag, 22. August 2021, 09:42:20 CEST schrieb Emanuel Berg:
Just a little hint: On my EEEPC for example, pwmconfig and fancontrol did not 
work, as it is loading the wrong module.

This can be fixed with a kernel param, that let load another kernel module, 
which is supporting pwmconfig and fancontrol.

Just a little info, but I believe, all modern cpus are now using the same 
kernel module, maybe just my old EEEPC does not.

However, I just wanted to mention this thing.

Happy hacking

Hans

> tomas wrote:
> > Start here [1]. Enjoy.
> > 
> > [1] https://wiki.archlinux.org/title/Fan_speed_control
> 
> Yes, but ...
> 
> $ sudo pwmconfig
> # pwmconfig version 3.6.0
> This program will search your sensors for pulse width
> modulation (pwm) controls, and test each one to see if it
> controls a fan on your motherboard. Note that many
> motherboards do not have pwm circuitry installed, even if your
> sensor chip supports pwm.
> 

signature.asc
Description: This is a digitally signed message part.

Re: FOSS "BIOS" (UEFI)

[Emanuel Berg]

The Wanderer wrote:

>> There is a grub-coreboot package, is that it?
>
> No. If you look at the output of
>
> $ apt-cache show coreboot
>
> you'll see that it says
>
> "This is a dependency package for a version of GRUB that has
> been built for use with platforms running the
> Coreboot firmware."
>
> As that indicates, this is not / does not install coreboot
> itself, it only installs a version of GRUB that knows how to
> interact with coreboot.
>
>> And how do you know if its supported?
>
> Read the coreboot board-compatibility list, which to the
> best of my ability to determine on short notice is at:
>
> https://coreboot.org/status/board-status.html
>
> I haven't looked in depth, but
> https://doc.coreboot.org/mainboard/index.html and/or the rest of
> https://doc.coreboot.org/ might be useful.
>
>> I think I have a
>> 
>> Asus ROG Strix B450-F Gaming
>> 
>> motherboard.
>
> You'd need the actual, internal model number, but I suspect
> that that is far too new to be likely to be
> (well-)supported yet.

OK, thanks.

-- 
underground experts united
https://dataswamp.org/~incal

multiples problèmes avec proftpd depuis upgrade bullseye sur serveur :-(

[Jean-François Bachelet]

Hello folks ^^)


bon, le passage de buster à bullseye sur serveur ne se fait pas sans 
problèmes :(



dabort, mon proftpd ne voulait pas se mettre à jour : résolu en 
désinstallant tout proftpd (plus rien ne faisant référence à lui sur le 
serveur) puis install proftpd-basic qui appelle correctement les 
dépendances.


un problème de moins ;

ensuite restauration des nouvelles confs et redémarrage du serveur ;

essaie de connexion ftps avec filezilla comme ça fonctionnait sous 
buster : niet ! 'vous vous êtes déjà connecté à ce serveur en ftp over 
tls mais ce serveur ne supporte pas ftp over tls' ! un comble !



c'est quoi le problème maintenant ???


voilà les confs :


proftpd.conf :

#
# /etc/proftpd/proftpd.conf -- This is a basic ProFTPD configuration file.
# To really apply changes, reload proftpd after modifications, if
# it runs in daemon mode. It is not required in inetd/xinetd mode.
#

# Includes DSO modules
Include /etc/proftpd/modules.conf

# Set off to disable IPv6 support which is annoying on IPv4 only boxes.
UseIPv6 on
# If set on you can experience a longer connection delay in many cases.

IdentLookups off


ServerName "ftp3.myownfqdn"
# Set to inetd only if you would run proftpd by inetd/xinetd/socket.
# Read README.Debian for more information on proper configuration.
ServerType standalone
DeferWelcome off

# Disable MultilineRFC2228 per 
https://github.com/proftpd/proftpd/issues/1085 


# MultilineRFC2228on
DefaultServer on
ShowSymlinks on

TimeoutNoTransfer 600
TimeoutStalled 600
TimeoutIdle 1200

DisplayLogin welcome.msg
DisplayChdir .message true
ListOptions "-l"

DenyFilter \*.*/

# Use this to jail all users in their homes
DefaultRoot ~

# Users require a valid shell listed in /etc/shells to login.
# Use this directive to release that constrain.
# RequireValidShelloff

# Port 21 is the standard FTP port.
Port 21

# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
PassivePorts 49152 49252

# If your host was NATted, this option is useful in order to
# allow passive tranfers to work. You have to use your public
# address and opening the passive ports used on your firewall as well.
# MasqueradeAddress 1.2.3.4

# This is useful for masquerading address with dynamic IPs:
# refresh any configured MasqueradeAddress directives every 8 hours

# DynMasqRefresh 28800


# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

# Set the user and group that the server normally runs at.
User proftpd
Group nogroup

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022 022
# Normally, we want files to be overwriteable.
AllowOverwrite on

# Uncomment this if you are using NIS or LDAP via NSS to retrieve passwords:
# PersistentPasswd off

# This is required to use both PAM-based authentication and local passwords
# AuthOrder mod_auth_pam.c* mod_auth_unix.c

# Be warned: use of this directive impacts CPU average load!
# Uncomment this if you like to see progress and transfer rate with ftpwho
# in downloads. That is not needed for uploads rates.
#
# UseSendFile off

TransferLog /var/log/proftpd/xferlog
SystemLog /var/log/proftpd/proftpd.log

# Logging onto /var/log/lastlog is enabled but set to off by default
#UseLastlog on

# In order to keep log file dates consistent after chroot, use timezone info
# from /etc/localtime. If this is not set, and proftpd is configured to
# chroot (e.g. DefaultRoot or ), it will use the non-daylight
# savings timezone regardless of whether DST is in effect.
SetEnv TZ :/etc/localtime


QuotaEngine off



Ratios off



# Delay engine reduces impact of the so-called Timing Attack described in
# http://www.securityfocus.com/bid/11430/discuss 


# It is on by default.

DelayEngine on



ControlsEngine off
ControlsMaxClients 2
ControlsLog /var/log/proftpd/controls.log
ControlsInterval 5
ControlsSocket /var/run/proftpd/proftpd.sock



AdminControlsEngine off


#
# Alternative authentication frameworks
#
#Include /etc/proftpd/ldap.conf
#Include /etc/proftpd/sql.conf

#
# This is used for FTPS connections
#
Include /etc/proftpd/tls.conf

#
# This is used for SFTP connections
#
#Include /etc/proftpd/sftp.conf

#
# This is used for other add-on modules
#
#Include /etc/proftpd/dnsbl.conf
#Include /etc/proftpd/geoip.conf
#Include /etc/proftpd/snmp.conf

#
# Useful to keep VirtualHost/VirtualRoot directives separated
#
#Include /etc/proftpd/virtuals.conf

# A basic anonymous 

Re: kodi and gnome-control-center conflict on bullseye

[The Wanderer]

On 2021-08-22 at 10:46, Tristan Miller wrote:

> Dear all,
> 
> On my bullseye system, it doesn't seem to be possible to install both 
> kodi and gnome-control-center as they conflict with each other.  (See 
> below for what happens when I've got kodi installed and then try to 
> install gnome-control-center.)

> # apt install gnome-control-center

> The following packages will be REMOVED:
>gstreamer1.0-libav kodi kodi-bin kodi-inputstream-adaptive 

I don't have either package installed, but if I try to install both in
the same command line, I don't get a failure. As such, I'm guessing this
may just be a dependency-resolver issue.

What happens if you instead run

$ apt install kodi gnome-control-center

? You should either get a success (via different resolution of the
dependencies, which doesn't consider omitting either of the two to be an
acceptable solution) or an error which may help us narrow down the problem.

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

kodi and gnome-control-center conflict on bullseye

[Tristan Miller]

Dear all,

On my bullseye system, it doesn't seem to be possible to install both 
kodi and gnome-control-center as they conflict with each other.  (See 
below for what happens when I've got kodi installed and then try to 
install gnome-control-center.)


Is this a known issue that affects others, or have I somehow borked my 
system configuration?  If the latter, help in diagnosing the problem 
would be appreciated.  In my /etc/apt/sources.list I have only the 
following three lines:


deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb-src http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org bullseye-security main contrib non-free

Regards,
Tristan


# apt install gnome-control-center
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer 
required:
  fonts-noto-hinted fonts-roboto-hinted fonts-roboto-unhinted 
javascript-common kodi-data
  kodi-visualization-shadertoy-data libaribb24-0 libcddb2 libcrossguid0 
libdouble-conversion3 libdvbpsi10 libebml5
  libenca0 libfmt7 libfstrcmp0 libimagequant0 libiso9660-11 libixml10 
libjs-iscroll libjs-jquery libkissfft-float131
  libmad0 libmatroska7 libmd4c0 libmicrohttpd12 libmng1 libmysofa1 
libnorm1 libopenmpt-modplug1 libpgm-5.3-0
  libplacebo72 libpocketsphinx3 libpostproc55 libprotobuf-lite23 
libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5
  libqt5svg5 libqt5widgets5 libqt5x11extras5 librabbitmq4 
libresid-builder0c2a librubberband2 libsdl-image1.2
  libshairplay0 libsidplay2 libspatialaudio0 libsphinxbase3 
libssh-gcrypt-4 libtinyxml2.6.2v5 libupnp13 libva-wayland2
  libvidstab1.1 libvorbisidec1 libwayland-client++0 
libwayland-cursor++0 libwayland-egl++0 libwebm1 libxcb-xinerama0
  libxcb-xinput0 libzimg2 libzmq5 pocketsphinx-en-us python3-olefile 
python3-pil python3-pycryptodome vlc-bin vlc-data

  vlc-plugin-qt vlc-plugin-video-output
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  apg cheese-common gir1.2-malcontent-0 gnome-control-center-data 
gstreamer1.0-plugins-bad libcheese-gtk25 libcheese8
  libcolord-gtk1 libde265-0 libflatpak0 libfluidsynth2 
libgupnp-igd-1.0-4 libinstpatch-1.0-2 libltc11
  libmalcontent-ui-0-0 libmjpegutils-2.1-0 libmms0 libmodplug1 
libmpeg2encpp-2.1-0 libmplex2-2.1-0 libnice10
  libnss-myhostname libofa0 libopenni2-0 libostree-1-1 libsbc1 
libsoundtouch1 libspandsp2 libsrt1.4-gnutls libsrtp2-1
  libvo-aacenc0 libvo-amrwbenc0 libwebrtc-audio-processing1 
libwildmidi2 libzbar0 malcontent malcontent-gui realmd

  timgm6mb-soundfont
Suggested packages:
  libcanberra-gtk-module frei0r-plugins libwildmidi-config 
fluid-soundfont-gm

Recommended packages:
  libcanberra-pulse pulseaudio-module-bluetooth
The following packages will be REMOVED:
  gstreamer1.0-libav kodi kodi-bin kodi-inputstream-adaptive 
kodi-visualization-fishbmc kodi-visualization-pictureit
  kodi-visualization-shadertoy kodi-visualization-spectrum 
kodi-visualization-waveform libavfilter7 libavformat58

  libsrt1-gnutls mplayer vlc vlc-plugin-base
The following NEW packages will be installed:
  apg cheese-common gir1.2-malcontent-0 gnome-control-center 
gnome-control-center-data gstreamer1.0-plugins-bad
  libcheese-gtk25 libcheese8 libcolord-gtk1 libde265-0 libflatpak0 
libfluidsynth2 libgupnp-igd-1.0-4 libinstpatch-1.0-2
  libltc11 libmalcontent-ui-0-0 libmjpegutils-2.1-0 libmms0 libmodplug1 
libmpeg2encpp-2.1-0 libmplex2-2.1-0 libnice10
  libnss-myhostname libofa0 libopenni2-0 libostree-1-1 libsbc1 
libsoundtouch1 libspandsp2 libsrt1.4-gnutls libsrtp2-1
  libvo-aacenc0 libvo-amrwbenc0 libwebrtc-audio-processing1 
libwildmidi2 libzbar0 malcontent malcontent-gui realmd

  timgm6mb-soundfont
0 upgraded, 40 newly installed, 15 to remove and 3 not upgraded.
Need to get 7,418 kB/20.0 MB of archives.
After this operation, 7,643 kB disk space will be freed.
Do you want to continue? [Y/n]


--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Buster to Bullseye upgrade problem

[David Wright]

On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:

> > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > 5047).
> > >Affected packages: texlive-fonts-recommended:amd64 
> > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---

[ … ]

> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I use this 
> by habit from academic writing but perhaps  might be better for this 
> purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared spontaneously.  
> The upgrade stops, and [...] here stands in for etckeeper output, which I 
> removed as noisy.

Both the < … > and [ … ] are fine; it's just that "upgrade
interrupted", in a passive construction, avoids specifying the agent,
which is what we need to know: was it you or APT whodunit.

[ … ]

> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages are 
> removed as part of the upgrade but the config (mods-[enabled]) isn't changed. 
>  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of 
> /etc/apache2/apache2.conf: Syntax error on line 3 of 
> /etc/apache2/mods-enabled/php7.3.load: Cannot load 
> /usr/lib/apache2/modules/libphp7.3.so into server: 
> /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No 
> such file or directory
> Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> 
> Is it normal to have to do this sort of thing after a major upgrade?  If not, 
> could a hiccup here be related to the upgrade breaking?

Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
transition from buster to bullseye, and although APT will look after
upgrading its conffiles, "conffiles" are those configuring the apache
software, not the mods-available/enabled that configure the service.

People who run apache servers may have their own opinions on the
correct procedure. My own would be that you should be sure a
configuration is correct before you run that service, and testing
it is not best done during a major upgrade, but when the dust has
settled.

Cheers,
David.

Re: smart fans

[tomas]

On Sun, Aug 22, 2021 at 04:02:48PM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> > I disagree. The thing poses [1] as a DC motor (2 pins power,
> > one tacho). I don't think you get too much control over RPM
> 
> That's what you get with the 4th wire/pin? A sensor to
> read RPM?

Re-read the Wikipedia I quoted: according to that, that's the
third pin of the three-pin thingie (aka tacho, like bikes have :)
The *fourth* pin is PWM, i.e. speed control.

Debate's up whether you can control a three-pin fan by regulating
its DC voltage (the motherboard/chipset would have to provide
that, of course). Some of us say it can be done, rhkramer says
it has (at least) been done.

> "What you can't measure, you can't control"

...it rather controls you ;-)

I think the tacho originally was important to have a "live signal",
in the times fans were more unreliable. If it gets stuck because
the bushing went bad, software can take action before the CPU goes
in flames. These days things fail more gracefully at several levels.

Cheers
 - t


signature.asc
Description: Digital signature

Re: smart fans

[Thomas Schmitt]

Hi,

Polyna-Maude Racicot-Summerside wrote:
> > Like I already wrote, modifying voltage doesn't change speed of a motor
> > (fan).

to...@tuxteam.de wrote:
> I disagree. [...]
> I have no idea what the motherboard/fan manufacturers actually do, though.

Voltage reduction is a tradional method to curb overly eager DC fans. I have
seen successful use of resistor adapters between fan cable and mainboard.

A quick search with "fan voltage control" yields
  https://en.wikipedia.org/wiki/Computer_fan_control#Linear_voltage_regulation
and others which state that 2-pin and 3-pin are only controllable via
voltage reduction whereas 4-pin indicate the capability for the competing
method of Pulse-Width Modulation (PWM).

Resistors can be seen at
  https://www.amazon.com/computer-fan-resistor/s?k=computer+fan+resistor


rhkra...@gmail.com wrote meanwhile:
> A voltage controlled DC (computer fan) motor can be controlled /
> regulated down to about 40% of full rated speed (depending on the motor).

That's what i read in the web and what i witnessed as effect of resistors on
dumb fans.


Have a nice day :)

Thomas

Re: smart fans

[The Wanderer]

On 2021-08-22 at 10:00, Emanuel Berg wrote:

> Polyna-Maude Racicot-Summerside wrote:
> 
>>> Or what's this about fan-divisors?
>>> 
>>>   You may also need to increase the fan divisors.
>>>   See doc/fan-divisors for more information.
>>> 
>> See *doc/fan-divisors* for more information.
> 
> Yeah, but is that supposed to be a path? Or button? What does
> it mean?

It's clearly a reference to a path in the source, or native
non-Debian-packaged build, tree of some relevant package.

With that as the basis:

$ dlocate fan-divisors
lm-sensors: /usr/share/doc/lm-sensors/fan-divisors.gz

So apparently this is part of lm-sensors, and in order to adhere to the
Debian-packaging filesystem layout, the packagers move its doc/
directory to be /usr/share/doc/lm-sensors/.

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

[rhkramer]

On Sunday, August 22, 2021 09:41:59 AM to...@tuxteam.de wrote:
> On Sun, Aug 22, 2021 at 09:03:51AM -0400, Polyna-Maude Racicot-Summerside
> > Like I already wrote, modifying voltage doesn't change speed of a motor
> > (fan).
> 
> I disagree. The thing poses [1] as a DC motor (2 pins power, one tacho).
> I don't think you get too much control over RPM, but putting the tacho
> in the control loop should be possible.

+1.  A voltage controlled DC (computer fan) motor can be controlled / 
regulated down to about 40% of full rated speed (depending on the motor).  A 
PWM (computer fan) motor can be controlled down to about 20% of full rated 
speed.

> I have no idea what the motherboard/fan manufacturers actually do, though.

I know that at least some motherboards (perhaps only older ones?) controlled 
fan speed via voltage control.

> [1] I'm nearly certain it's a BLDC in disguise, with some electronic goo.

Re: smart fans

[Emanuel Berg]

didier gaumet wrote:

>> Okay, but is that even possible?
>
> Yes. If you want more details, read the previous link to an
> explanation of differences between 3 and 4 pins connectors:
> there are pictures to illustrate different possible
> combinations between 3 or 4 pins fan connectors and 3 or 4
> pins motherboard connectors
>
>> How? In the UEFI?
>
> Yes, refer to the 3.2.3 section of your manual

OK, king. Or roi maybe...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Debian 10.7 no me actualiza.

[fernando sainz]

El sáb, 21 ago 2021 a las 18:45, Aristobulo Pinzon
() escribió:
>
> Buenas Tardes apreciados colaboradores.
> Debian 10.7 no me actualiza. Me da estos mensajes y no logro saber que
> debo hacer, si cambiar los repositorios del sources.list  y colocar
> que? para seguir con buster uos meses más.
> muchas gracias por su colaboración.
>
> --
> Que es Dios?
> Dios es la inteligencia suprema, causa primera de todas las cosas.
>


No es bueno tener en apt la versión nombrada como stable, porque en
los momentos de cambio podría darte problemas.
Durante la transición hay algún momento que se paraliza el sistema de
actualización.
Mi recomendación: Cambia stable por buster en tu sources.list.
Actualiza al máximo.
Y si quieres actualizar a la versión 11, primero lee la documentación
de la migración.

S2.

Re: smart fans

[tomas]

On Sun, Aug 22, 2021 at 09:03:51AM -0400, Polyna-Maude Racicot-Summerside wrote:

[...]

> Like I already wrote, modifying voltage doesn't change speed of a motor
> (fan).

I disagree. The thing poses [1] as a DC motor (2 pins power, one tacho).
I don't think you get too much control over RPM, but putting the tacho
in the control loop should be possible.

I have no idea what the motherboard/fan manufacturers actually do, though.

Cheers

[1] I'm nearly certain it's a BLDC in disguise, with some electronic goo.

 - t


signature.asc
Description: Digital signature

Re: smart fans

[Emanuel Berg]

didier gaumet wrote:

> Here is your motherboard user manual [...]
> https://rog.asus.com/us/motherboards/rog-strix/rog-strix-b450-f-gaming-model/helpdesk_manual
> Look at 3.2.3 section for fan control

OK!

> I could be entirely wrong but what I would imagine is that
> fan control is by default managed directly by the UEFI of
> your motherboard, not by the OS.

Yes.

> But that to be really efficient il would require 4-pins fans
> to have been mounted.

Okay, but is that even possible?

> For 3-pins fans in your situation, I would suggest trying to
> delegate fan management from the UEFI to the OS (Linux) by
> (possibly setting the fan profile to "manual") and the mode
> from "PWM" to "DC"

How? In the UEFI?

-- 
underground experts united
https://dataswamp.org/~incal

Re: FOSS "BIOS" (UEFI) (was: Re: smart fans)

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 2:28 a.m., Emanuel Berg wrote:
> Reco wrote:
> 
>>> This made me think, is there a FOSS "BIOS" (UEFI) that you
>>> can install/flash to replace the manufacturer's?
>>
>> Coreboot is what you're thinking of. Supported motherboard's
>> list is extremely limited though.
> 
> There is a grub-coreboot package, is that it?
> 
> And how do you know if its supported?
Google "Coreboot supported motherboard" ?

And going to see this page as the first choice

https://coreboot.org/status/board-status.html


> 
> I think I have a
> 
>   Asus ROG Strix B450-F Gaming
> 
> motherboard.
> 
> https://dataswamp.org/~incal/ebchw/COMPUTER
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 5:49 a.m., Emanuel Berg wrote:
> didier gaumet wrote:
> 
>>> Okay, but is that even possible?
>>
>> Yes. If you want more details, read the previous link to an
>> explanation of differences between 3 and 4 pins connectors:
>> there are pictures to illustrate different possible
>> combinations between 3 or 4 pins fan connectors and 3 or 4
>> pins motherboard connectors
>>
>>> How? In the UEFI?
>>
>> Yes, refer to the 3.2.3 section of your manual
> 
> OK, king. Or roi maybe...
> 
??

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 5:27 a.m., Emanuel Berg wrote:
> didier gaumet wrote:
> 
>> Here is your motherboard user manual [...]
>> https://rog.asus.com/us/motherboards/rog-strix/rog-strix-b450-f-gaming-model/helpdesk_manual
>> Look at 3.2.3 section for fan control
> 
> OK!
> 
>> I could be entirely wrong but what I would imagine is that
>> fan control is by default managed directly by the UEFI of
>> your motherboard, not by the OS.
> 
> Yes.
> 
>> But that to be really efficient il would require 4-pins fans
>> to have been mounted.
> 
> Okay, but is that even possible?
What is possible ?
4 pins fans ?

Yes it is possible (4 wire fans) and you have received many links on the
subject.

I've sent you link and dider sent you the same ones.
> 
>> For 3-pins fans in your situation, I would suggest trying to
>> delegate fan management from the UEFI to the OS (Linux) by
>> (possibly setting the fan profile to "manual") and the mode
>> from "PWM" to "DC"
> 
> How? In the UEFI?
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 4:39 a.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>> The significant difference in practice is that 4-pin fans
>> allow for RPM to change based on the need for cooling
>> temperature, this reduces noise and power consumption.
>> While 3-pin can control the voltage, but the voltage can't
>> turn to change the fan RPM at all and accurate as much as 4
>> pin fans.
> 
> OK, but since there are temperature readings from the GPU and
> the CPU _and_ 3-pin fans doesn't that mean it should be able
> to control (the voltage) them based on the temperature?
> 
Like I already wrote, modifying voltage doesn't change speed of a motor
(fan).
> 4-pin fans wouldn't be possible because of the motherboard
> sockets, I think, which are also 3-pin.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Polyna-Maude Racicot-Summerside]

On 2021-08-22 4:36 a.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>> I think you got all the information at hand now.
> 
> pwmconfig fails but the error message doesn't add up.
> 
> Or what's this about fan-divisors?
> 
>   You may also need to increase the fan divisors.
>   See doc/fan-divisors for more information.
> 
See *doc/fan-divisors* for more information.

Maybe going out and reading this one ?
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: smart fans

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

> The significant difference in practice is that 4-pin fans
> allow for RPM to change based on the need for cooling
> temperature, this reduces noise and power consumption.
> While 3-pin can control the voltage, but the voltage can't
> turn to change the fan RPM at all and accurate as much as 4
> pin fans.

OK, but since there are temperature readings from the GPU and
the CPU _and_ 3-pin fans doesn't that mean it should be able
to control (the voltage) them based on the temperature?

4-pin fans wouldn't be possible because of the motherboard
sockets, I think, which are also 3-pin.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

> You can only throttle it when you go into a close to stop.
> But this is really ineffective way of trying to control the
> speed. You'll be running at at most a hundred rpm.

But then why doesn't pwmconfig ask for 4-pin fans? It asks for
3-pin fans so while ineffective it's something people still
care to do.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

> I think you got all the information at hand now.

pwmconfig fails but the error message doesn't add up.

Or what's this about fan-divisors?

  You may also need to increase the fan divisors.
  See doc/fan-divisors for more information.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

tomas wrote:

> Whether three-pin fans can be even be RPM controlled is an
> open question (the DC feed could be modulated, I guess, but
> I don't know whether it is actually done).

But then wouldn't pwmconfig ask for something other than
3-pin, perhaps something I don't have?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 13:18, Gareth Evans  wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > On Fri 20 Aug 2021, at 04:45, David Wright  
> > > wrote:
> > > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > 
> > > $ apt policy pitivi
> > > pitivi:
> > >   Installed: 0.999-1+b1
> > >   Candidate: 0.999-1+b1
> > >   Version table:
> > >  *** 0.999-1+b1 500
> > > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > > 100 /var/lib/dpkg/status
> > > 
> > > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > > 
> > > [Bullseye] 
> > > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > > 
> > > 
> > > The first upgrade interruption issue (repeated here for clarity):
> > > 
> > > --
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > dpkg: error processing archive 
> > > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> > >  (--unpack):
> > >  trying to overwrite 
> > > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > > which is also in package pitivi 0.999-1+b1
> > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > > --
> > > 
> > > appears to be a file conflict, per 
> > > 
> > > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > > 
> > > which includes that "File conflicts should not occur if you upgrade from 
> > > a “pure” buster system..."
> > > 
> > > So I would like to know if apt is not handling this properly, or if the 
> > > scenario of a file changing packages (see David's previous email) is an 
> > > expected exception to the (sort of) rule.
> > 
> 
> Hi David,
> 
> > As Sven posted, it looks as if #965007 is the cause. A snag is
> > that, because the bug has been closed, it no longer shows up on
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> > Moral: for major upgrades, always set "Archived and Unarchived"
> > on https://www.debian.org/Bugs/ because these sorts of bug are
> > likely to have been fixed by the time unstable→stable arrives.
> > 
> > But the workaround is to recall reading (!) § 4.5.4 in the Release
> > Notes, and force things as shown there.
> 
> I did see that but had already managed to make progress with apt 
> install --fix-broken before twigging a file conflict (which is obvious 
> once realised!)
> 
> > 
> > > There is also no explanation in term.log, syslog or dpkg.log for the 
> > > second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 
> > > 5047).
> > >Affected packages: texlive-fonts-recommended:amd64 
> > > texlive-lang-greek:amd64 texlive-latex-base:amd64 
> > > texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> > > texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---
> > > 
> > > which occurs even if pitivi is removed before upgrading, and the warning 
> > > doesn't appear in term.log either.
> > > 
> > > If anyone can shed further light, I would be interested, but it's not 
> > > ultimately a roadblock to upgrading so possibly not worth worrying about.
> > 
> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I 
> use this by habit from academic writing but perhaps  might be 
> better for this purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared 
> spontaneously.  The upgrade stops, and [...] here stands in for 
> etckeeper output, which I removed as noisy.
> 
> > 
> > ISTR that history.log records intent, not achievement, whereas
> > term.log can obviously /only/ log achievement, so a comparison
> > of their two lists of packages for the interrupted step might give
> > a clue, perhaps a more fruitful one than just the list of Affected
> > packages quoted above.
> 
> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages 
> are removed as part of the upgrade but the config (mods-available) 
> isn't changed.  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP 

Re: FOSS "BIOS" (UEFI) (was: Re: smart fans)

[Emanuel Berg]

BIOS seems to be:

$ sudo dmidecode -t bios
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.

Handle 0x, DMI type 0, 26 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 2801
Release Date: 09/18/2019
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
APM is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.13

Handle 0x0031, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 9
en|US|iso8859-1
fr|FR|iso8859-1
zh|TW|unicode
ja|JP|unicode
de|DE|iso8859-1
es|ES|iso8859-1
ru|RU|iso8859-5
ko|KR|unicode

Currently Installed Language: en|US|iso8859-1

-- 
underground experts united
https://dataswamp.org/~incal

Re: Buster to Bullseye upgrade problem

[Gareth Evans]

On Sun 22 Aug 2021, at 05:36, David Wright  wrote:
> On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > On Fri 20 Aug 2021, at 04:45, David Wright  wrote:
> > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> 
> > $ apt policy pitivi
> > pitivi:
> >   Installed: 0.999-1+b1
> >   Candidate: 0.999-1+b1
> >   Version table:
> >  *** 0.999-1+b1 500
> > 500 http://deb.debian.org/debian buster/main amd64 Packages
> > 100 /var/lib/dpkg/status
> > 
> > So pitivi 0.999 as installed is a Buster package, and gir* is installed 
> > during the upgrade as a dependency of Bullseye's newer pitivi version.
> > 
> > [Bullseye] 
> > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > 
> > 
> > The first upgrade interruption issue (repeated here for clarity):
> > 
> > --
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > dpkg: error processing archive 
> > /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> >  (--unpack):
> >  trying to overwrite 
> > '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', 
> > which is also in package pitivi 0.999-1+b1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > --
> > 
> > appears to be a file conflict, per 
> > 
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > 
> > which includes that "File conflicts should not occur if you upgrade from a 
> > “pure” buster system..."
> > 
> > So I would like to know if apt is not handling this properly, or if the 
> > scenario of a file changing packages (see David's previous email) is an 
> > expected exception to the (sort of) rule.
> 

Hi David,

> As Sven posted, it looks as if #965007 is the cause. A snag is
> that, because the bug has been closed, it no longer shows up on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> Moral: for major upgrades, always set "Archived and Unarchived"
> on https://www.debian.org/Bugs/ because these sorts of bug are
> likely to have been fixed by the time unstable→stable arrives.
> 
> But the workaround is to recall reading (!) § 4.5.4 in the Release
> Notes, and force things as shown there.

I did see that but had already managed to make progress with apt install 
--fix-broken before twigging a file conflict (which is obvious once realised!)

> 
> > There is also no explanation in term.log, syslog or dpkg.log for the second 
> > interruption:
> > 
> > --
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > [upgrade interrupted...]
> > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> >Affected packages: texlive-fonts-recommended:amd64 
> > texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 
> > texlive-latex-recommended:amd64 texlive-pictures:amd64 
> > texlive-plain-generic:amd64 texlive-science:amd64
> > ---
> > 
> > which occurs even if pitivi is removed before upgrading, and the warning 
> > doesn't appear in term.log either.
> > 
> > If anyone can shed further light, I would be interested, but it's not 
> > ultimately a roadblock to upgrading so possibly not worth worrying about.
> 
> I'm no help here, as I've never seen output like that,
> neither the "[ … ]", nor the "W: APT had planned …".
> Is that output, with [upgrade interrupted...], a verbatim
> copy/paste? Did this message appear spontaneously, or
> because you yourself interrupted the process?

"[...]" was just my way of showing output until this point has not been 
included in the paste, or that the paste includes gaps in output.  I use this 
by habit from academic writing but perhaps  might be better for this 
purpose?  

The interrupt and following "W: APT had planned..." appeared spontaneously.  
The upgrade stops, and [...] here stands in for etckeeper output, which I 
removed as noisy.

> 
> ISTR that history.log records intent, not achievement, whereas
> term.log can obviously /only/ log achievement, so a comparison
> of their two lists of packages for the interrupted step might give
> a clue, perhaps a more fruitful one than just the list of Affected
> packages quoted above.

I have just noticed that the logged action after which it trips up:

Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

is related to what may be another problem of sorts.  php7.3 packages are 
removed as part of the upgrade but the config (mods-available) isn't changed.  
Apache2 won't start after upgrading until I

a2dismod *php*7.3*

>From /var/log/syslog: 
Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of 
/etc/apache2/apache2.conf: Syntax error on line 3 of 
/etc/apache2/mods-enabled/php7.3.load: Cannot load 
/usr/lib/apache2/modules/libphp7.3.so into server: 
/usr/lib/apache2/modules/libphp7.3.so: cannot open shared 

Re: smart fans

[Emanuel Berg]

Polyna-Maude Racicot-Summerside wrote:

>>> This would be the first thing to clear. If your hardware
>>> doesn't play along... game over :-/
>> 
>> Yeah, but if so, why doesn't it?
>
> Why doesn't it? Because it is not implemented, because the
> builder of your motherboard made this choice...
>
> A two wire fan can't control the speed of the fan properly.
> It needs a three wire fan.

The fans have 3 wires.

-- 
underground experts united
https://dataswamp.org/~incal

Re: smart fans

[Emanuel Berg]

tomas wrote:

>> There are no working fan sensors, all readings are 0.
>> Make sure you have a 3-wire fan connected.
>   ^^
> Well?

I'm sure!

> This would be the first thing to clear. If your hardware
> doesn't play along... game over :-/

Yeah, but if so, why doesn't it?

-- 
underground experts united
https://dataswamp.org/~incal