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

2021-08-21 Thread Reco
Hi.

On Sun, Aug 22, 2021 at 07:25:34AM +0200, Emanuel Berg wrote:
> > There is fancontrol (pwdconfig(1)) but I don't get it to
> > work ... The BIOS (UEFI) can maybe be used but I don't
> > have/use a mouse and I dislike the UI ...
> >
> > $ sudo dmidecode [...]
> 
> 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.

Reco



Re: You are required to change your password immediately (administrator enforced).

2021-08-21 Thread John Crawley

On 18/08/2021 21:16, Harald Dunkel wrote:

...sid becomes the next release in 2 years


Sid is always sid.
Testing (now Bookworm) will become stable in ~2 years.

--
John



Re: smart fans

2021-08-21 Thread Emanuel Berg
Polyna-Maude Racicot-Summerside wrote:

> Maybe you are playing in something you don't really master
> the ins and out of the consequence of what you may do.
> And this is proven by the simple sentence that *hibernation
> cut Internet*. Unless you have a good reason to risk frying
> your CPU then leave it alone.

Oh, I meant to post this to the Debian user ML, not
alt.os.linux ...

> Or buy a system that doesn't use a fan, like the low power,
> low thermal emission CPU used in laptop with only passive
> cooling (heatsink).

I had an RPi3 once and it was completely quiet, at least to
the human ear - no fan. But as you see (the HDD and projector)
while I used it, the fans were on anyway. But for some reason
when you use a computer, that noise don't bug you ...

  https://dataswamp.org/~incal/work-photos/rpi.jpg

So there is no way of disabling the 120/140 mm fans that are
connected to the motherboard from software? Maybe prolong the
cables and have little physical switches (to cut power), if
such things are marketed ...

Because this

  #! /bin/zsh
  # 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"
  }

outputs the CPU and GPU temperature, one could downgrade the
fans gradually and see what good they do - especially when one
isn't using the computer ...

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



Re: Buster to Bullseye upgrade problem

2021-08-21 Thread David Wright
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.

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.

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

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.

Cheers,
David.



Re: Watching a directory, was Re: how would you do this?

2021-08-21 Thread David Wright
On Sat 21 Aug 2021 at 19:17:31 (+0530), didar wrote:
> On Thu, Aug 19, 2021 at 10:45:44PM -0500, David Wright wrote:
> > On Thu 19 Aug 2021 at 08:01:24 (-0400), songbird wrote:
> > > David Wright wrote:
> > > > On Wed 18 Aug 2021 at 20:55:12 (-0400), songbird wrote:
> > > >>   let's suppose you have a directory where there are
> > > >> various scripts, libraries, programs, data, etc.
> > > >> 
> > > >>   you want to know exactly which other scripts, libraries,
> > > >> etc. use them and to log each caller to know the name so
> > > >> it can be tracked down (location would be nice too, but 
> > > >> that could be found later if needed).
> > > >> 
> > > >>   i don't need to keep the information in a database as
> > > >> just having the log file will be enough.
> > > >> 
> > > >>   how would you do this?
> > > >> 
> > > >>   this isn't a homework assignment i'm just curious how
> > > >> easy or hard this would be to accomplish.
> > > >
> > > > Easy.
> > > >
> > > > $ inotifywait -m -e access --timefmt "%F %T" --format "%T %f" 
> > > > the-directory/
> > > >
> > > > To try it, just type in that line, using a sensible directory name.
> > > > (The package name to install first is inotify-tools.)
> > > >
> > > > Change the formats to taste. Pipe into a   while IFS=$'\n' read 
> > > > Filename ; do
> > > > loop if you want to do something with the output. See:
> > > >
> > > >   https://lists.debian.org/debian-user/2021/03/msg01494.html
> > > >
> > > > for a real script (waiting on close-writeable-file, rather than just
> > > > access) that I use a lot for stealing files from FireFox's cache
> > > > (~/.cache/mozilla/firefox/foo.bar.profile/cache2/entries/).
> > > 
> > >   thanks!  very interesting!  :)
> > > 
> > >   thank you to others who replied also.  :)
> > > 
> > >   i was wondering if there was a general tool available as on
> > > debian-devel they are talking about usr-merge and if there was a
> > > simple way to find out who's using /bin and such instead of 
> > > /usr/bin,
> > 
> > No, that's a different problem. My solution addresses a directory,
> > hence the change in Subject line. You'd have to dive deeper into
> > inotify and inotify_add_watch, to see whether you can specify the
> > inode of the /bin symlink separately from that for /usr/bin.
> > 
> > $ ls -Glidg /bin /usr/bin
> > 12 lrwxrwxrwx 1 7 Apr  3  2020 /bin -> usr/bin
> > 261634 drwxr-xr-x 2 69632 Aug 11 19:10 /usr/bin
> > $ 
> > 

To be more explicit, my understanding of symlinks is that they're
a property of the filesystem, and so are resolved in the kernel,
likely somewhere in fs/ext{2,4}. So nothing in userspace is likely
to be aware of whether a filename was referenced through a symlink.

> There is an "auditd" package - a Red Hat origin tool/subsystem. It's available
> on Bullseye, but, I have not tried it recently. It might be what you are 
> looking
> for.

I would revise my "Easy", above, to Hard. You would have to write
rules to trigger logging just the right events in the kernel, and then
write a program to wade through the log, which will be pouring in from
all the processes triggering those events. Plus deal with the slowdown
from a heavy overhead if the rules aren't adequately focussed.

