Re: live-build: erreur sur firmware

[didier gaumet]

Le 23/11/2023 à 03:23, Pierre ESTREm a écrit :
[...]

E: Package 'firmware-linux' has no installation candidate

[...]

     --archive-areas main contrib non-free \

[...]

Bonjour,

didier@hp-notebook14:~$ apt show firmware-linux
[...]
Section: non-free-firmware/metapackages
[...]

je pense que la ligne suivante serait correcte pour ton emploi:

  --archive-areas main contrib non-free non-free-firmware \

ou simplement

  --archive-areas main contrib non-free-firmware \

si seuls les firmwares t'intéressent parmi les logiciels propriétaires

Re: CVE (Critical + High) in bookworm image

[David Wright]

On Wed 22 Nov 2023 at 15:27:06 (-0500), Greg Wooledge wrote:
> On Wed, Nov 22, 2023 at 01:34:49PM -0600, David Wright wrote:
> > AFAICT zipOpenNewFileInZip4_64 is only contained in
> > /usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
> > libminizip1_1~b1_amd64.deb.
> > 
> > In Debian, it would appear that minizip was split off from zlib1g
> > a decade ago.
> > 
> > zlib (1:1.2.8.dfsg-2) unstable; urgency=low
> >   
> >   * Drop zlib-bin package as minizip has now been packaged separately,
> > delay due to lack of notice regarding upload (closes: #753070).
> > 
> >  -- Mark Brown   Sat, 16 Aug 2014 15:12:11 +0100
> 
> unicorn:~$ apt-cache show zlib1g
> [...]
> Source: zlib
> [...]
> Homepage: http://zlib.net/
> 
> unicorn:~$ apt-cache show libminizip1
> [...]
> Source: minizip (1.1-8)
> [...]
> Homepage: http://www.winimage.com/zLibDll/minizip.html
> 
> 
> Looks like Debian's minizip (including libminizip1) was sourced from a
> separate location, rather than being split apart from zlib.

I think that link gives a misleading impression. Before minizip,
the functionality was in zlib-bin, and the library was (using as
an example zlib-bin-1.2.3.4-minizip, from 2009):

  $ strings /tmp/zlib-bin-1.2.3.4-minizip | grep -i zlib
  MiniZip 1.01b, demo of zLib + Zip package written by Gilles Vollant
  more info at http://www.winimage.com/zLibDll/unzip.html
   zip 1.01 Copyright 1998-2004 Gilles Vollant - http://www.winimage.com/zLibDll
  $ 

I think it's all the same old code; this is the latest canonical
source of zlib (1495873 Aug 18 05:08 zlib.tar.gz, which I unpacked
in /tmp) with the same link:

  $ head -n 5 /tmp/zlib-1.3/contrib/minizip/zip.c 
  /* zip.c -- IO on .zip files using zlib
 Version 1.1, February 14h, 2010
 part of the MiniZip project - ( 
http://www.winimage.com/zLibDll/minizip.html )

   Copyright (C) 1998-2010 Gilles Vollant (minizip) ( 
http://www.winimage.com/zLibDll/minizip.html )
  $ 

> On the other hand, I cannot find zipOpen in
> /lib/x86_64-linux-gnu/libz.so.1.2.13 either (I used nm -D ... | less),
> so perhaps the minizip portion of zlib is not included during the build.
> If that's true, then the package should be marked as "not vulnerable".

… and libminizip1 should be the one marked:

  $ grep -r zipOpenNewFileInZip4_64 /tmp/zlib-1.3/
  /tmp/zlib-1.3/contrib/minizip/zip.c:extern int ZEXPORT 
zipOpenNewFileInZip4_64(zipFile file, const char* filename, const zip_fileinfo* 
zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.c:return zipOpenNewFileInZip4_64(file, 
filename, zipfi,
  /tmp/zlib-1.3/contrib/minizip/zip.h:extern int ZEXPORT 
zipOpenNewFileInZip4_64(zipFile file,
  /tmp/zlib-1.3/contrib/vstudio/vc10/zlibvc.def:zipOpenNewFileInZip4_64 
@135
  /tmp/zlib-1.3/contrib/vstudio/vc14/zlibvc.def:zipOpenNewFileInZip4_64 
@135
  /tmp/zlib-1.3/contrib/vstudio/vc11/zlibvc.def:zipOpenNewFileInZip4_64 
@135
  /tmp/zlib-1.3/contrib/vstudio/vc9/zlibvc.def:zipOpenNewFileInZip4_64  
   @135
  /tmp/zlib-1.3/contrib/vstudio/vc12/zlibvc.def:zipOpenNewFileInZip4_64 
@135
  $ 

Cheers,
David.

live-build: erreur sur firmware

[Pierre ESTREm]

Bonjour la liste

Je débute avec cet outil.
Je commence par une iso-hybrid avec un système "normal" :

J'obtiens l'erreur en fin de log :
...
E: Package 'firmware-linux' has no installation candidate
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...

Reading state information...

Je fais cela avec le script auto/config :

#!/bin/sh

set -e

lb config noauto \
    --architectures amd64 \
    --distribution bookworm \
    --system normal \
    --bootloaders syslinux \
    --archive-areas main contrib non-free \
    --apt-recommends true \
    --binary-filesystem ext4 \
    "${@}"

Si j'ajoute l'option "--firmware-binary true" même  erreur.

Où fais-je l'erreur ?

Merci
pierre estrem

Re: Récupérer les noms, marques et modèles des périphériques connectées à un réseau

[Belaïd]

 Salut,

La commande ci-dessous donne déjà plus d'informations:

nmap -T4 -A

Le mer. 22 nov. 2023 à 22:06, Frederic Zulian  a écrit :

> Bonjour,
>
> Avec nmap -sP  je récupère les IP  des matériels connectés sur un réseau.
> Mais comment faire pour identifier les différents matériels  (type de
> matériel, marque, modèle) ?
>
> Exemple :  Avec freeos, il est possible de récupérer   la marque, le
> modèle, le nom du constructeur en plus des adresses MAC et IP de tous les
> périphérique.
>
>  Une idée  ?
>
>
> Frédéric ZULIAN
>


-- 
< Belaid >

Re: CVE (Critical + High) in bookworm image

[Greg Wooledge]

On Wed, Nov 22, 2023 at 01:34:49PM -0600, David Wright wrote:
> AFAICT zipOpenNewFileInZip4_64 is only contained in
> /usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
> libminizip1_1~b1_amd64.deb.
> 
> In Debian, it would appear that minizip was split off from zlib1g
> a decade ago.
> 
> zlib (1:1.2.8.dfsg-2) unstable; urgency=low
>   
>   * Drop zlib-bin package as minizip has now been packaged separately,
> delay due to lack of notice regarding upload (closes: #753070).
> 
>  -- Mark Brown   Sat, 16 Aug 2014 15:12:11 +0100

unicorn:~$ apt-cache show zlib1g
[...]
Source: zlib
[...]
Homepage: http://zlib.net/

unicorn:~$ apt-cache show libminizip1
[...]
Source: minizip (1.1-8)
[...]
Homepage: http://www.winimage.com/zLibDll/minizip.html


Looks like Debian's minizip (including libminizip1) was sourced from a
separate location, rather than being split apart from zlib.

On the other hand, I cannot find zipOpen in
/lib/x86_64-linux-gnu/libz.so.1.2.13 either (I used nm -D ... | less),
so perhaps the minizip portion of zlib is not included during the build.
If that's true, then the package should be marked as "not vulnerable".

Re: CVE (Critical + High) in bookworm image

[David Wright]

On Wed 22 Nov 2023 at 12:52:17 (-0500), Greg Wooledge wrote:
> On Wed, Nov 22, 2023 at 10:39:56PM +0530, thomas wrote:
> > is there any way we could get
> > a fix in bookworm release or is there any other suggestion.
> 
> Whenever the security team releases a fix.
> 
> > CVE-2023-45853
> 
> https://security-tracker.debian.org/tracker/CVE-2023-45853
> 
>   "MiniZip in zlib through 1.3 has an integer overflow and resultant
>   heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long
>   filename, comment, or extra field. NOTE: MiniZip is not a supported
>   part of the zlib product."

AFAICT zipOpenNewFileInZip4_64 is only contained in
/usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
libminizip1_1~b1_amd64.deb.

In Debian, it would appear that minizip was split off from zlib1g
a decade ago.

zlib (1:1.2.8.dfsg-2) unstable; urgency=low
  
  * Drop zlib-bin package as minizip has now been packaged separately,
delay due to lack of notice regarding upload (closes: #753070).

 -- Mark Brown   Sat, 16 Aug 2014 15:12:11 +0100

Looking at what pulls libminizip1 in, they look like multiplatform
games and graphics programs. I know that, were I to install it,
frescobaldi would pull it in.

> Here's what I don't immediately understand: what actually triggers
> the bug?  Does it require some explicit request to access the MiniZip
> functionality, or does it just automatically get called if the input
> archive is compressed with it?
> 
> In other words, if you've got a malicious input file, will something
> like "zcat mailicious.minizip" trigger it, or do you have to pass
> a "--minizip" flag or something?

I would guess that an unintentional usage might be if you caused the
unzipping of an archive that looked as if it had been compressed with
PKZIP, or tried to add files to such a file.

Cheers,
David.

Récupérer les noms, marques et modèles des périphériques connectées à un réseau

[Frederic Zulian]

Bonjour,

Avec nmap -sP  je récupère les IP  des matériels connectés sur un réseau.
Mais comment faire pour identifier les différents matériels  (type de
matériel, marque, modèle) ?

Exemple :  Avec freeos, il est possible de récupérer   la marque, le
modèle, le nom du constructeur en plus des adresses MAC et IP de tous les
périphérique.

 Une idée  ?


Frédéric ZULIAN

Re: CVE (Critical + High) in bookworm image

[Greg Wooledge]

On Wed, Nov 22, 2023 at 10:39:56PM +0530, thomas wrote:
> is there any way we could get
> a fix in bookworm release or is there any other suggestion.

Whenever the security team releases a fix.

> CVE-2023-45853

https://security-tracker.debian.org/tracker/CVE-2023-45853

  "MiniZip in zlib through 1.3 has an integer overflow and resultant
  heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long
  filename, comment, or extra field. NOTE: MiniZip is not a supported
  part of the zlib product."

>  JFrog Severity -High

I don't know how that severity level was determined.  A buffer overflow
in an unsupported part of the library doesn't sound "High" severity to
me, but hey, what do I know.

>  Summary
> 
> A heap buffer overflow in zlib may lead to remote code execution when
> parsing a malicious archive.

Here's what I don't immediately understand: what actually triggers
the bug?  Does it require some explicit request to access the MiniZip
functionality, or does it just automatically get called if the input
archive is compressed with it?

In other words, if you've got a malicious input file, will something
like "zcat mailicious.minizip" trigger it, or do you have to pass
a "--minizip" flag or something?

If it's the former, then maybe the "High" severity is justified.

>  CVE-2023-31484
> Missing TLS check in CPAN.pm allows man-in-the-middle attacks when
> downloading packages and may lead to code execution.

That sounds pretty avoidable.  Just don't do that.  Do you actually use
CPAN to download and compile perl modules on this system?  If not, then
this bug can't possibly affect you.

In order to trigger this, not only would you have to be using CPAN in
that way on your system, but the attacker would *also* have to compromise
either the CPAN file servers, or some part of your TCP/IP connection to
them.

CVE (Critical + High) in bookworm image

[thomas]

Hi,

   I am installing  nodejs on top of a debian (bookworm-slim) image for
some task. While the intended functionality works fine, the security scan
(JFrog Xray) fails with a critical and high issue. I see some fix in sid
but since it is development mode (I believe) is there any way we could get
a fix in bookworm release or is there any other suggestion.

CVE-2023-45853

 JFrog Severity -High

Components - debian:bookworm:zlib1g:1:1.2.13.dfsg-1

Version 1:1.2.13.dfsg-1

 CVSS Score - 9.8 (v3)

 Summary

A heap buffer overflow in zlib may lead to remote code execution when
parsing a malicious archive.

 ==

 CVE-2023-31484

 JFrog Severity - High

Components - debian:bookworm:perl-base:5.36.0-7

Version - 5.36.0-7

CVSS Score -8.1 (v3)

 Summary

Missing TLS check in CPAN.pm allows man-in-the-middle attacks when
downloading packages and may lead to code execution.


Thanks,

Thomas

Re: Part II dd copy destroyed DVD

[to...@tuxteam.de]

On Wed, Nov 22, 2023 at 02:11:13PM +, Schwibinger Michael wrote:
> 
> Yes.
> This is the problem.
> So mc cannot copy all files

Perhaps. But perhaps not. It is possible we misunderstand.

Can you please

 - show us the file name you are trying to copy the ISO to?
   Please, with the full path.
 - show us which file systems you have mounted?
   In a console, enter "mount" (without the quotes)
 - show us how much space is left in your file system
   In a console, enter "df"

Then, perhaps, we may understand what is happening.

Cheers

(Your mail provider, Microsoft, still hates me)
-- 
t


signature.asc
Description: PGP signature

AW: Part II dd copy destroyed DVD

[Schwibinger Michael]

Yes.
This is the problem.
So mc cannot copy all files

Regards

Sophie




Von: to...@tuxteam.de
Gesendet: Sonntag, 19. November 2023 06:59
Bis: Timothy M Butterworth
Cc: debian-user@lists.debian.org
Betreff: Re: Part II dd copy destroyed DVD

On Sat, Nov 18, 2023 at 10:38:16PM -0500, Timothy M Butterworth wrote:
> On Sat, Nov 18, 2023 at 10:17 PM Max Nikulin  wrote:
>
> > On 18/11/2023 23:35, Marco Moock wrote:
> > > it maybe a stupid DRM?
> >
> > ... or a blank disk because nothing has been written there.
> >
> > AW: Anybody familiar with dd (copy)? Sat, 4 Nov 2023 13:28:16 +
> >
> > https://lists.debian.org/msgid-search/as8pr10mb742781d572af09e5dc874f1dc5...@as8pr10mb7427.eurprd10.prod.outlook.com
> > >  I did burn a DVD.
> > > Burning did make a bug.
> >
>
> How big is the iso file? If it is larger than 4.7GB then it will be too
> large to write to disk.

I lost track: does the OP have a crippled file system
like that?

Cheers
--
t

Re: it: perhaps? gmail issues.

[Richmond]

In this article Google seems to think using standard webmail works with
a screen reader.

https://support.google.com/mail/answer/90559

It advises to turn on keyboard shortcuts.

I suppose another option would be to use another webmail service to pick
up email from gmail.

Karen Lewellen wrote:
> Hi folks,
> Admit my hands are shaking a bit as I write.
> This morning google began circulating a plan to force standard gmail
> on users still keeping basic html gmail...in spite of posts on their
> own accessibility list from members around the world experiencing
> disabilities who still need basic html.
> I personally have a great deal of content, for work and otherwise in
> this inbox.
> making it worse for me is that one must solve a captcha to prove
> yourself, something I physically cannot do.
> so,  thinking of Debian shells or Ubuntu ones, how would you find a
> path to gmail firmly?
> Thanks,
> Karen
>
>

Re: bash vs. dash and stdin

[Nicolas George]

Max Nikulin (12023-11-22):
> Is there a document that describes shell behavior in respect to stdin in
> such cases?

The shell did not eat your stdin here, ssh did.

Regards,

-- 
  Nicolas George

Re: bash vs. dash and stdin

[Greg Wooledge]

On Wed, Nov 22, 2023 at 07:06:58PM +0700, Max Nikulin wrote:
> Consider a file (ssh.sh) containing a couple of commands:
> 
>ssh localhost echo remote
>echo local
> 
> Let's try to run it (assuming key-based authorization)
> 
> bash  remote

You're trying to use stdin twice at the same time.  You've got bash
reading stdin to fetch commands, and you've got ssh reading stdin because
that's just what ssh does.

This is like .  ssh grabs
all of the stdin (until EOF) and leaves none for bash.

> One might expect to see "local" as well.
> 
> dash  remote
> local

I don't know dash's internals.  Maybe dash reads an entire buffer's
worth of stdin at a time, instead of a command at a time as bash does.

> If the script is passed as an argument, not to stdin, then output contains
> "local" in both cases.

Yes.  In that case, bash is not competing with ssh for stdin.

bash vs. dash and stdin

[Max Nikulin]

Hi,

There was a thread on stdio buffering and fork a month ago. That time I 
thought shells should be rather careful with input/output handling when 
spawning subprocesses.


Consider a file (ssh.sh) containing a couple of commands:

   ssh localhost echo remote
   echo local

Let's try to run it (assuming key-based authorization)

bash Is there a document that describes shell behavior in respect to stdin in 
such cases?


If the script is passed as an argument, not to stdin, then output 
contains "local" in both cases. I admit that ssh (called this way) can 
not avoid consuming of some stdin, so bash behavior may be considered a 
bit more correct despite initial expectations.


If you are going to try strace then, to make difference more prominent, 
it is better to force creation of a pipe


cat ssh.sh | strace bash

I am curious if it may be a dash bug or it is just falls into the 
category of unspecified behavior.


P.S. I noticed it in a discussion whether a command not executed after 
ssh is an Emacs bug. My conclusion is that "ssh -n" should be used in 
scripts unless a remote command really needs stdin.

Re: Weird MAC address

[Marco Moock]

Am 22.11.2023 um 12:00:52 Uhr schrieb Nicolas George:

> Thanks for clarifying. But AFAIK, with proxy ARP, the network mask
> covers all the networks covered by the proxy. That is not the case
> here.

Does your Router have a default route?
The it covers 0.0.0.0/0.

Re: Weird MAC address

[Marco Moock]

Am 22.11.2023 um 11:58:55 Uhr schrieb Nicolas George:

> I do not see what the router has to do with anything. Can you
> elaborate what you mean?

Proxy-ARP offers the possibility to answer ARP requests of addresses
outside the own subnet sitting on another ethernet link.
In normal cases that is not needed. It is needed when systems exist
that don't have the same subnet mask - for whatever reason.

It is a niche situation mostly for very old operating systems, so
disable it by default on the router.

> On the server, we never enabled an option to accept ARP information
> that does not come as a reply to a request from the network stack, if
> such an option even exists, so even if such a packet came it should
> not have reached the ARP tables.

I dunno if your system accepts such ARP replies, maybe give it a manual
try.

Re: Weird MAC address

[Nicolas George]

Marco Moock (12023-11-22):
> Sorry, not gracious-arp, proxy-arp can be responsible for that.

Thanks for clarifying. But AFAIK, with proxy ARP, the network mask
covers all the networks covered by the proxy. That is not the case here.

Regards,

-- 
  Nicolas George

Re: Weird MAC address

[Nicolas George]

Marco Moock (12023-11-22):
> Are those networks on the same ethernet link?

No, they are on a different VLAN.

> Are some systems with wrong subnet masks on the link and the router has
> gratious ARP enabled?

I do not see what the router has to do with anything. Can you elaborate
what you mean?

On the server, we never enabled an option to accept ARP information that
does not come as a reply to a request from the network stack, if such an
option even exists, so even if such a packet came it should not have
reached the ARP tables.

Regards,

-- 
  Nicolas George

Re: Weird MAC address

[Marco Moock]

Am 22.11.2023 um 11:51:36 Uhr schrieb Marco Moock:

> Are some systems with wrong subnet masks on the link and the router
> has gratious ARP enabled?

Sorry, not gracious-arp, proxy-arp can be responsible for that.

Re: Weird MAC address

[Marco Moock]

Am 22.11.2023 um 11:29:47 Uhr schrieb Nicolas George:

> As you can see, the server is on the …96.0/22 subnet, i.e. …96-…99,
> but it sees MAC addresses on the 100 and 103 networks.

Are those networks on the same ethernet link?
Are some systems with wrong subnet masks on the link and the router has
gratious ARP enabled?

Weird MAC address

[Nicolas George]

Hi.

Since last we have four MAC addresses in the ARP table of a server that
should not be there:

$ ip route
default via XXX.XXX.98.254 dev eth0 onlink 
XXX.XXX.96.0/22 dev eth0  proto kernel  scope link  src XXX.XXX.98.94 

But:

$ ip neigh | grep -v 'XXX.XXX.9[6789]'
XXX.XXX.103.161 dev eth0 lladdr YY:YY:YY:YY:YY:YY

Re: apt update : message

[Daniel Caillibaud]

Le 18/11/23 à 17:27, "ajh-valmer"  a écrit :
> apt update :
> "http://deb.debian.org/debian/dists/bookworm-backports/InRelease: 
> Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), 

Tu as des clés stockées avec l'ancienne méthode. Pour passer à la nouvelle il 
faut simplement
suivre ses conseils :

> see the DEPRECATION section in apt-key(8) for details.

=> `man apt-key` puis chercher DEPRECATION (taper '/' puis 'DEPRECATION')

> N: Repository 'Debian bookworm' changed its 'non-free component' 
> value from 'non-free' to 'non-free non-free-firmware'"

Ça c'est une info, si tu avais mis non-free seulement pour des pilotes, tu peux 
mettre
non-free-firmware à la place (ça fera bcp moins de monde à analyser à chaque 
apt update)

-- 
Daniel

Ce n'est pas parce qu'ils sont nombreux à avoir tord
qu'ils ont raison.
Coluche

Re: Teams via firefox

[Fab]

Le 20/11/2023 à 22:06, Frederic Zulian a écrit :
Solution toute simple : Installation de l'extension "Refined Microsoft 
Teams".

Cela fonctionne nickel.


ou installer le client lourd "Teams for linux" ?

f.

Re: screen lock shuts down attached HDDs, they don't start up again

[Zenaan Harkness]

On 11/22/23, Zenaan Harkness  wrote:
> On 11/21/23, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
>> On 21 Nov 2023 14:48 +1100, from zen...@gmail.com (Zenaan Harkness):
>>> The desktop displays, but my external HDDs have been put to sleep, and
>>> they do not wake up.
>>>
>>> One of them is zfs. The zfs mounts list shows, but any attempt to
>>> view/ls a zfs mount, just hangs permanently until a reboot.
>>>
>>> The other drive is an ext4 filesystem, and it has been completely
>>> un-mounted and the HDD spun down, and it does not spin up again -
>>> until a reboot.
>>
>> This doesn't sound right.
>>
>> Can you run hdparm -C on the affected devices at the time? What is the
>> result of that?
>
> So it seems I can test this quickly with a manual suspend, then do the
> various checks... it seems that the issue here is the
> auto-sleep/suspend.
>
> For starters, prior to suspend, I've removed the zfs drive, and just
> left the ext4 drive in the USB caddy (it holds up to 2 drives).
>
> Prior to suspend, I get, for the 2.5 inch hdd when it has not been
> accessed for a while and I can feel it is not spinning:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> then, I ls'ed a dir in that drive that had not previously been
> accessed, and could feel it spin up and then give me the output, and
> then I ran hdparm again and interestingly, checking a few times on the
> now spun up drive, I get identical results as with the drive in the
> spun down state:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> 
> Now, after suspend (and wait for hdd to spin down, and wait for
> monitors to blank, and wait another 10s) and finally wake the computer
> up (which is really too slow - 20 or 30 seconds or so, so something
> odd or challenging seems to be happening inside the kernel somewhere):
>
> # ll /dev/sd*
> ls: cannot access '/dev/sd*': No such file or directory
>
> # hdparm -C /dev/sda
> /dev/sda: No such file or directory
>
>
>> Do the drives spin back up if you use hdparm -z?
>
> Prior to suspend and wake, I get this:
>
> # hdparm -z /dev/sda
> /dev/sda:
>  re-reading partition table
>  BLKRRPART failed: Device or resource busy
>
> And again, after suspend and wake there is no more /dev/sda, or any
> /dev/sd*, so I cannot run hdparm on any such device.
>
>
>> What is the exact kernel version you are running? Please provide both
>> the package name and exact package version, and the full output from
>> uname -a.
>
> # uname -a
> Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
> (2023-09-29) x86_64 GNU/Linux
>
> The kernel package is exactly
> linux-image-6.1.0-13-amd64
>
>
>> Assuming that those drives are connected over USB, do they show up in
>> lsusb output while inaccessible?
>
> Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
> trackball, and possibly the following is the HDD dock ? dunno:
>
> Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
> USA Technology Corp. JMS56x Series
>
> ... and sure enough after suspend and wake, Bus 006 Device 015 is
> gone, no longer exists, so it somehow has not woken up - but I CAN
> still see the blue light on the hdd caddy, but the hdd remains in a
> spun down/ sleep state, and no /dev/sd* device.


I apologize, the above para was inserted after I did the suspend and
wake cycle, and the following paras were done before that. I apologize
for the confusion, so just be aware the following paras are part of
the "Prior to suspend..." para above.

> I do get these though (alias ll='ls -l'):
>
> # find /dev/disk/|grep usb
> /dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
> /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
>
> # ll /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
> 0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
> /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
> ../../sda
>
> # ll /dev/sd*
> 0 brw-rw 1 root disk 8, 0 20231122 10:33.10 /dev/sda
>
> ... interestingly, it seems when I formatted this drive with ext4, I
> formatted ext4 on the whole disk (/dev/sda) without using partitions,
> and so it's just /dev/sda and not /dev/sda1, which has the ext4
> filesystem.
>
>
>> Is there anything relevant in dmesg output?
>
> This looks quite suspicious (some error lines, not all of dmesg output):
>
> [42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
> [42668.986050] usb 6-2.3.1: USB disconnect, device number 15
> [42

Re: screen lock shuts down attached HDDs, they don't start up again

[Zenaan Harkness]

On 11/21/23, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> On 21 Nov 2023 14:48 +1100, from zen...@gmail.com (Zenaan Harkness):
>> The desktop displays, but my external HDDs have been put to sleep, and
>> they do not wake up.
>>
>> One of them is zfs. The zfs mounts list shows, but any attempt to
>> view/ls a zfs mount, just hangs permanently until a reboot.
>>
>> The other drive is an ext4 filesystem, and it has been completely
>> un-mounted and the HDD spun down, and it does not spin up again -
>> until a reboot.
>
> This doesn't sound right.
>
> Can you run hdparm -C on the affected devices at the time? What is the
> result of that?

So it seems I can test this quickly with a manual suspend, then do the
various checks... it seems that the issue here is the
auto-sleep/suspend.

For starters, prior to suspend, I've removed the zfs drive, and just
left the ext4 drive in the USB caddy (it holds up to 2 drives).

Prior to suspend, I get, for the 2.5 inch hdd when it has not been
accessed for a while and I can feel it is not spinning:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby

then, I ls'ed a dir in that drive that had not previously been
accessed, and could feel it spin up and then give me the output, and
then I ran hdparm again and interestingly, checking a few times on the
now spun up drive, I get identical results as with the drive in the
spun down state:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby


Now, after suspend (and wait for hdd to spin down, and wait for
monitors to blank, and wait another 10s) and finally wake the computer
up (which is really too slow - 20 or 30 seconds or so, so something
odd or challenging seems to be happening inside the kernel somewhere):

# ll /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory

# hdparm -C /dev/sda
/dev/sda: No such file or directory


> Do the drives spin back up if you use hdparm -z?

Prior to suspend and wake, I get this:

# hdparm -z /dev/sda
/dev/sda:
 re-reading partition table
 BLKRRPART failed: Device or resource busy

And again, after suspend and wake there is no more /dev/sda, or any
/dev/sd*, so I cannot run hdparm on any such device.


> What is the exact kernel version you are running? Please provide both
> the package name and exact package version, and the full output from
> uname -a.

# uname -a
Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
(2023-09-29) x86_64 GNU/Linux

The kernel package is exactly
linux-image-6.1.0-13-amd64


> Assuming that those drives are connected over USB, do they show up in
> lsusb output while inaccessible?

Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
trackball, and possibly the following is the HDD dock ? dunno:

Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS56x Series

... and sure enough after suspend and wake, Bus 006 Device 015 is
gone, no longer exists, so it somehow has not woken up - but I CAN
still see the blue light on the hdd caddy, but the hdd remains in a
spun down/ sleep state, and no /dev/sd* device.

I do get these though (alias ll='ls -l'):

# find /dev/disk/|grep usb
/dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
/dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0

# ll /dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
/dev/disk/by-path/pci-:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
../../sda

# ll /dev/sd*
0 brw-rw 1 root disk 8, 0 20231122 10:33.10 /dev/sda

... interestingly, it seems when I formatted this drive with ext4, I
formatted ext4 on the whole disk (/dev/sda) without using partitions,
and so it's just /dev/sda and not /dev/sda1, which has the ext4
filesystem.


> Is there anything relevant in dmesg output?

This looks quite suspicious (some error lines, not all of dmesg output):

[42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
[42668.986050] usb 6-2.3.1: USB disconnect, device number 15
[42668.986406] device offline error, dev sda, sector 0 op 0x1:(WRITE)
flags 0x800 phys_seg 0 prio class 2
[42668.988647] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
[42668.990867] hub 6-2.3.2.3:1.0: hub_ext_port_status failed (err = -71)
[42668.990888] hub 6-2.3.2.1:1.0: hub_ext_port_status failed (err = -71)
[42669.007554] usb 6-2.3.2.3.1: Failed to suspend device, error -71
[42669.008775] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
42713.495809] xhci_hcd :3a:00.0: Timeout while waiting for setup
device command
[42713.703761] usb 6-2.3.1: device not accepting address 19, error -62
[42713.704792] usb 6-2.3-port1: unable to enumerate USB device
[42713.708332] usb 6-2.3.2: USB disconnect, device number 5
[42713.708343] usb 6-2.3.2.1: USB disconnect, device number 7


since "2.3.1" appears in the d

Parts for sports cars

[Edmond Borom]

Hi,

I'm reaching out to you on behalf of a manufacturer of automotive parts 
dedicated to BMW drift car modifications.

We are active drivers who participate in races and automotive events. Our 
product range includes a variety of parts, from engine components and 
suspension systems to body modifications. We can supply everything that sports 
car enthusiasts may need.

For wholesale customers, we offer competitive prices, enabling our partners to 
achieve attractive margins while maintaining affordability for their customers.

Are you interested in expanding your product offerings with high-quality parts 
for sports cars?


Sincerely
Edmond Borom