When the OP replied to my first post, I ran my one-liner on /bin,
and then tried running a few binaries by invoking them through /bin
and /usr/bin (which, of course, didn't reveal anything interesting).
However, I could only do this for ~50 seconds of each minute because
my crontab would spew a couple of screenfuls every time it triggered.

Let us know how it goes, should you attempt it.

Cheers,
David.



smart fans

2021-08-21 Thread Emanuel Berg
o/

Is there a way to have "smart fans" that only go as fast
as needed?

Or, lacking that, is there a way to manually switch them off
when one isn't using the computer?

I do

  $ sudo hibernate -v 0

but that seems to kill the Internet connection as well :(

I managed to output the GPU/CPU temperature like this

  #! /bin/zsh
  # 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 temp=temperature

Perhaps one should leave those on?

But I also have, connected to the motherboard

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

Can I reduce their speeds/turn them off from software?

TIA

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



Re: smart fans

2021-08-21 Thread Polyna-Maude Racicot-Summerside


On 2021-08-21 9:01 p.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>> Maybe you are playing in something you don't really master
>> the ins and out of the consequence of what you may do.
>> And this is proven by the simple sentence that *hibernation
>> cut Internet*. Unless you have a good reason to risk frying
>> your CPU then leave it alone.
> 
> Oh, I meant to post this to the Debian user ML, not
> alt.os.linux ...
> 
>> Or buy a system that doesn't use a fan, like the low power,
>> low thermal emission CPU used in laptop with only passive
>> cooling (heatsink).
> 
> I had an RPi3 once and it was completely quiet, at least to
> the human ear - no fan. But as you see (the HDD and projector)
> while I used it, the fans were on anyway. But for some reason
> when you use a computer, that noise don't bug you ...
I'll add. the CPU in a Raspberry Pi is meant to be used in embedded
application and other stuff like a cellular phone for example. Those are
ARM type processor. Totally different from a x86/x64 based processor.

ARM are CPU used in cell phone and the latest Mac that runs without a
heat sink.

Nothing compared to a desktop PC.

And even then, there's some Raspberry Pi with a fan.

https://www.raspberrypi.org/blog/new-raspberry-pi-4-case-fan/

So even the RPi if you want more power, a fan would help. Because when
temperature rise, the CPU clock will lower, something specific to ARM CPU.

With AMD/Intel x86/x64 CPU, it's more that it won't allow to upscale the
clock if the temperature is too high inside the CPU.

> 
>   https://dataswamp.org/~incal/work-photos/rpi.jpg
> 
> So there is no way of disabling the 120/140 mm fans that are
> connected to the motherboard from software? Maybe prolong the
> cables and have little physical switches (to cut power), if
> such things are marketed ...
> 
> Because this
> 
>   #! /bin/zsh
>   # 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"
>   }
> 
> outputs the CPU and GPU temperature, one could downgrade the
> fans gradually and see what good they do - especially when one
> isn't using the computer ...
> 

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



OpenPGP_signature
Description: OpenPGP digital signature


Re: smart fans

2021-08-21 Thread Polyna-Maude Racicot-Summerside


On 2021-08-21 9:01 p.m., Emanuel Berg wrote:
> Polyna-Maude Racicot-Summerside wrote:
> 
>> Maybe you are playing in something you don't really master
>> the ins and out of the consequence of what you may do.
>> And this is proven by the simple sentence that *hibernation
>> cut Internet*. Unless you have a good reason to risk frying
>> your CPU then leave it alone.
> 
> Oh, I meant to post this to the Debian user ML, not
> alt.os.linux ...
> 
How's that supposed to be relevant as a comment ?

You did post it to Debian mailing list. Did I suggest you didn't ?

>> Or buy a system that doesn't use a fan, like the low power,
>> low thermal emission CPU used in laptop with only passive
>> cooling (heatsink).
> 
> I had an RPi3 once and it was completely quiet, at least to
> the human ear - no fan. But as you see (the HDD and projector)
> while I used it, the fans were on anyway. But for some reason
> when you use a computer, that noise don't bug you ...
> 
>   https://dataswamp.org/~incal/work-photos/rpi.jpg
> 
You are comparing different things with no link between each other.

One (RPi) is a CPU meant for using mostly a heat sink and running at low
power, being able to modulate the speed based on load and using low
power consumption.

And the other one CPU (Intel/AMD made for desktop) is a CPU meant to be
cooled with a fan and produce much more thermal power per watt.

You compare something running with a USB power supply versus something
requiring hundred of watts of power.

Raspberry Pi power consumption

Idle260 mA (*1.4 W*)
ab -n 100 -c 10 (uncached)  480 mA (*2.4 W*)
400% CPU load (stress --cpu 4)  730 mA (*3.7 W*)

https://www.pidramble.com/wiki/benchmarks/power-consumption

*versus*

Core i7-860 Lynnfield (45 nm)   2.8 GHz *95 W*
Core i7-860SLynnfield (45 nm)   2.533 GHz   *82 W*
Core i7-870 Lynnfield (45 nm)   2.933 GHz   *95 W*
Core i7-875KLynnfield (45 nm)   2.93 GHz*95 W*
Core i7-880 Lynnfield (45 nm)   3.067 GHz   *95 W*
Core i7-920 Bloomfield (45 nm)  2.667 GHz   *130 W*
Core i7-930 Bloomfield (45 nm)  2.8 GHz *130 W*
Core i7-940 Bloomfield (45 nm)  2.933 GHz   *130 W*

https://en.wikipedia.org/wiki/List_of_CPU_power_dissipation_figures

*versus*

Intel Atom is a series of Ultra Low Voltage processors made for
ultraportables called "netbooks" and ultra small form factor desktops
called "nettops". Because of their low clock speed, Intel Atom CPUs are
highly energy efficient. Atom's microarchitecture is unique from other
Intel CPUs. Certain Atom CPUs have Hyper-Threading.

Atom 230Diamondville (45 nm)1.6 GHz *4 W*
Atom 330 (Dual-Core)Diamondville (45 nm)1.6 GHz *8 W*
Atom N270   Diamondville (45 nm)1.6 GHz *2.5 W*
Atom N280   Diamondville (45 nm)1.67 GHz*2.5 W*
Atom D410   Pineview (45 nm)1.66 GHz*10 W*
Atom D510 (Dual-Core)   Pineview (45 nm)1.66 GHz*13 W*
Atom D525 (Dual-Core)   Pineview (45 nm)1.8 GHz *13 W*

*versus*

Laptop i5 (with a fan + heat sink)

Core i5-6500T   Skylake (14 nm) 2.5 GHz [Turbo 3.1 GHz] *35 W*
Core i5-6300HQ  Skylake (14 nm) 2.3 GHz [Turbo 3.2 GHz] *45 W*
Core i5-6300HQ  Skylake (14 nm) 2.3 GHz [Turbo 3.2 GHz] *45 W*
Core i5-6350HQ  Skylake (14 nm) 2.3 GHz [Turbo 3.2 GHz] *45 W*
Core i5-6440HQ  Skylake (14 nm) 2.6 GHz [Turbo 3.5 GHz] *45 W*
Core i5-6600T   Skylake (14 nm) 2.7 GHz [Turbo 3.5 GHz] *35 W*

> So there is no way of disabling the 120/140 mm fans that are
> connected to the motherboard from software? Maybe prolong the
> cables and have little physical switches (to cut power), if
> such things are marketed ...

The speed of your fan are set according to a thermal sensor.

If they are really loud than maybe either they are dirty or the thermal
sensor could be failing and this would make them run at full power all
the time. Other than this, they are happy as they are.

They sell desktop computer built using laptop CPU if you want something
silent. But those are pretty limited as a matter of CPU power because
CPU power means using watt of power to drive it. And those watts have to
go somewhere and this is called heat.

Maybe there's a reason why there's a hardware fan and it can't be turned
off. And that there's some safety that prevent you from frying your
system. Don't you think ? Or is it simply that you believe that we are
mostly just enjoying having a fan in the PC ?

Your computer doesn't produce nothing as mechanical work. All the energy
is converted into heat, it's somewhat only a really non efficient
heater. Energy doesn't get lost, if it's not producing mechanical work
then it means it's getting converted to heat (and some to light for the
blinking light). Calculation or whatever else is done (it's all
calculation at basic level) doesn't exist in physics, that's only
electricity running thru tiny wire and producing heat thru resistivity.

That's called "Ohm Law", the 

Re: smart fans

2021-08-21 Thread Polyna-Maude Racicot-Summerside
Hi,

On 2021-08-21 7:53 p.m., Emanuel Berg wrote:
> o/
> 
> Is there a way to have "smart fans" that only go as fast
> as needed?
> 
Fans are already going " as needed" if your system supports it.
> Or, lacking that, is there a way to manually switch them off
> when one isn't using the computer?
> 
It's not because you are not using the computer that it means that it
doesn't use power (and produce heat), hence why the fans work even if
your computer are idle.

> I do
> 
>   $ sudo hibernate -v 0
> 
> but that seems to kill the Internet connection as well :(
> 
Do you know what hibernate means ?

https://en.wikipedia.org/wiki/Hibernation_(computing)

Hibernation (also known as suspend to disk, or Safe Sleep on Macintosh
computers) in computing is powering down a computer while retaining its
state. When hibernation begins, the computer saves the contents of its
random access memory (RAM) to a hard disk or other non-volatile storage.

So yes it does cut your Internet connection.

> I managed to output the GPU/CPU temperature like this
> 
>   #! /bin/zsh
>   # 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 temp=temperature
> 
> Perhaps one should leave those on?
> 
> But I also have, connected to the motherboard
> 
>   fan front 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
>   
> 
> Can I reduce their speeds/turn them off from software?
> 
It wouldn't be a good choice to turn off the fans as you'll be causing
your CPU temperature to rise and this could damage it. Even if it would
be possible, something that I have doubt. As there's some self
protection enabled in the management system.

Maybe you are playing in something you don't really master the ins and
out of the consequence of what you may do. And this is proven by the
simple sentence that *hibernation cut Internet*. Unless you have a good
reason to risk frying your CPU then leave it alone.

Or buy a system that doesn't use a fan, like the low power, low thermal
emission CPU used in laptop with only passive cooling (heatsink).

> TIA
> 

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



OpenPGP_signature
Description: OpenPGP digital signature


Re: Debian 11 installer crashed and reboot

2021-08-21 Thread Chuck Zmudzinski

On 8/21/2021 5:52 AM, Thomas Schmitt wrote:

Hi,

there might be an easier way (still depending on whether such simple
file replacements are tolerated by the booting system):

   # Choose the desired new files
   new_kernel=...path.to.desired.new.kernel.in.some.mounted.filesystem...
   new_initrd=...path.to.desired.new.initrd.in.some.mounted.filesystem...

   # Choose the files in the ISO to be replaced by the new files.
   # The ISO needs not to be mounted. (Better it should not be mounted.)
   # Naively, i assume that it's about these two:
   old_kernel=/install.amd/xen/vmlinuz
   old_initrd=/install.amd/xen/initrd.gz

   # Copy netinst ISO to playground ISO
   cp debian-11.0.0-amd64-netinst.iso test.iso

   # Use xorriso multi-session to override the undesired files
   xorriso -dev test.iso \
   -boot_image any keep \
   -map "$new_kernel" "$old_kernel" \
   -map "$new_initrd" "$old_initrd"

This will result in a quite short run of xorriso, which will report
something like

   ISO image produced: 8108 sectors
   Written to medium : 8288 sectors at LBA 193024
   Writing to 'test.iso' completed successfully.

(The numbers 8108 and 8288 are result of the sizes of the two dummy files
which i used as $new_kernel #and new_initrd. Yours will be substantially
larger due to the typical size of an initrd.)

Inspection of the boot equipment of test.iso shows no differences,
except the new storage position of the El Torito boot catalog and the
enlarged ISO image size.

When mounted by Linux, the paths
   /mnt/iso/install.amd/xen/vmlinuz
   /mnt/iso/install.amd/xen/initrd.gz
lead to the content of $new_kernel and $new_initrd.

Then it depends on the inner doings of boot loader and starting system,
whether this perky change is tolerated.


Have a nice day :)

Thomas



Hi Thomas,

Thank you for these tips. I will use them to try to get a bullseye
Debian installer ISO working in a Xen HVM DomU next week
when I have some spare time and post the results here.

All the best,

Chuck



Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM

2021-08-21 Thread Polyna-Maude Racicot-Summerside


On 2021-08-21 3:03 p.m., piorunz wrote:
> On 21/08/2021 19:38, Mislav Jurić wrote:
> 
>> I have a bug related to Debian 11 (codename Bullseye). I tried to report
>> it using /*reportbug*/, but /*reportbug*/ led me to this email address.
>>
>> I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that
>> when I close my laptop screen for the 5th or 6th time, my laptop doesn't
>> suspend properly. *Again, this issue  doesn't happen every time. It
>> happens after I close and then re-open the laptop screen for the 5th or
>> 6th time in a row.
>>
>> I am using NVIDIA drivers and CUDA for Debian 11 which I obtained
>> following instructions from this link
>> . I am also using the
>> Atheros firmware package, as well as some other non-driver related
>> packages.
Some *other non-driver related packages* this could hardly be more vague.

The more information you give, the more information you'll have chance
to get help from people on this mailing list.

Are you using the plain install of Debian 11 ?
Have you made some configuration changes regarding hibernation and power
management ?
What what does *does not suspend properly* is supposed to mean ?
It may be clear in your own mind but for everyone else it could mean
many things. For example :
Does not suspend at all
It only turn off the display but does not suspend the computer itself.
The computer suspend but doesn't resume properly.
The system start to suspend but crash doing so.
The system suspend properly but crash waking up.
The system suspend properly but wake up as if it was turned off.
The system start to suspend but goes into a unknown state...

etc.

Also your computer may have many configurations, which one you have ?

Maybe installing hwinfo package and sending the dump of *hwinfo -all*
here could help. You can use *apt-get install hwinfo* and after use the
following command in a terminal *hwinfo > hwinfo.txt* then send the
content of *hwinfo.txt* (for example opening in a text editor and
copying into a message).

> 
> NVIDIA drivers are closed source and proprietary. If they are cause of
> this problem, Debian or kernel developers might not be able to help you.
> 
> Try to uninstall NVIDIA drivers and use nouveau drivers for a few days.
> See if you can reproduce this problem on nouveau. Please note that
> nouveau are very basic and 3D acceleration or other things may not work
> at all.
> Also when you report a problem, even here, it would be useful to include
> your hardware specification and cuts from dmesg or other logs showing
> this problem, maybe someone will be more able to help after seeing
> specific details, not only vague description of the problem.
> 
> -- 
> 
> With kindest regards, piorunz.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄
> 

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



OpenPGP_signature
Description: OpenPGP digital signature


Re: Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM

2021-08-21 Thread piorunz

On 21/08/2021 19:38, Mislav Jurić wrote:


I have a bug related to Debian 11 (codename Bullseye). I tried to report
it using /*reportbug*/, but /*reportbug*/ led me to this email address.

I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that
when I close my laptop screen for the 5th or 6th time, my laptop doesn't
suspend properly. *Again, this issue  doesn't happen every time. It
happens after I close and then re-open the laptop screen for the 5th or
6th time in a row.

I am using NVIDIA drivers and CUDA for Debian 11 which I obtained
following instructions from this link
. I am also using the
Atheros firmware package, as well as some other non-driver related packages.


NVIDIA drivers are closed source and proprietary. If they are cause of
this problem, Debian or kernel developers might not be able to help you.

Try to uninstall NVIDIA drivers and use nouveau drivers for a few days.
See if you can reproduce this problem on nouveau. Please note that
nouveau are very basic and 3D acceleration or other things may not work
at all.
Also when you report a problem, even here, it would be useful to include
your hardware specification and cuts from dmesg or other logs showing
this problem, maybe someone will be more able to help after seeing
specific details, not only vague description of the problem.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄



Debian 11 doesn't suspend properly on Acer Aspire 5 A515-51G-52GM

2021-08-21 Thread Mislav Jurić
Dear Debian users,

I have a bug related to Debian 11 (codename Bullseye). I tried to report it
using *reportbug*, but *reportbug* led me to this email address.

I am using Debian 11 on Acer Aspire 5 A515-51G-52GM. *My issue is that when
I close my laptop screen for the 5th or 6th time, my laptop doesn't suspend
properly. *Again, this issue  doesn't happen every time. It happens after I
close and then re-open the laptop screen for the 5th or 6th time in a row.

I am using NVIDIA drivers and CUDA for Debian 11 which I obtained following
instructions from this link .
I am also using the Atheros firmware package, as well as some other
non-driver related packages.

If you could give me further guidance on this, I'd greatly appreciate it.

Best regards


Re: Failed to detect SSD when installing Bullseye

2021-08-21 Thread Nikolay Velyurov
Hi Bjørn,

On Sat, Aug 21, 2021 at 4:38 PM Bjørn Mork  wrote:

> Great!  Glad it could be resolved as easily as that.
>
> Probably a firmware bug. I don't know.  Such issues are pretty common,
> and disabling the IOMMU is the first thing you should try.  Sometimes
> it just doesn't play well with some other feature.  If you don't need
> it then you might as well just disable it.
>
> My Thinkpad fails to suspend if I enable both IOMMU and TPM 2.0.  One of
> them is OK, but not both.  Go figure.  This is https://bugs.debian.org/949020
>
> For some background:
> https://www.kernel.org/doc/html/latest/x86/intel-iommu.html
>
> There are also a number of other options than "off" you could try if you
> want to play with it:
> https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
>
> Note that the bug has probably always been there in your PC firmware.
> It showed up now because Debian changed the default from "off" to "on".
>
> Bjørn

Thanks for the explanation, very helpful!

Nikolay



Libinput Error

2021-08-21 Thread SDA
Hi,
I've been getting the following messages in the journal-log even before
I installed Debian 11. Could someone help decipher them for me? I have
each device plugged into USB v 3.x USB buses as that's all my
motherboard supports.
Is the message saying that the device's are too slow being that they're
probably USB v2? It doesn't make sense that an AMD Ryzen CPU with 32 Gb
of ram would be too slow for any USB socket.
===
Aug 21 13:23:13 home gnome-shell[2096]: libinput error: event2  - dakai 
PS/2+USB Keyboard: client bug: event processing lagging
+behind by 36ms, your system is too slow
Aug 21 13:23:13 home gnome-shell[2096]: libinput error: event2  - dakai 
PS/2+USB Keyboard: WARNING: log rate limit exceeded (5
+msgs per 60min). Discarding future messages.



Re: (deb-cat) Alentiment de processos amb les hores i els dies

2021-08-21 Thread Eloi

El 20/8/21 a les 21:41, Narcis Garcia ha escrit:

El 19/8/21 a les 11:59, Ernest Adrogué ha escrit:

2021-08-18, 17:37 (+0200); Narcis Garcia escriu:

No trobo cap indici del problema en processos que corren, ni res de res.
Només se m'acudeis que pot ser un defecte del nucli Linux (potser les
mitigacions per a Intel?), ja que arrencant amb els nuclis més antics
(4.9 i 4.19) la cosa és més exagerada. Però amb el Linux 5.10 no me'n
lliuro.

Algú sap com esbrinar el problema?

Has comprovat l'ús de memòria, cpus, discs, i freqüència del rellotge?

Aquestes serien les primeres coses que miraria... i òbviament la sortida
de dmesg.

Sí, porto més de 2 anys comprovant tot això, i també provant a canviar
placa base, CPU, RAM.
Algú altre treballa amb Debian en ordinadors amb CPU+gràfics Intel? Ha
provat a treballar diàriament sense aturar l'ordinador?


Jo vaig arribar a tenir un parell de mesos l'ordinador permanentment 
engegat durant el confinament més dur i no vaig tenir cap problema a 
nivell de sistema. Sí que hi havia alguns programes que anaven "perdent 
memòria" (memory leak), per exemple el client de correu Thunderbird, que 
sí havia de reiniciar periòdicament. Ara mateix tinc un uptime de 7 dies 
i va bé.


El meu sistema té processador i gràfica d'Intel.

Prova amb atop, que a més de donar paràmetres de rendiment al moment 
també els enregistra en un històric consultable a posteriori, això 
permet per una banda detectar problemes que ja han passat així com poder 
arribar a detectar increments graduals de consum de recursos.






Re: Debian 10.7 no me actualiza.

2021-08-21 Thread Camaleón
El 2021-08-21 a las 11:27 -0500, 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 son esos?

Yo llevo con la versión 9 varios años y sigo actulizándola :-P

root@stt008:~# cat /etc/debian_version
9.13

root@stt008:~# apt-get update && apt-get -V dist-upgrade
Des:1 http://security.debian.org/debian-security stretch/updates 
InRelease [53,0 kB]
Des:2 http://security.debian.org/debian-security stretch/updates/main 
amd64 Packages [709 kB]
Des:3 http://security.debian.org/debian-security stretch/updates/main 
Translation-en [326 kB]
Ign:4 http://ftp.de.debian.org/debian stretch InRelease   
Obj:5 http://ftp.de.debian.org/debian stretch-updates InRelease 
Obj:6 http://ftp.de.debian.org/debian stretch Release   
Descargados 1.088 kB en 6s (169 kB/s)   
Leyendo lista de paquetes... Hecho
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias   
Leyendo la información de estado... Hecho
Calculando la actualización... Hecho
El paquete indicado a continuación se instaló de forma automática y ya 
no es necesario.
   linux-image-4.9.0-14-amd64 (4.9.246-2)
Utilice «apt autoremove» para eliminarlo.
0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 0 no 
actualizados.

root@stt008:~# cat /etc/apt/sources.list
# 

# deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 
20180310-11:21]/ stretch main

#deb cdrom:[Debian GNU/Linux 9.4.0 _Stretch_ - Official amd64 NETINST 
20180310-11:21]/ stretch main

deb http://ftp.de.debian.org/debian/ stretch main contrib non-free
# deb-src http://ftp.de.debian.org/debian/ stretch main

deb http://security.debian.org/debian-security stretch/updates main contrib 
non-free
# deb-src http://security.debian.org/debian-security stretch/updates main

# stretch-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ stretch-updates main
# deb-src http://ftp.de.debian.org/debian/ stretch-updates main

Saludos,

-- 
Camaleón 



Debian 10.7 no me actualiza.

2021-08-21 Thread Aristobulo Pinzon
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.



Re: Buster to Bullseye upgrade problem

2021-08-21 Thread Gareth Evans
On Sat 21 Aug 2021, at 13:42, Sven Hartge  wrote:
> Gareth Evans  wrote:
> 
> > 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 Sven,

> > Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?
> 
> No, because Debian Policy says that partial upgrades are supported and
> must work.

Interesting, thanks.  I will have a look at [1,2,3] which seem relevant - any 
good refs would be appreciated, even for other distros if the 
concepts/techniques are similar.

Many thanks,
Gareth

[1] https://www.debian.org/doc/debian-policy/policy.pdf

[2] https://wiki.debian.org/Packaging/Intro

[3] https://www.debian.org/doc/manuals/developers-reference/index.en.html

> 
> > It's not a conflict involving two Bullseye packages, nor with one from
> > Bullseye and one held/pinned etc, so I don't see why it should happen.
> 
> This might be a genuine bug in one of the two packages here, where a
> Conflict/Breaks/Replaces dependendy was needed to move a file from one
> package to another.
> 
> I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
> of that problem.
> 
> Grüße,
> S°
> 
> -- 
> Sigmentation fault. Core dumped.
> 
> 



Re: Relatively boring bullseye upgrade reports

2021-08-21 Thread Reco
r2s: Rockchip 3328-based board, NanoPI R2S
Home router, IPSec endpoint

Nothing to report, the upgrade went smoothly.


helios64: Kobol Helios64 board, same device name
NAS

Rebuilding custom packages was the longest part of the upgrade, but no
problems otherwise. transmission-remote-cli did not make it into
bullseye, will search for the replacement.


pi: Broadcom 2835-based board, Raspberry Pi 1B
RS232 redirector, backup SIM holder

Gammu was removed from bullseye, probably will backport it from sid in
the future.


pi2: Broadcom 2710-based board, Raspberry Pi 3B
GNSS receiver, runs proper Debian

Nothing to report, the upgrade went smoothly.


camel: QEMU VM, remote hosting, console access is available
Secondary MX

Exim4 configuration has changed somewhat between buster and bullseye,
but it's nothing that vimdiff could not handle.
Discovered new CHECK_RCPT_NO_FAIL_TOO_MANY_BAD_RCPT option, will test it
for a few days.

Reco



Re: Watching a directory, was Re: how would you do this?

2021-08-21 Thread didar
On Thu, Aug 19, 2021 at 10:45:44PM -0500, David Wright wrote:
> On Thu 19 Aug 2021 at 08:01:24 (-0400), songbird wrote:
> > David Wright wrote:
> > > On Wed 18 Aug 2021 at 20:55:12 (-0400), songbird wrote:
> > >>   let's suppose you have a directory where there are
> > >> various scripts, libraries, programs, data, etc.
> > >> 
> > >>   you want to know exactly which other scripts, libraries,
> > >> etc. use them and to log each caller to know the name so
> > >> it can be tracked down (location would be nice too, but 
> > >> that could be found later if needed).
> > >> 
> > >>   i don't need to keep the information in a database as
> > >> just having the log file will be enough.
> > >> 
> > >>   how would you do this?
> > >> 
> > >>   this isn't a homework assignment i'm just curious how
> > >> easy or hard this would be to accomplish.
> > >
> > > Easy.
> > >
> > > $ inotifywait -m -e access --timefmt "%F %T" --format "%T %f" 
> > > the-directory/
> > >
> > > To try it, just type in that line, using a sensible directory name.
> > > (The package name to install first is inotify-tools.)
> > >
> > > Change the formats to taste. Pipe into a   while IFS=$'\n' read Filename 
> > > ; do
> > > loop if you want to do something with the output. See:
> > >
> > >   https://lists.debian.org/debian-user/2021/03/msg01494.html
> > >
> > > for a real script (waiting on close-writeable-file, rather than just
> > > access) that I use a lot for stealing files from FireFox's cache
> > > (~/.cache/mozilla/firefox/foo.bar.profile/cache2/entries/).
> > 
> >   thanks!  very interesting!  :)
> > 
> >   thank you to others who replied also.  :)
> > 
> >   i was wondering if there was a general tool available as on
> > debian-devel they are talking about usr-merge and if there was a
> > simple way to find out who's using /bin and such instead of 
> > /usr/bin,
> 
> No, that's a different problem. My solution addresses a directory,
> hence the change in Subject line. You'd have to dive deeper into
> inotify and inotify_add_watch, to see whether you can specify the
> inode of the /bin symlink separately from that for /usr/bin.
> 
> $ ls -Glidg /bin /usr/bin
> 12 lrwxrwxrwx 1 7 Apr  3  2020 /bin -> usr/bin
> 261634 drwxr-xr-x 2 69632 Aug 11 19:10 /usr/bin
> $ 
> 
> > but also the idea of being able to set up a honeypot
> > on your own system and see if any programs or processes you 
> > haven't done yourself are accessing it.  might give you a
> > warning of being hacked, but of course there are other things
> > going on in a system which you expect to access things so it
> > is an interesting way to find out what is happening...
> > 
> >   after many years and a lot of different things being set up
> > i think it is a good idea to keep an eye on what is happening.
> > especially with how things are going these days.
> 
> Cheers,
> David.
> 

There is an "auditd" package - a Red Hat origin tool/subsystem. It's available
on Bullseye, but, I have not tried it recently. It might be what you are looking
for.

Regards,
didar

-- 



Re: Debian 11 installer crashed and reboot

2021-08-21 Thread Chuck Zmudzinski

On 8/19/2021 3:11 PM, Andy Smith wrote:

Hi Chuck,

On Tue, Aug 17, 2021 at 08:04:43AM -0400, Chuck Zmudzinski wrote:

After some testing of the Debian 11 installer on Xen
(using the debian-11.0.0-amd64-netinst.iso), I find that
this image only supports installation into a Xen PV guest,
the guest always crashes and reboots for either a BIOS
or OVMF boot into an HVM Xen guest.

Could you report this to Debian's Xen team as a bug? Perhaps it is
as simple as needing different kernel options in the netinst
installer kernel given that the full install works under HVM?


Would you also consider the fact that the OP also noted that the
live ISO also crashes and reboots in a Xen HVM guest a bug? My
thought is that both netinst and live amd64 ISOs should work on
a Xen HVM out of the box (OOTB). If I report a bug, I am inclined
to consider the bug to be that both netinst and live amd64 ISOs
crash in Xen HVM guests and the bug should not be closed until
both ISOs work OOTB in a Xen HVM guest on both a default
Xen/Dom0 stable and oldstable installation, so that users of
oldstable can use oldstable to quickly and easily test stable in a
Xen HVM guest. This would require, as I understand it, close
cooperation between the Xen team, the Qemu team, and the
Debian installer developers so those key parts of the Xen HVM
environment play nicely together with the Debian installer.

I also wonder if the bug should be reported to Debian installer
developers instead of to the Xen team.

Cheers,

Chuck



Re: Debian 11 installer crashed and reboot

2021-08-21 Thread Chuck Zmudzinski

On 8/21/2021 4:34 AM, Thomas Schmitt wrote:

Hi,

John Mok wrote:

As a quick fix on the make installer media work, how can I remake my own
installation ISO by recompil ing the kernel and initramfs ?

Chuck Zmudzinski wrote:

A quick solution would not even require any recompilation
of a kernel, since we know the kernel and ramdisk of
an installed bullseye system does work in a Xen HVM guest.
[...]
I am not familiar with the process that the debian installer team
uses to generate the installation ISOs, but if I wanted to learn
I would start by looking at
https://wiki.debian.org/DebianInstaller/CheckOut

If there are no checksums in the ISO which would cover the initially
booted kernel and the ramdisk, then you could also go the path of

   https://wiki.debian.org/RepackBootableISO

This article mainly shows how to determine the necessary arguments for
the ISO 9660 producing program. Nevertheless, in
   
https://wiki.debian.org/RepackBootableISO#Methods_to_overwrite.2C_delete.2C_or_add_files
it shows some ways how to do the desired manipulations of the ISO's
file tree.

I assume that questions about the entrails of a Debian installation ISO
are best asked at debian-cd mailing list. (Although two of the experts
there happen to be also our friendly list hosts here.)


Have a nice day :)

Thomas



This is how it should be - I am happy that Debian installer developers are
following the user list. There is no more important Debian user to support
than the user who tries to install Debian for the first time. It is the 
Debian

installer's job to try to ensure, as far as possible, that a new Debian user
will be able to quickly and easily install Debian on all supported 
platforms.

I presume that would include at least the bare hardware of the supported
architectures, things like docker/Linux containers and supported virtual
environments such as qemu/kvm and Xen. So the Debian installer developers
should always monitor the Debian user lists for problems that users are 
having

installing Debian in the supported computing environments.

Cheers,

Chuck



Re: nvme SSD and poor performance

2021-08-21 Thread Sven Hartge
Anssi Saari  wrote:
> Jochen Spieker  writes:

>> Stay away from the "discard" option and do not worry about SSD life.

> What's the issue with the discard option? AFAIK, there may have been
> issues with it in the decade before last but again AFAIK, today some
> distros enable discard and some run fstrim on timer, both work.

> But please share.

This may be part cargo culting and part real problem.

In the past it was shown that many SSD needed to flush their whole queue
whenever a TRIM command was received and the Kernel was really zealos of
sending those for every block freed. 

This basically neutered many SSD and even caused corruption issues on
some especially shoddy ones.

Some firmwares got fixed and newer drives don't suffer from the same
problems, but even now end then you can find some devices on the lower
end of the consumer spectrum behaving poorly when bombarded with TRIM
commands.

So in the end the consensous was to just play it safe and batch-TRIM
once a week or day, because TRIMming on demand hasn't been shown to be a
big win.

It is far easier to fall back on that option than trying to
good/bad-list specific drive or firmware versions and select the
appropriate TRIM method.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.



Re: Buster to Bullseye upgrade problem

2021-08-21 Thread Sven Hartge
Gareth Evans  wrote:

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

> Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?

No, because Debian Policy says that partial upgrades are supported and
must work.

> It's not a conflict involving two Bullseye packages, nor with one from
> Bullseye and one held/pinned etc, so I don't see why it should happen.

This might be a genuine bug in one of the two packages here, where a
Conflict/Breaks/Replaces dependendy was needed to move a file from one
package to another.

I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
of that problem.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.



Re: Failed to detect SSD when installing Bullseye

2021-08-21 Thread Nikolay Velyurov
Hi Bjørn,

On Sat, Aug 21, 2021 at 7:42 AM Bjørn Mork  wrote:

> try booting with intel_iommu=off on the kernel command line

It works now, thanks for your help. Is there a known bug or something?

Nikolay



Re: Debian 11 installer crashed and reboot

2021-08-21 Thread Thomas Schmitt
Hi,

there might be an easier way (still depending on whether such simple
file replacements are tolerated by the booting system):

  # Choose the desired new files
  new_kernel=...path.to.desired.new.kernel.in.some.mounted.filesystem...
  new_initrd=...path.to.desired.new.initrd.in.some.mounted.filesystem...

  # Choose the files in the ISO to be replaced by the new files.
  # The ISO needs not to be mounted. (Better it should not be mounted.)
  # Naively, i assume that it's about these two:
  old_kernel=/install.amd/xen/vmlinuz
  old_initrd=/install.amd/xen/initrd.gz

  # Copy netinst ISO to playground ISO
  cp debian-11.0.0-amd64-netinst.iso test.iso

  # Use xorriso multi-session to override the undesired files
  xorriso -dev test.iso \
  -boot_image any keep \
  -map "$new_kernel" "$old_kernel" \
  -map "$new_initrd" "$old_initrd"

This will result in a quite short run of xorriso, which will report
something like

  ISO image produced: 8108 sectors
  Written to medium : 8288 sectors at LBA 193024
  Writing to 'test.iso' completed successfully.

(The numbers 8108 and 8288 are result of the sizes of the two dummy files
which i used as $new_kernel #and new_initrd. Yours will be substantially
larger due to the typical size of an initrd.)

Inspection of the boot equipment of test.iso shows no differences,
except the new storage position of the El Torito boot catalog and the
enlarged ISO image size.

When mounted by Linux, the paths
  /mnt/iso/install.amd/xen/vmlinuz
  /mnt/iso/install.amd/xen/initrd.gz
lead to the content of $new_kernel and $new_initrd.

Then it depends on the inner doings of boot loader and starting system,
whether this perky change is tolerated.


Have a nice day :)

Thomas



Re: passage de bullseye à bookworm

2021-08-21 Thread Jean Louis Giraud Desrondiers
enfin beaucoup beaucoup plus
> > que les fois précédentes et je me demande si je n'ai pas raté
> > quelque chose ?  
> 
> bullseye est sortie la semaine dernière, donc le temps que les
> nouveaux paquets intégrés dans sid fassent leur entrée dans
> bookworm (soit à peu près cinq jours), le delta entre les deux
> distributions n'est pour l'instant pas immense.
ah oui c'est une possibilité - il est vrai que les fois précédentes
j'attendais plusieurs semaines avant de passer à la nouvelle version
testing ceci explique probablement cela. 
> 
> Si ça peut éclairer votre lanterne,
> Bonne journée,  :)
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/9, please excuse my verbosity.


-- 
Cordialement, 

Jean Louis Giraud Desrondiers 



Re: Debian 11 installer crashed and reboot

2021-08-21 Thread Thomas Schmitt
Hi,

John Mok wrote:
> > As a quick fix on the make installer media work, how can I remake my own
> > installation ISO by recompil ing the kernel and initramfs ?

Chuck Zmudzinski wrote:
> A quick solution would not even require any recompilation
> of a kernel, since we know the kernel and ramdisk of
> an installed bullseye system does work in a Xen HVM guest.
> [...]
> I am not familiar with the process that the debian installer team
> uses to generate the installation ISOs, but if I wanted to learn
> I would start by looking at
> https://wiki.debian.org/DebianInstaller/CheckOut

If there are no checksums in the ISO which would cover the initially
booted kernel and the ramdisk, then you could also go the path of

  https://wiki.debian.org/RepackBootableISO

This article mainly shows how to determine the necessary arguments for
the ISO 9660 producing program. Nevertheless, in
  
https://wiki.debian.org/RepackBootableISO#Methods_to_overwrite.2C_delete.2C_or_add_files
it shows some ways how to do the desired manipulations of the ISO's
file tree.

I assume that questions about the entrails of a Debian installation ISO
are best asked at debian-cd mailing list. (Although two of the experts
there happen to be also our friendly list hosts here.)


Have a nice day :)

Thomas



Re: You are required to change your password immediately (administrator enforced).

2021-08-21 Thread Sven Joachim
On 2021-08-18 14:16 +0200, Harald Dunkel wrote:

> On 8/17/21 21:55, Sven Joachim wrote:
>> On 2021-08-17 19:59 +0200, Harald Dunkel wrote:
>>
>>>
>>> How can I make sure I don't have to change passwords on 400+ hosts?
>> Do not run sid on 400+ hosts.  Do not run testing either, especially
>> in
>> the first months after a release.
>>
>
> Of course not. But sid becomes the next release in 2 years, and then it
> might be to late to get rid of this lie.

Feel free to file a bug against the libcrypt1 package and/or the release
notes.  The change itself looks quite reasonable to me though, as
md5crypt hashes are really insecure these days.

The following command could be used to check for old md5crypt password
hashes, see crypt(5):

sudo cat /etc/shadow | grep -F ':$1$'

Cheers,
   Sven



Re: Problema de gràfics amb kernel 5.10 després d'actualitzar d10 > d11

2021-08-21 Thread Joan
El Wed, 18 Aug 2021 12:45:56 +0200
Narcis Garcia  va escriure:

> Has provat a deshabilitar Wayland al GDM ?
> 
> Salut.


Si que ho vaig provar, sense èxit. Al final era això:

https://slimbook.es/component/questions/question/4854

Resulta que la gent d'Slimbook, quan venen un ordinador amb una Debian
preinstal·lada, fan alguns canvis perquè tot xuti (lo típic d'equips
nous que amb una Debian poden tenir problemes de reconeixement de
hardware). Doncs bé, algun d'aquests canvis pot quedar en un fitxer de
configuració, com era el cas, i donar problemes posteriorment...

Merci per l'ajutori!

> 
> 
> El 17/8/21 a les 14:25, Joan ha escrit:
> > Bon dia,
> > 
> > Tinc un problema després de l'actualització de debian 10 a d11
> > 
> > La pantalla del display manager em queda congelada, perquè no puc
> > moure el ratolí ni usar el teclat He provat substituint el gdm3 per
> > altres display managers (lightdm, el de kde, el de lfce...), i dona
> > el mateix error Però, en canvi, si arrenco amb el kernel antic 5.3
> > en comptes de l'actual 5.10, no tinc aquest problema i puc iniciar
> > la meva sessió.
> > 
> > Ara bé, el Gnome no em permet gestionar les extensions... De fer, a
> > les preferències, no em deixa triar al desplegable "shell"
> > 
> > I la pestanya "extensions", als "Ajustaments", surt ombrejada i no
> > em deixa activar/desactivar cap extensió Teniu alguna idea de quin
> > log podria revisar per començar a tenir alguna pista? Per cert,
> > tinc dugues pantalles, no sé si això pot tenir alguna rellevància..
> >   
> 



-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi



Re: différence entre Debian 11 & Ubuntu 21.04, clavier lent!

2021-08-21 Thread Basile Starynkevitch



On 21/08/2021 00:43, Sébastien Dinot wrote:

Bonjour Basile,

Basile Starynkevitch a écrit :

J'ai la vague mais nette impression (alors que la machine est "idle"
la plupart du temps) d'un délai (parfois plus d'une demi-seconde!)
entre le clavier et l'affichage (par exemple via Xorg et thunderbird).

Aurais-tu activé par hasard le mode « slow keys » ?

https://help.gnome.org/users/gnome-help/stable/a11y-slowkeys.html.en



Merci de cette piste, mais je n'ai pas trouvé de section AccessX 

Je vais regarder de plus près!




Sébastien


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