Re: [ HS ] find et les gros fichiers

[David Martin]

Bonjour Pascal,

Merci pour cette info, tu as un exemple d'utilisation ?

La commande de bernard est vraiment bien... par contre si l'un de vous
connais exim (je suis plus à l'aise avec Postfix), je cherche
le moyen d'ajouter notre relais smtp pour l'envoi automatique d'un mail du
rapport à la fin de la commande.

Sous postfix je renseigne la variable relay_host =
sous exim ça à l'air plus compliqué non ?

Re: [ HS ] find et les gros fichiers

[Pascal Le Bris]

Bonjour 
Sans répondre vraiment à la question: pour la chasse aux gros j'utilise 'ncdu' 
qui a la bonne idée de pouvoir exporter le résultat dans un fichier qu'il peut 
rejouer. 
Cordialement 

> De: "David Martin" 
> À: "debian-user-french@lists.debian.org French"
> 
> Envoyé: Mercredi 30 Mars 2022 15:47:42
> Objet: [ HS ] find et les gros fichiers

> Bonjour,
> Je suis en train d'essayer de chercher sur un partage samba d'environ plus de
> 1500 utilisateurs
> (solution libre eole / scribe) ceux qui auraient des gros fichiers.
> Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.

> Pour ça j'utilise la commande find

> find ./a -xdev -type f -size +500M

> Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
> est-ce qu'il est possible que la commande pour le dossier "a" passe en suite 
> au
> répertoire "'b" autrement que de faire un script en l'éxécutant l'une après
> l'autre ?

> J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas comment
> combiner la commande "du -sh" pour qu'elle m'affiche la taille en bout de
> ligne. l'idée est de constituer un fichier à transmettre à ma hiérarchie.

> Je suis preneur de toute idée ;-)

> --
> david martin

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

I seem to have rediscovered Debian bug 889720
xauth crashes when directory name matches host name
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
(Feb 2018)

So, nothing to do with the Bullseye upgrade.
I must have created that directory-matching-hostname in the
process of setting up for the upgrade.

  - Larry

Re: [ HS ] find et les gros fichiers

[David Martin]

Merci Bernard,

Je vais essayer ça



Le mer. 30 mars 2022 à 17:32, Bernard Isambert  a écrit :

> Quelque chose comme :
>
>find ./[a-z] -xdev -type f -size +500M -exec du -h {} \;
>
> vous donne la taille puis le nom de fichier. Si vous voulez inverser, et
> s'il peut y avoir des espaces dans les noms de fichiers, vous pouvez par
> exemple envoyer le résultat à awk en rajoutant :
>
>| awk '{a=$1; $1=""; print $0," ",a}'
>
> Le 30/03/2022 à 15:47, David Martin a écrit :
> > Bonjour,
> >
> > Je suis en train d'essayer de chercher sur un partage samba d'environ
> > plus de 1500 utilisateurs
> > (solution libre eole / scribe) ceux qui auraient des gros fichiers.
> > Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.
> >
> > Pour ça j'utilise la commande find
> >
> > find ./a -xdev -type f -size +500M
> >
> > Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
> > est-ce qu'il est possible que la commande pour le dossier "a" passe en
> > suite au répertoire "'b" autrement que de faire un script en
> > l'éxécutant l'une après l'autre ?
> >
> > J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas
> > comment combiner la commande "du -sh"  pour qu'elle m'affiche la
> > taille en bout de ligne. l'idée est de constituer un fichier à
> > transmettre à ma hiérarchie.
> >
> > Je suis preneur de toute idée ;-)
> >
> >
> >
> > --
> > david martin
> >
>
> --
> Bernard.
> 25 ans d'utilisation de Debian. Comme le temps passe...
>
>

-- 
david martin

Re: [ HS ] find et les gros fichiers

[David Martin]

Bonjour Didier,

En effet, mais je prefere faire une passe par répertoire, et il y'à des
répertoires que je ne veux pas scruter.

Merci pour ta réponse

Le mer. 30 mars 2022 à 19:48, didier gaumet  a
écrit :

> Le mercredi 30 mars 2022 à 15:50:02 UTC+2, David Martin a écrit :
> > Bonjour,
> >
> > Je suis en train d'essayer de chercher sur un partage samba d'environ
> plus de 1500 utilisateurs
> > (solution libre eole / scribe) ceux qui auraient des gros fichiers.
> > Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.
> >
> > Pour ça j'utilise la commande find
> >
> > find ./a -xdev -type f -size +500M
> >
> > Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
> > est-ce qu'il est possible que la commande pour le dossier "a" passe en
> suite au répertoire "'b" autrement que de faire un script en l'éxécutant
> l'une après l'autre ?
> >
> > J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas
> comment combiner la commande "du -sh"  pour qu'elle m'affiche la taille en
> bout de ligne. l'idée est de constituer un fichier à transmettre à ma
> hiérarchie.
> >
> > Je suis preneur de toute idée ;-)
> >
> >
> >
> > --
> > david martin
>
> Ben en fait, c'est peut-être moi qui ne comprend pas la question :-) mais
> find étant récursif (sinon il ne te retournerait uniquement les gros
> fichiers de la base  de l'arborescence de chaque utilisateur), pourquoi ne
> pas simplement faire:
> find ./ -xdev -type f -size +500M
> ?
>
>

-- 
david martin

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:
> 
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > 
> > > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > > as I can read here [1] network names should be stable.
> > > > > (Stable interface names even when hardware is added or removed)
> > > > 
> > > > > [1] 
> > > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > > 
> > > > Sorry, but you've been lied to.
> > > 
> > > I would see that as a bit strong. A lie is a deliberate action,
> > > knowing the reality rests elesewhere. Good faith and all that :).
> > 
> > Perhaps.
> 
> Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> the truth and peddles false information purposefully?

Calm down. There are many shades between Truth (TM) and Lie (TM).
My take is that this specific shade is failing to admit that the
freedesktop folks set out to solve a generally unsolvable problem.

This is one weakness I see with freedesktop often. They try to
fight complexity with ever more complexity, with the end result
of a more user-unfriendly (because less understandable) system.

Nevertheless I thank freedesktop for keeping X (which I do use
a lot) up and running. It's not that I hate them (much less the
people working there). I'm thankful.

Good intentions, pavements, hell, all that.

But hey, this is my take. I'm not in the mood to wage a war over
it. You get to keep your take, I get to keep mine. We could even
remain friends over that.

> > But once I understood what problem this is trying to solve,
> > and how, I decided I haven't that problem, I have net.ifnames=0 in
> > my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.
> 
> Well done! But, if there isn't any problem for you, why go to this
> trouble? Leaving things as they are would seem not to do any harm.

To what trouble? Adding a boot option to my kernel? The trouble
was to find out which one. After that, I'm a happy camper :)

See, for an anecdote: long time ago (this was Linux kernel 2.0.36)
a group of us customised a distro (yes, it was a Debian. Must
have been around Potato or Woody) for a local hardware vendor.
It was a firewall appliance, with four network cards. One of
the ethernet ports was labelled "Internet", the other three "internal
net".

Guess which kind of problem we faced?

After a dive into the PCI spec, the specs of the motherboard
we used at the time, etc. we reached the conclusion that there
is no way to be sure we know which is which (if you follow the
thread here you'll discover exactly that pattern, years down
the history). PCI slots ain't it, because, at the end, hardware
does what it wants. Things become even worse when devices are
hanging off an USB tree. MACs? Some cards are chamaleons and
can change that [1] on the fly. Some can even have more than
one. Yadda, yadda.

Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".

Can we still be friends?

Cheers

[1] I won't bore you with /that/ anecdote, although it's
   funny :)

-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> > Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> > the truth and peddles false information purposefully?
> 
> Some people get excessively worked up over things like interface names and
> like to throw around strong words for dramatic effect. Just ignore the
> noise.

Somewhat self-referential. I'm not the one getting worked up here ;-)

Let's not quarrel over it. You like your predictable names. I like
mine. Let's Just Get Along (TM) :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 19:31 (UTC-0700):

> Felix Miata wrote:

>> Is the problem avoided if you login via a display manager (gdm, sddm, 
>> lightdm,
>> etc.) instead of using startx?
 
> Beats me.  I don't have any software like that installed.

You could install one. Try LightDM. Uncompressed Size: 852 k, plus whatever 
deps.

> Would they run xauth before or after cd'ing to my home directory?

I don't know the middle of the chains of events that gets an X sessions
started, whether via DM, or startx, only some start and end points. I booted up 
a
Bullseye installation to multi-user.target, logged in, then ran startx, and got 
this:

# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 16 21:23 ..
-rw---  1  33857 Mar 30 20:20 .bash_history
-rw---  1 99 Mar 30 20:23 .Xauthority
-rw-r--r--  1 52 Mar 30 20:23 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:23 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:23 .mcoprc
drwx-- 15   4096 Mar 30 20:23 .
-rw---  1 103873 Mar 30 20:23 .xsession-errors

Next I rebooted to graphical.target, logged in, and got this:
# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 30 20:39 ..
-rw---  1 99 Mar 30 20:49 .Xauthority
-rw-r--r--  1 52 Mar 30 20:49 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:49 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:49 .mcoprc
-rw---  1  34072 Mar 30 20:49 .bash_history
drwx-- 15   4096 Mar 30 20:49 .
-rw---  1  48801 Mar 30 20:49 .xsession-errors
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Tom Browder]

On Wed, Mar 30, 2022 at 19:00 Greg Wooledge  wrote:

> On Wed, Mar 30, 2022 at 06:53:26PM -0500, Tom Browder wrote:
> > I've been following the update guide and only have one apt source.list
> left
> > to handle: buster-backports:


Thanks so much, Greg!

-Tom

Re: Does this happen often with sid?

[Chuck Zmudzinski]

On 3/29/22 3:16 PM, Joe wrote:

On Tue, 29 Mar 2022 14:36:55 -0400
Chuck Zmudzinski  wrote:



I do like synaptic also because it saves a history of all the
changes that it makes to the system.



The apt tools also do this, but in a more user-hostile way. See
/var/log/apt/history.log.

This may be what Synaptic uses, I'm never quite sure of the sharing
between the apt tools.

  


It looks to me like synaptic's history only logs the changes
synaptic makes, while /var/log/apt/history.log logs changes
made by any of the apt tools, including synaptic.

Chuck

Re: Predictable Network Interface Names

[gene heskett]

On Wednesday, 30 March 2022 18:31:36 EDT Michael Stone wrote:
> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
> 
> of course I have
> 
> >Predictable interface names *do* sometimes change.  And when that
> >happens, it's a huge deal, because all of the configuration files are
> >set up for the old name.  Things break, in an extremely visible way.
> 
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
> 
> >This is not some theoretical issue.  This is real.
> 
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
> 
Perhaps because to the OP, it is a big deal, being locked away from the 
info that makes it and easy fix. I'm one that that fairly numerous crowd 
who has suffered thru fixing that, but from reading the mail for 20 some 
years, I've learned that complaining is a waste of time, the coder are 
gonna do it their way regardless of the crowd wanting blood. So I don't, 
until this attitude pushes my button.

Take care and stay well, thats more important than complaining to a stone 
wall today.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Greg Wooledge]

On Wed, Mar 30, 2022 at 06:53:26PM -0500, Tom Browder wrote:
> I've been following the update guide and only have one apt source.list left
> to handle: buster-backports:
> 
> Do I change it to bullseye-backports or just comment the line out?

Comment it out, and only add bullseye-backports (later) if you actually
need them.

Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Tom Browder]

I've been following the update guide and only have one apt source.list left
to handle: buster-backports:

Do I change it to bullseye-backports or just comment the line out?

Thanks.

-Tom

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Felix -

Felix Miata  wrote:
> Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
> etc.) instead of using startx?

Beats me.  I don't have any software like that installed.
Would they run xauth before or after cd'ing to my home directory?

  - Larry

P.S.  Sorry about breaking threading; I can only read this list
via the web.

Re: Predictable Network Interface Names

[Intense Red]

> Some people get excessively worked up over things like interface names
> and like to throw around strong words for dramatic effect. Just ignore
> the noise.

   I've just come to accept that the actual interface name is going to be some 
bizarre name. So I look it up, and then promptly rename it in "/etc/network/
interfaces" like so:

 - - - snip - - -
iface enp18s0f0 inet manual

auto LAN
iface LAN inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.1.1
dns-nameservers 192.168.168.1
dns-search locallan.net
bridge_ports enp18s0f0
 - - - snip - - -

   This uses Debian's bridge-utils package to rename the interface.

   From then on, my machines have an interface named LAN, WAN, DMZ, etc. -- 
all "logical" names and I don't have to deal with enp18s0f0 or enp18s1e0 or 
some such nonsense.


-- 
"When law and morality contradict each other, the citizen has the cruel 
alternative of either losing his moral sense or losing his respect for the 
law." -- Frederic Bastiat, 19th century French author and economist.

Re: Running Steam Proton Games with primusrun

[Paul Johnson]

On Wed, Mar 30, 2022 at 5:41 PM Jonathan Marquardt 
wrote:

> On Tue, Mar 29, 2022 at 01:24:50PM -0500, Paul Johnson wrote:
> > I'd recommend using pvkrun instead of primusrun if available.
>
> Gives me the same error messages :(
>
> >  This looks like you're somehow missing nvidia-glx.
>
> $ apt search nvidia-glx
> Sorting... Done
> Full Text Search... Done
> libegl-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary EGL library
>
> libgles-nvidia1/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary OpenGL|ES 1.x library
>
> libgles-nvidia2/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary OpenGL|ES 2.x library
>
> libglx-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary GLX library
>
> What am i missing?
>

Thing that should not work but almost always works for me:  Mark the nvidia
GL packages for reinstall and let aptitude do its thing, restart and run
pvkrun glxgears to make sure things are working.  If that breaks, try
including the output of pvkrun glxinfo

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 5:32 PM Michael Stone  wrote:

> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
>
> of course I have
>
> >Predictable interface names *do* sometimes change.  And when that happens,
> >it's a huge deal, because all of the configuration files are set up for
> >the old name.  Things break, in an extremely visible way.
>
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
>
> >This is not some theoretical issue.  This is real.
>
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
>

Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in
large part to support mobile computing. Which does not and will never be
valuable on the back-end, the server end, where commerce occurs.

It's what we call a different "use-case".

>

Re: Running Steam Proton Games with primusrun

[Jonathan Marquardt]

On Sun, Mar 27, 2022 at 12:34:07PM -, Curt wrote:
> TL;DR (everything) but this bug?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876033

I am not sure. None of the solutions described there worked for me.

There isn't even a libgl1-nvidia-glx package for bullseye.

Re: Running Steam Proton Games with primusrun

[Jonathan Marquardt]

On Tue, Mar 29, 2022 at 01:24:50PM -0500, Paul Johnson wrote:
> I'd recommend using pvkrun instead of primusrun if available.

Gives me the same error messages :(

>  This looks like you're somehow missing nvidia-glx.

$ apt search nvidia-glx
Sorting... Done
Full Text Search... Done
libegl-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary EGL library

libgles-nvidia1/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary OpenGL|ES 1.x library

libgles-nvidia2/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary OpenGL|ES 2.x library

libglx-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary GLX library

What am i missing?

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:

It's like you haven't even read this thread.


of course I have


Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.


And they also broke before the predictable name scheme! And they can 
break if you lock names to MAC addresses! There are always ways things 
can break. If they break in an extremely visible way that's actually a 
good thing--the impact of simple interface reordering can be much more 
severe. And when they do break, the fix is generally pretty 
straightforward (that is, not such a big deal as to justify the bytes 
wasted complaining about it).



This is not some theoretical issue.  This is real.


It's also real that for the majority of systems it works fine. Why are 
you so invested in denying that reality?

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> For most consumer sytems the interface name matters not one bit, because
> it's auto-discovered on install, will never change, and there's little
> likelihood that another interface will be added.

It's like you haven't even read this thread.

Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.

This is not some theoretical issue.  This is real.

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?


Some people get excessively worked up over things like interface names 
and like to throw around strong words for dramatic effect. Just ignore 
the noise.


We've been over all this before. In general, for server-class systems, 
predictable interface names Just Work. These are the kinds of systems 
mostly likely to have 1) lots of interfaces and 2) a need for 
standardized build profiles. I've got quite a lot of these in 
production, and it works as advertised. One really nice thing this gets 
you that MAC-based renamed interfaces can't (apart from not needing to 
plug hundreds of MAC addresses into config files) is that when a NIC 
goes bad and you pop in a replacement...it has the same name. 

For most consumer sytems the interface name matters not one bit, because 
it's auto-discovered on install, will never change, and there's little 
likelihood that another interface will be added.


Then there's a small sliver of systems whose users like to shuffle 
things around, but for some reason can't stand having to learn anything 
new or change a config file or whatever, so they get unbelievably angry 
about a rather sensible naming scheme and throw out hot words like 
"lies" rather than just getting on with their lives. You'd think they'd 
just set their defaults the way they want them instead of venting on 
mailing lists, but the internet is the internet.

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > 
> > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > as I can read here [1] network names should be stable.
> > > > (Stable interface names even when hardware is added or removed)
> > > 
> > > > [1] 
> > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > 
> > > Sorry, but you've been lied to.
> > 
> > I would see that as a bit strong. A lie is a deliberate action,
> > knowing the reality rests elesewhere. Good faith and all that :).
> 
> Perhaps.

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

> But once I understood what problem this is trying to solve,
> and how, I decided I haven't that problem, I have net.ifnames=0 in
> my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Well done! But, if there isn't any problem for you, why go to this
trouble? Leaving things as they are would seem not to do any harm.

-- 
Brian.

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 04:00:42PM -0500, Nicholas Geovanis wrote:
> Does anyone here know how the BSD-derived "free" unices handle this
> situation?

I haven't used OpenBSD in several years, but the last time I used it,
it went something like this:

The OpenBSD kernel has drivers for lots of different kinds of network
interfaces.  Each driver has a separate concise name.  Some examples:

  ath — Atheros IEEE 802.11a/b/g wireless network device with GPIO
  fxp — Intel EtherExpress PRO/100 10/100 Ethernet device
  ie — Intel i82596 Ethernet device
  rl — Realtek 8129/8139 10/100 Ethernet device

When the kernel boots and does its hardware detection, any devices that
are detected are "claimed" by the appropriate drivers, and given a name
according to the driver which claims it.  E.g. if the system has one
Realtek 8129 interface, that interface will be named "rl0", regardless
of whether it's detected before or after an Intel PRO/100, which is
claimed by the fxp driver and named "fxp0".

As long as there's only one interface claimed by each driver, there will
never be any unpredictability in the names.

I'm not sure how it handles the naming when there are two or more
interfaces claimed by the same driver.  They'll be called "rl0" and "rl1"
for example, but I don't know how it determines which one gets which
name.

double boot quand y'a deja 4 partoches primaires

[hamster]

Salut.

Je viens de nouveau vers vous pour encore un autre ordi. La il s'agit de 
faire un double boot, le souci c'est que le windows 10 déjà présent a 
été installé en mode légacy et qu'il y a déjà 4 partitions primaires de 
faites :

- une partition de 1 Go en NTFS avec le label "SYSTEM"
- une partition de 448 Go en NTFS avec le label "Windows"
- une partition de 14 Go en NTFS avec le label "HP_RECOVERY"
- une partition de 2 Go en FAT32 avec le label "HP_TOOLS"

Le souci n'est pas le manque de place : la grosse partition contenant 
windows est très peu utilisée et je pourrais sans problème la réduire 
pour faire de la place a linux.


Le souci c'est que c'est installé en mode légacy, donc avec un table de 
partitions au format DOS, donc limitée a 4 partitions. Et y'a déjà 4 
partitons primaires.


Si je réduis la grosse partition windows, je pourrai pas créer d'autres 
partitions dans la place vide parce que le nombre maximum est déjà atteint.


Si je supprime une partition pour avoir une place libre dans la table 
des partitions et pouvoir faire une partition étendue, je bouzille une 
fonctionnalité présente.


Si quelqu'un a une idée miraculeuse je suis preneur.

Dans l'optique de supprimer une partition, laquelle me conseillez vous ?

Merci pour vos lumières.

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 2:15 PM Brian  wrote:

> On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:
>
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > > Yes.  You've now seen direct evidence of the lie.  I guess I won't
> need
> > > > to post links to the wiki articles that say the same thing you've
> already
> > > > observed.
> > >
> > > I would be interested in a couple of links to the same observations
> > > as given by the OP.
> >
> > <
> https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases
> >
> > tries very hard to avoid mentioning the issue directly, but ultimately
> > has this paragraph down near the bottom of the section:
> >
> >   it turns out even after all this there are still reported cases of
> >   interfaces changing their name on a reboot. All that needs to happen
> >   is that some buggy BIOS (or some new, less buggy version of a driver
> >   module, or systemd's naming policy) changes its mind about some detail
> >   like whether or not your hardware counts as the kind that should have
> >   an ONBOARD name. There are even reports of devices changing their
> >   PCI-port numbering due to other hardware being installed.
> >
> > This links to
> >  which
> > goes into some detail.
>
> Thanks. Very informative. As the second link says:
>
>   The resulting reality is that your PCI based names are only
>   stable if you change no hardware in the system. The moment
>   you change any hardware all bets are off for all hardware.
>
> This, plus your advice, could point the OP to a way forward.
>
> How hardare specific the claim is is not explored.
>
> > I'm sure there are many more pages like this one.
> >
> > > Recently, we have had a mail or two about iwd. It uses the kernel
> > > interface wlan0, which broke my /e/n/i. In the end I went with the
> > > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > > rather than fighting iwd.
> >
> > Wireless interfaces are not my strong suit.  I don't have any advice
> > for those.
>
> I only mentioned what I did bcause, om the whole, I am prepared to
> accept interface renaming. The vast majority of users will not notice
> that it has taken place.
>

Does anyone here know how the BSD-derived "free" unices handle this
situation?
And how about free-ish Oracle/Solaris?
And AIX running on Intel hard/firmware?

-- 
> Brian.
>
>

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 08:57 (UTC-0700):

> The xauth segfault is definitely real and
> a problem for me.

Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
etc.) instead of using startx?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Potential DNS leak with Wireguard + iwd + resolvconf

[Celejar]

Hi,

My wireless interface is controlled via iwd
(EnableNetworkConfiguration=true, NameResolvingService=resolvconf), and
I have a wireguard VPN used to remotely access my private network,
managed via e/n/i / ifupdown (using wg-quick).
In /etc/wireguard/wg0.conf, I have a "DNS=xxx.xxx.xxx.xxx" line,
pointing to a nameserver I run within my private network (reachable
through the wireguard tunnel).

When I connect to a wireless network (using DHCP,
handled by iwd, as above), /etc/resolv.conf gets populated with the
standard:

nameserver nnn.nnn.nnn.nnn
search a.b.c

When I then do "ifup wg0", my specified nameserver xxx.xxx.xxx.xxx is
*prepended* to the above lines, so I end up with the following
in /etc/resolv.conf:

nameserver xxx.xxx.xxx.xxx
nameserver nnn.nnn.nnn.nnn
search a.b.c

This seems wrong, and a potentially serious DNS leak: if my nameserver
xxx.xxx.xxx.xxx ever goes down, then nameserver nnn.nnn.nnn.nnn will be
automatically queried, which may be undesirable.

My understanding is that the VPN configuration should be *replacing* the
pre-VPN /etc/resolv.conf, rather then *prepending* the new nameserver to
it. Am I misunderstanding things, have I misconfigured things, or is
this indeed a (serious) bug?

-- 
Celejar

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> 
> > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > as I can read here [1] network names should be stable.
> > > (Stable interface names even when hardware is added or removed)
> > 
> > > [1] 
> > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > 
> > Sorry, but you've been lied to.
> 
> I would see that as a bit strong. A lie is a deliberate action,
> knowing the reality rests elesewhere. Good faith and all that :).

Perhaps. But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[Dan Ritter]

Greg Wooledge wrote: 
> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > That's good advice, but are MAC addresses memorable?
> 
> Doesn't matter.  You can choose a memorable name.  The MAC address is
> simply the data point you place in the config file, so the system knows
> this is the interface you're talking about.
> 
> unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> [Match]
> MACAddress=18:60:24:77:5c:ec
> 
> [Link]
> Name=lan0
> 
> That's what I'm using.  Of course, this relies on the MAC address being
> consistent across boots.  I've heard of some cases where this isn't
> true, but I believe those cases involved removable devices (USB network
> interfaces or similar).

Some NICs can have their MAC addresses changed permanently.

There were at least a few terrible NICs in history where an
entire production run got the same MAC address assigned.

Most NICs can have their MAC addresses reassigned after boot,
which will almost always be reset on next power cycle.

lan0 is a good name. I like names like "internal" and "dmz" and  "internet"
or "cogent" and "level3" -- either functional descriptors or
where their other ends are connected.

-dsr-

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 21:15, Brian a écrit :

= which

goes into some detail.

Thanks. Very informative. As the second link says:

   The resulting reality is that your PCI based names are only
   stable if you change no hardware in the system. The moment
   you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.



I also got a name change with an upgrade (I do not remember wether it 
was kernel, systemd or udev).


SInce interfaces where combined in a bond, imagine the mess...

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > > to post links to the wiki articles that say the same thing you've already
> > > observed.
> > 
> > I would be interested in a couple of links to the same observations
> > as given by the OP.
> 
> 
> tries very hard to avoid mentioning the issue directly, but ultimately
> has this paragraph down near the bottom of the section:
> 
>   it turns out even after all this there are still reported cases of
>   interfaces changing their name on a reboot. All that needs to happen
>   is that some buggy BIOS (or some new, less buggy version of a driver
>   module, or systemd's naming policy) changes its mind about some detail
>   like whether or not your hardware counts as the kind that should have
>   an ONBOARD name. There are even reports of devices changing their
>   PCI-port numbering due to other hardware being installed.
> 
> This links to
>  which
> goes into some detail.

Thanks. Very informative. As the second link says:

  The resulting reality is that your PCI based names are only
  stable if you change no hardware in the system. The moment
  you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.

How hardare specific the claim is is not explored.
 
> I'm sure there are many more pages like this one.
> 
> > Recently, we have had a mail or two about iwd. It uses the kernel
> > interface wlan0, which broke my /e/n/i. In the end I went with the
> > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > rather than fighting iwd.
> 
> Wireless interfaces are not my strong suit.  I don't have any advice
> for those.

I only mentioned what I did bcause, om the whole, I am prepared to
accept interface renaming. The vast majority of users will not notice
that it has taken place.

-- 
Brian.

Re: Phone

[Paul van der Vlis]

Op 30-03-2022 om 21:01 schreef Paul van der Vlis:


Hmm, en ik zie hier ook al het boven genoemde probleem, met oplossing:
https://github.com/Biktorgj/pinephone_modem_sdk/blob/honister/docs/SETTINGS.md 


Na een "echo -ne "AT+EN_CAT\r" > /dev/ttyUSB2" rinkelt hij...

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Phone

[Paul van der Vlis]

Hoi Geert, en anderen,

Op 30-03-2022 om 19:44 schreef Geert Stappers:

On Wed, Mar 30, 2022 at 02:41:08PM +0200, Paul van der Vlis wrote:

Op 28-03-2022 om 22:58 schreef Koen Wybo:

hoe zijn jullie ervaringen met pinephone en mobian?
Mijn smartphone is zo langzaam naar de laatste adem aan het happen en
ik ben op zoek naar een linux-alternatief of een duurzaam alternatief
(fairphone).


Ik heb een beetje ervaring met de Pinephone en Mobian. Ik heb de telefoon
vrij lang gehad naast een andere telefoon, met als gevolg dat ik hem bijna
niet gebruikte. Toen ging de andere telefoon ongeveer een maand geleden
kapot, sindsdien gebruik ik de Pinephone.

Ik werk vooral thuis, en thuis gebruik ik over het algemeen mijn vaste lijn.
Normaal hangt de Pinephone aan de oplader, en als ik weg ga neem ik hem mee.

Tot nu toe ben ik niet zo enthousiast moet ik zeggen, en dat heeft vooral te
maken met onbetrouwbaarheid in de praktijk, misschien dat er iets aan te
doen is. Misschien ligt het alleen aan mijn hardware en heeft een ander er
geen last van.


Het gaat ons lukken om om te gaan met teksten die niet door marketing
zijn geschreven. We gaan bij win-win-situaties uitkomen.

Dat in andere woorden:
Meeste berichten die we krijgen zijn succesverhalen geschreven door
mensen die daar voor betaald krijgen. 


Het kan wellicht ook zijn dat mensen gewoon heel enthousiast zijn. Zelf 
vind ik het ook wel geweldig eigenlijk. Maar ja, hij moet het ook nog 
goed doen wil hij bruikbaar zijn.



Het voelt vreemd om een bericht
te krijgen dat vertelt dat een product toch niet perfect is.
Met de juiste wisselwerking gaat het goed komen.

  

Het is me nu al een paar keer gebeurd dat ik niet bereikbaar was. Soms is
het zo dat ik de telefoon uit mijn zak haal, en deze blijkt dan spontaan
gereboot te zijn. Ik moet dan pincodes ingeven, maar ondertussen was ik niet
bereikbaar. Wellicht is in mijn zak per ongeluk de aan/uit knop ingedrukt
geweest, misschien dat een hoesje of zo zou kunnen helpen.

Verder is het me ook een paar keer gebeurd dat de telefoon overging en ik
hem wou opnemen, maar dat dat niet ging. Het beeld bleef zwart. De enige
optie was dan om te rebooten, en daarmee was het telefoontje weg. In de logs
kon ik daarna dan niet vinden wie me gebeld had.

Wat ik ook gezien heb is een melding op de telefoon dat er geen "voice
capable modem" aanwezig was. Een reboot helpt dan, maar ondertussen was ik
niet bereikbaar.

Verder gebeurd het me soms ook dat ik iemand opbel, maar dat ik niets hoor
rinkelen o.i.d. Gisteren belde ik bijvoorbeeld ergens heen, en pas toen
diegene opnam hoorde ik iets.


Zulke "signalling" komt uit het telefonienetwerk, niet uit een toestel.
Experiment om uit te voeren:
* Bel naar een nederlands nummer en je hoort voordat het gesprek begint
   ring ... ring ... ring ... ring
* Bel naar een engels of iers nummer en je hoort voordat het gesprek begint
   ring ring ... ring ring ... ring ring ... ring ring


Dat kan goed zijn, maar de telefoon moet het ook doorgeven.

Het ging om een vast nummer wat ik gisteren belde. Ik heb net even mijn 
eigen vaste nummer gebeld. Ik hoorde geen "ring  ring ... ring". Ik 
hoorde niets.  Terwijl de telefoon wel overging.


Wat ik overigens niet gemeld had is dat ik de (grotendeels) open source 
modem firmware van Biktor gebruik:

https://github.com/Biktorgj/pinephone_modem_sdk/

Hmm, en ik zie hier ook al het boven genoemde probleem, met oplossing:
https://github.com/Biktorgj/pinephone_modem_sdk/blob/honister/docs/SETTINGS.md

Wat ik hoor van andere gebruikers is dat deze firmware stabieler is dan 
de officiële.



Off-topic:


Ja, ik ken het gevoel van "off topic".  Jon Postel zou zeggen:

   "be conservative in what you send, be liberal in what you accept"


Gelukkig weten we allemaal dat Debian bestaat om er wat mee te doen.
Juist de vele raakvlakken maken dat we niet snel "off topic" zijn.


Inderdaad. Verder is Mobian heel erg Debian-based. Ik hoop dat op een 
gegeven moment alles in Debian zelf zit, op het moment is dat nog niet zo.


Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: Sistema de fichero ntfs...

[Luis]

Hola amigo,Estamos vivos, y podemos saludarnos, como antes :)Sent from my Metro 
By T-Mobile 4G LTE Android Device
 Mensaje original De: Debian  
Fecha: 30/3/22  9:03 a. m.  (GMT-05:00) A: debian-user-spanish@lists.debian.org 
Asunto: Re: Sistema de fichero ntfs... El 29/3/22 a las 12:19, Luis escribió:> 
Hola,> > Me he actualizado mi laptop. Tenía debian 9 e instalé la 11. No tengo 
> repos locales para la 11. Conservo los de la 7.> > Resulta que no tengo 
conexión por cable, solo por datos a través del > móvil mediante zona wifi. 
Estoy tratando de instalar algunas cosas desde > el repo de la 7 pero no me 
deja montar el disco porque no tengo el > paquete ntfs-3g.> > Recuerdo que 
antes cuando yo había una nueva instalación, podía montar > el repo local en 
modo lectura para actualizar. Luego, uno de los > paquetes que instalaba era el 
ntfs-3g para poder escribir en las > particiones windows pero parece que debían 
11 no permite ahora montar > las particiones ntfs sin antes instalar el 
ntfs-3g.> > Qué puedo hacer para resolver este problema?> > Saludos,> Luis 
Esteban.> > > > Sent from my Metro By T-Mobile 4G LTE Android Device> ¡¡¡Luis, 
tanto tiempoEspero que sigas bien y estos dos años de pandemia no te hayan 
jorobado mucho.En la tarde, me pongo a ver tu tema en detalle. Asumo que siguen 
con el problema del bloqueo a internet en la isla en la Universidad donde 
tenías acceso.Avisame si podés recibir archivos adjuntos y te mando los 
paquetes por acá, si es que no los puedes bajar.JAP

Re: Problemas con Debian 11 (Era: Sistema de fichero ntfs...)

[Luis]

Recibido...En estos momentos estoy instalando según las instrucciones aportadas 
por Camaleon :)Sent from my Metro By T-Mobile 4G LTE Android Device
 Mensaje original De: Camaleón  Fecha: 
30/3/22  9:08 a. m.  (GMT-05:00) A: debian-user-spanish@lists.debian.org 
Asunto: Re: Problemas con Debian 11 (Era: Sistema de fichero ntfs...) El 
2022-03-30 a las 08:06 -0400, luis escribió:> On Wed, 30 Mar 2022 07:33:52 
-0400, Camaleón  wrote:> > > > Ejecuta lspci y manda la 
salida para que veamos el chipset que llevan> > > > > > 0b:00.0 Network 
controller: Broadcom Inc. and subsidiaries BCM4322> > > 802.11a/b/g/n Wireless 
LAN Controller (rev 01)> > > 0c:00.0 Network controller: Broadcom Inc. and 
subsidiaries BCM43228> > > 802.11a/b/g/n> > > > Tienes que instalar el driver 
cerrado de Broadcom «wl», lo tienes en> > los repos non-free (el paquete se 
llama «broadcom-sta-dkms»).> > Así?> > deb http://ftp.debian.org/debian/ 
bullseye-updates main contrib non-free> > o así?> > deb-src 
http://ftp.debian.org/debian/ bullseye-updates main contrib 
non-freeInstrucciones de la wiki de Debian:Installation    Add a "non-free" 
component to /etc/apt/sources.list for your Debian version, for example:    # 
Debian 9 "Stretch"    deb http://deb.debian.org/debian stretch-backports main 
contrib non-free    # Debian 10 "Buster"    deb http://deb.debian.org/debian 
buster-backports main contrib non-free    # Debian 11 "Bullseye"    deb 
http://deb.debian.org/debian bullseye contrib non-free    Update the list of 
available packages. Install the relevant/latest linux-image, linux-headers and 
broadcom-sta-dkms packages:    # apt-get update    # apt-get install 
linux-image-$(uname -r|sed 's,[^-]*-[^-]*-,,') linux-headers-$(uname -r|sed 
's,[^-]*-[^-]*-,,') broadcom-sta-dkms    This will also install the recommended 
wireless-tools package. DKMS will build the wl module for your system.    
(Optional) Rescue if install/build fails in previous step    # apt-get install 
-f    # dpkg-reconfigure broadcom-sta-dkms    (Optional) Check all the built 
DKMS kernel modules. There should be "wl.ko" in the list.    # find 
/lib/modules/$(uname -r)/updates    Unload conflicting modules:    # modprobe 
-r b44 b43 b43legacy ssb brcmsmac bcma    Load the wl module:    # modprobe wl  
  Configure your wireless interface as appropriate. See also known issues. 
Saludos,-- Camaleón 

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 20:39, Greg Wooledge a écrit :


Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.


Be aware that bridge or bond interfaces get their mac address from one 
of the inner inetrface, thus you may have to add a macth (eg a match on 
the driver)

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > to post links to the wiki articles that say the same thing you've already
> > observed.
> 
> I would be interested in a couple of links to the same observations
> as given by the OP.


tries very hard to avoid mentioning the issue directly, but ultimately
has this paragraph down near the bottom of the section:

  it turns out even after all this there are still reported cases of
  interfaces changing their name on a reboot. All that needs to happen
  is that some buggy BIOS (or some new, less buggy version of a driver
  module, or systemd's naming policy) changes its mind about some detail
  like whether or not your hardware counts as the kind that should have
  an ONBOARD name. There are even reports of devices changing their
  PCI-port numbering due to other hardware being installed.

This links to
 which
goes into some detail.

I'm sure there are many more pages like this one.

> Recently, we have had a mail or two about iwd. It uses the kernel
> interface wlan0, which broke my /e/n/i. In the end I went with the
> flow on the basis that wlan0 is stable enough and changed /e/n/i
> rather than fighting iwd.

Wireless interfaces are not my strong suit.  I don't have any advice
for those.

> > 2) If you have multiple ethernet interfaces, or the possibility of this
> >occurring in the future, take control of their names yourself.  Set
> >up systemd.link(5) files to assign a name to each interface based on
> >its MAC address, or some other identifying characteristic.
> 
> That's good advice, but are MAC addresses memorable?

Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link 
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.

Surgical instruments supply

[Saleem Yousaf]

We are manufacturer all kinds dental  surgical and beauty instruments then
supply to the others countries if you are interested in our instruments
please contact with us we can provide you our best quality with good price

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > as I can read here [1] network names should be stable.
> > (Stable interface names even when hardware is added or removed)
> 
> > [1] 
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).
 
> > What I see now is:
> > 
> > When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> > to enp6s3 and back for example.
> 
> Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> to post links to the wiki articles that say the same thing you've already
> observed.

I would be interested in a couple of links to the same observations
as given by the OP.
> 
> For most people, there are two paths forward:
> 
> 1) If your system has exactly one ethernet interface, and if this is not
>likely to change at any point in the future, you can go back to the
>old old way of doing things -- let the kernel assign "eth0" to the
>first interface it finds, "eth1" to the second interface it finds,
>and so on.  Since it will only ever find one interface, that interface
>will always be named "eth0", and you can configure from there.

Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

If you were of the opinion that, with a single interface, a user
gets a stable. *easily memorable* name, I could agree with you.

> 2) If you have multiple ethernet interfaces, or the possibility of this
>occurring in the future, take control of their names yourself.  Set
>up systemd.link(5) files to assign a name to each interface based on
>its MAC address, or some other identifying characteristic.

That's good advice, but are MAC addresses memorable?

-- 
Brian.

Re: [ HS ] find et les gros fichiers

[didier gaumet]

Le mercredi 30 mars 2022 à 15:50:02 UTC+2, David Martin a écrit :
> Bonjour,
> 
> Je suis en train d'essayer de chercher sur un partage samba d'environ plus de 
> 1500 utilisateurs
> (solution libre eole / scribe) ceux qui auraient des gros fichiers.
> Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.
> 
> Pour ça j'utilise la commande find
> 
> find ./a -xdev -type f -size +500M
> 
> Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
> est-ce qu'il est possible que la commande pour le dossier "a" passe en suite 
> au répertoire "'b" autrement que de faire un script en l'éxécutant l'une 
> après l'autre ?
> 
> J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas comment 
> combiner la commande "du -sh"  pour qu'elle m'affiche la taille en bout de 
> ligne. l'idée est de constituer un fichier à transmettre à ma hiérarchie.
> 
> Je suis preneur de toute idée ;-)
> 
> 
> 
> -- 
> david martin

Ben en fait, c'est peut-être moi qui ne comprend pas la question :-) mais find 
étant récursif (sinon il ne te retournerait uniquement les gros fichiers de la 
base  de l'arborescence de chaque utilisateur), pourquoi ne pas simplement 
faire:
find ./ -xdev -type f -size +500M
?

Re: Phone

[Geert Stappers]

On Wed, Mar 30, 2022 at 02:41:08PM +0200, Paul van der Vlis wrote:
> Op 28-03-2022 om 22:58 schreef Koen Wybo:
> > hoe zijn jullie ervaringen met pinephone en mobian?
> > Mijn smartphone is zo langzaam naar de laatste adem aan het happen en
> > ik ben op zoek naar een linux-alternatief of een duurzaam alternatief
> > (fairphone).
> 
> Ik heb een beetje ervaring met de Pinephone en Mobian. Ik heb de telefoon
> vrij lang gehad naast een andere telefoon, met als gevolg dat ik hem bijna
> niet gebruikte. Toen ging de andere telefoon ongeveer een maand geleden
> kapot, sindsdien gebruik ik de Pinephone.
> 
> Ik werk vooral thuis, en thuis gebruik ik over het algemeen mijn vaste lijn.
> Normaal hangt de Pinephone aan de oplader, en als ik weg ga neem ik hem mee.
> 
> Tot nu toe ben ik niet zo enthousiast moet ik zeggen, en dat heeft vooral te
> maken met onbetrouwbaarheid in de praktijk, misschien dat er iets aan te
> doen is. Misschien ligt het alleen aan mijn hardware en heeft een ander er
> geen last van.

Het gaat ons lukken om om te gaan met teksten die niet door marketing
zijn geschreven. We gaan bij win-win-situaties uitkomen.

Dat in andere woorden:
Meeste berichten die we krijgen zijn succesverhalen geschreven door
mensen die daar voor betaald krijgen. Het voelt vreemd om een bericht
te krijgen dat vertelt dat een product toch niet perfect is.
Met de juiste wisselwerking gaat het goed komen.

 
> Het is me nu al een paar keer gebeurd dat ik niet bereikbaar was. Soms is
> het zo dat ik de telefoon uit mijn zak haal, en deze blijkt dan spontaan
> gereboot te zijn. Ik moet dan pincodes ingeven, maar ondertussen was ik niet
> bereikbaar. Wellicht is in mijn zak per ongeluk de aan/uit knop ingedrukt
> geweest, misschien dat een hoesje of zo zou kunnen helpen.
> 
> Verder is het me ook een paar keer gebeurd dat de telefoon overging en ik
> hem wou opnemen, maar dat dat niet ging. Het beeld bleef zwart. De enige
> optie was dan om te rebooten, en daarmee was het telefoontje weg. In de logs
> kon ik daarna dan niet vinden wie me gebeld had.
> 
> Wat ik ook gezien heb is een melding op de telefoon dat er geen "voice
> capable modem" aanwezig was. Een reboot helpt dan, maar ondertussen was ik
> niet bereikbaar.
> 
> Verder gebeurd het me soms ook dat ik iemand opbel, maar dat ik niets hoor
> rinkelen o.i.d. Gisteren belde ik bijvoorbeeld ergens heen, en pas toen
> diegene opnam hoorde ik iets.

Zulke "signalling" komt uit het telefonienetwerk, niet uit een toestel.
Experiment om uit te voeren: 
* Bel naar een nederlands nummer en je hoort voordat het gesprek begint
  ring ... ring ... ring ... ring
* Bel naar een engels of iers nummer en je hoort voordat het gesprek begint
  ring ring ... ring ring ... ring ring ... ring ring


> > Off-topic:

Ja, ik ken het gevoel van "off topic".  Jon Postel zou zeggen:

  "be conservative in what you send, be liberal in what you accept"


Gelukkig weten we allemaal dat Debian bestaat om er wat mee te doen.
Juist de vele raakvlakken maken dat we niet snel "off topic" zijn.


Groeten
Geert Stappers
-- 
https://en.wikipedia.org/wiki/Robustness_principle

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> as I can read here [1] network names should be stable.
> (Stable interface names even when hardware is added or removed)

> [1] 
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

> What I see now is:
> 
> When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> to enp6s3 and back for example.

Yes.  You've now seen direct evidence of the lie.  I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

For most people, there are two paths forward:

1) If your system has exactly one ethernet interface, and if this is not
   likely to change at any point in the future, you can go back to the
   old old way of doing things -- let the kernel assign "eth0" to the
   first interface it finds, "eth1" to the second interface it finds,
   and so on.  Since it will only ever find one interface, that interface
   will always be named "eth0", and you can configure from there.

2) If you have multiple ethernet interfaces, or the possibility of this
   occurring in the future, take control of their names yourself.  Set
   up systemd.link(5) files to assign a name to each interface based on
   its MAC address, or some other identifying characteristic.

Predictable Network Interface Names

[basti]

Hello,

as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)

First of all I have multiple PCIe NIC in a server.

What I see now is:

When I add or remove a PCIe card (USB card) the name is changed from 
enp5s3 to enp6s3 and back for example.


This is not what I understand with "Stable interface names", especially
when it rename multiple nic's.

I guess an empty PCI / PCIe slot is ignored.

Is there a way to not ignore empty slots?

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Esteemed Debian experts and maintainers -

On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote:
> On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> > I just upgraded my first machine from 11.2 to 11.3.
> > xauth fails in the context of startx.
> Workaround: create an empty directory, cd to that, and then startx.
> Something about running startx (and therefore xauth) in my home
> directory has it very confused.

The key command is
  xauth list $(hostname -f):0
When run in my home directory, it yields a Segmentation fault,
and leaves behind two zero-length lock files
  .Xauthority-l .Xauthority-c
that are hard-linked together.  I have to remove those files before
continuing.  When run in an empty subdirectory, that xauth command
(correctly) prints one line with an MIT-MAGIC-COOKIE-1, and
does not segfault.

In the context of /usr/bin/startx (xinit-1.4.0-1), this fault shows up
in line 199-200
authcookie=`xauth list "$displayname" \
| sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
and the lock files left behind prevent the following xauth calls from
functioning.

I can run xauth (xauth-1:1.1-1) under gdb, but until and unless I recompile 
it with debugging symbols, the result is not so helpful:
Program received signal SIGSEGV, Segmentation fault.
__strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
301 ../sysdeps/x86_64/multiarch/strcpy-avx2.S: No such file or directory.
(gdb) bt
#0  __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
#1  0x8cc3 in ?? ()
#2  0x9c8c in ?? ()
#3  0xa53d in ?? ()
#4  0xaa1e in ?? ()
#5  0x8634 in ?? ()
#6  0x77ca0d0a in __libc_start_main (main=0x8480, argc=3,
argv=0x7fffe378, init=, fini=,
rtld_fini=, stack_end=0x7fffe368)
at ../csu/libc-start.c:308
#7  0x870a in ?? ()
(gdb)

This behavior started when I upgraded to Bullseye 11.3 from 11.2.
Until I understand the fault and its trigger better, I can't guarantee 
that wasn't a coincidence.  The xauth segfault is definitely real and
a problem for me.

  - Larry

Re: [ HS ] find et les gros fichiers

[Bernard Isambert]

Quelque chose comme :

  find ./[a-z] -xdev -type f -size +500M -exec du -h {} \;

vous donne la taille puis le nom de fichier. Si vous voulez inverser, et 
s'il peut y avoir des espaces dans les noms de fichiers, vous pouvez par 
exemple envoyer le résultat à awk en rajoutant :


  | awk '{a=$1; $1=""; print $0," ",a}'

Le 30/03/2022 à 15:47, David Martin a écrit :

Bonjour,

Je suis en train d'essayer de chercher sur un partage samba d'environ 
plus de 1500 utilisateurs

(solution libre eole / scribe) ceux qui auraient des gros fichiers.
Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.

Pour ça j'utilise la commande find

find ./a -xdev -type f -size +500M

Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
est-ce qu'il est possible que la commande pour le dossier "a" passe en 
suite au répertoire "'b" autrement que de faire un script en 
l'éxécutant l'une après l'autre ?


J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas 
comment combiner la commande "du -sh"  pour qu'elle m'affiche la 
taille en bout de ligne. l'idée est de constituer un fichier à 
transmettre à ma hiérarchie.


Je suis preneur de toute idée ;-)



--
david martin



--
Bernard.
25 ans d'utilisation de Debian. Comme le temps passe...

Re: installing on Lenovo Ideapad 3

[황병희]

>> Unfortunately now the install doesn't detect an Ethernet card and gives 
>> me a long list of driver choices and I will have to figure out which one 
>> this laptop needs.
>
> Maybe a binary module is missing? Did you try an "unofficial" image with
> non-free components?

+1;

Months ago, the installation was successful. At that time my laptop was
Lenovo ThinkPad E495.

Relative link is:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: Debian 11.3 kernel panics on Epyc 7281 CPU

[Greg Marks]

> Our servers were running Debian 10 without any issues
> We have been trying to do a fresh install of debian 11.3 on exactly the
> same hardware. The install works without any errors but on rebooting the
> system fails with kernel panics
> 
> By adding  init=/bin/bash from within grub works and we can then do things
> like
> 
> mount - o remount /
> cd /etc/init.d
> ./networking start
> ./ssh start
> apt install stress
> stress -c 16 -m 16 --vm-bytes 50GB
> 
> This stress test (without running the normal init process)  runs for hours
> without issues
> 
> We then tried adding systemd.confirm_spawn=true from the boot line in grub
> to try to see at what stage the kernel crashes
> Even if we don't confirm the first systemd spawn and leave the computer
> waiting for an answer for a few minutes the kernel panics
> 
> Has anyone else seen this or have a fix for it?
> The board is a GIGABYTE  R181-Z90-00 Version F01 , the CPU is AMD EPYC
> 7281,the total memory is 1TB from 64GB sticks of Samsung DDR4
> M386A8K40BM2-CTD

I don't have any of this hardware, and I can only speculate as to the
cause of the problem.  Is it, by any chance, related to the following?

   
https://cloudlinux.zendesk.com/hc/en-us/articles/360014242019-AMD-CPU-Unable-to-Boot-after-CPU-Microcode-Update

Debian not booting on EPYC CPUs is an extremely serious problem.
I hope some solution is discovered.

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: mngtmpaddr IP

[Jevin Gala]

It's already disabled for all and eth0 as well.

On Tue, Mar 29, 2022 at 12:53 PM Jevin Gala  wrote:

> Hi,
>
> I am un-able to find how to disable mngtmpaddr IPv6 IP in Debian 11 in a
> KVM VPS.
>
> /proc/sys/net/ipv6/conf/default/use_tempaddr file shows 0 but it's still
> assigning mngtmpaddr IP to the VPS.
>
> --
> Regards,
> Jevin  Gala
>
> Virtualizor support - Softaculous Ltd.
>


-- 
Regards,
Jevin  Gala

Virtualizor support - Softaculous Ltd.

[ HS ] find et les gros fichiers

[David Martin]

Bonjour,

Je suis en train d'essayer de chercher sur un partage samba d'environ plus
de 1500 utilisateurs
(solution libre eole / scribe) ceux qui auraient des gros fichiers.
Les répertoires a, b, c, d, . z héberge les comptes utilisateurs.

Pour ça j'utilise la commande find

find ./a -xdev -type f -size +500M

Ca fonctionne plutot bien, mais je dois à chaque fois changer la lettre,
est-ce qu'il est possible que la commande pour le dossier "a" passe en
suite au répertoire "'b" autrement que de faire un script en l'éxécutant
l'une après l'autre ?

J'aimerai aussi afficher la taille des fichiers, mais je ne vois pas
comment combiner la commande "du -sh"  pour qu'elle m'affiche la taille en
bout de ligne. l'idée est de constituer un fichier à transmettre à ma
hiérarchie.

Je suis preneur de toute idée ;-)



-- 
david martin

Re: Problemas con Debian 11 (Era: Sistema de fichero ntfs...)

[Camaleón]

El 2022-03-30 a las 08:06 -0400, luis escribió:

> On Wed, 30 Mar 2022 07:33:52 -0400, Camaleón  wrote:

> > > > Ejecuta lspci y manda la salida para que veamos el chipset que llevan
> > > 
> > > 0b:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322
> > > 802.11a/b/g/n Wireless LAN Controller (rev 01)
> > > 0c:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228
> > > 802.11a/b/g/n
> > 
> > Tienes que instalar el driver cerrado de Broadcom «wl», lo tienes en
> > los repos non-free (el paquete se llama «broadcom-sta-dkms»).
> 
> Así?
> 
> deb http://ftp.debian.org/debian/ bullseye-updates main contrib non-free
> 
> o así?
> 
> deb-src http://ftp.debian.org/debian/ bullseye-updates main contrib non-free

Instrucciones de la wiki de Debian:


Installation

Add a "non-free" component to /etc/apt/sources.list for your Debian 
version, for example:

# Debian 9 "Stretch"
deb http://deb.debian.org/debian stretch-backports main contrib non-free

# Debian 10 "Buster"
deb http://deb.debian.org/debian buster-backports main contrib non-free

# Debian 11 "Bullseye"
deb http://deb.debian.org/debian bullseye contrib non-free

Update the list of available packages. Install the relevant/latest 
linux-image, linux-headers and broadcom-sta-dkms packages:

# apt-get update
# apt-get install linux-image-$(uname -r|sed 's,[^-]*-[^-]*-,,') 
linux-headers-$(uname -r|sed 's,[^-]*-[^-]*-,,') broadcom-sta-dkms

This will also install the recommended wireless-tools package. DKMS will 
build the wl module for your system.

(Optional) Rescue if install/build fails in previous step

# apt-get install -f
# dpkg-reconfigure broadcom-sta-dkms

(Optional) Check all the built DKMS kernel modules. There should be "wl.ko" 
in the list.

# find /lib/modules/$(uname -r)/updates

Unload conflicting modules:

# modprobe -r b44 b43 b43legacy ssb brcmsmac bcma

Load the wl module:

# modprobe wl

Configure your wireless interface as appropriate. See also known issues. 


Saludos,

-- 
Camaleón 

Re: Sistema de fichero ntfs...

[Debian]

El 29/3/22 a las 12:19, Luis escribió:

Hola,

Me he actualizado mi laptop. Tenía debian 9 e instalé la 11. No tengo 
repos locales para la 11. Conservo los de la 7.


Resulta que no tengo conexión por cable, solo por datos a través del 
móvil mediante zona wifi. Estoy tratando de instalar algunas cosas desde 
el repo de la 7 pero no me deja montar el disco porque no tengo el 
paquete ntfs-3g.


Recuerdo que antes cuando yo había una nueva instalación, podía montar 
el repo local en modo lectura para actualizar. Luego, uno de los 
paquetes que instalaba era el ntfs-3g para poder escribir en las 
particiones windows pero parece que debían 11 no permite ahora montar 
las particiones ntfs sin antes instalar el ntfs-3g.


Qué puedo hacer para resolver este problema?

Saludos,
Luis Esteban.



Sent from my Metro By T-Mobile 4G LTE Android Device




¡¡¡Luis, tanto tiempo
Espero que sigas bien y estos dos años de pandemia no te hayan jorobado 
mucho.


En la tarde, me pongo a ver tu tema en detalle. Asumo que siguen con el 
problema del bloqueo a internet en la isla en la Universidad donde 
tenías acceso.


Avisame si podés recibir archivos adjuntos y te mando los paquetes por 
acá, si es que no los puedes bajar.


JAP

Re: Problemas con Debian 11 (Era: Sistema de fichero ntfs...)

[luis]

On Wed, 30 Mar 2022 07:33:52 -0400, Camaleón  wrote:


El 2022-03-30 a las 07:08 -0400, luis escribió:

Manda a la lista...


Perdón, no me di cuenta.


> Ejecuta lspci y manda la salida para que veamos el chipset que llevan

0b:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322
802.11a/b/g/n Wireless LAN Controller (rev 01)
0c:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228
802.11a/b/g/n


Tienes que instalar el driver cerrado de Broadcom «wl», lo tienes en
los repos non-free (el paquete se llama «broadcom-sta-dkms»).


Así?

deb http://ftp.debian.org/debian/ bullseye-updates main contrib non-free

o así?

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



El driver b43 también podría funcionar, pero por mi experiencia, funciona
mejor (más estable) el cerrado.


Este es el que siempre instalé con tu ayuda en las versiones anteriores.  
Nunca logré instalar el propietario, por eso siempre mi conexión wifi fue  
intermitente.


--
Saludos,
Luis

Re: Problemas con Debian 11 (Era: Sistema de fichero ntfs...)

[Camaleón]

El 2022-03-30 a las 07:08 -0400, luis escribió:

Manda a la lista...

> ...
> 
> > Ejecuta lspci y manda la salida para que veamos el chipset que llevan
> 
> 0b:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322
> 802.11a/b/g/n Wireless LAN Controller (rev 01)
> 0c:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228
> 802.11a/b/g/n

Tienes que instalar el driver cerrado de Broadcom «wl», lo tienes en 
los repos non-free (el paquete se llama «broadcom-sta-dkms»).

El driver b43 también podría funcionar, pero por mi experiencia, funciona 
mejor (más estable) el cerrado.

https://wiki.debian.org/wl

Saludos,

-- 
Camaleón 

Re: Sistema de fichero ntfs...

[luis]

On Wed, 30 Mar 2022 02:58:13 -0400, Camaleón  wrote:


El 2022-03-29 a las 11:19 -0400, Luis escribió:
Hola,Me he actualizado mi laptop. Tenía debian 9 e instalé la 11. No  
tengo repos locales para la 11. Conservo los de la 7.Resulta que no  
tengo conexión por cable, solo por datos a través del móvil mediante  
zona wifi. Estoy tratando de instalar algunas cosas desde el repo de la  
7 pero no me deja montar el disco porque no tengo el paquete  
ntfs-3g. Recuerdo que antes cuando yo había una nueva instalación,  
podía montar el repo local en modo lectura para actualizar. Luego, uno  
de los paquetes que instalaba era el ntfs-3g para poder escribir en las  
particiones windows pero parece que debían 11 no permite ahora montar  
las particiones ntfs sin antes instalar el ntfs-3g.Qué puedo hacer para  
resolver este problema?Saludos,Luis Esteban.Sent from my Metro By  
T-Mobile 4G LTE Android Device


No le encuentro mucho sentido a tener una versión del sistema operativo
actualizado y con paquetes antiguos, amén de los problemas y conflictos
que puede generarte mezclar paquetes/bibliotecas/módulos de la 7 y la 11.

Un dislate, pero sigamos :-)

Ciertamente, el paquete ntfs ya no se usa en debian, lo han vinculado a
ntfs-3g¹, por lo que tendrás que instalar el paquete ntfs-3g para poder
montar una partición NTFS.


Ya lo tengo instalado, el ntfs-3g :)

--
Saludos,
Luis

Re: installing on Lenovo Ideapad 3 now working

[tomas]

On Wed, Mar 30, 2022 at 11:56:55AM +0200, Thomas Schmitt wrote:

[...]

> For those who do not trust themselves to choose the right /dev/sdX
> i have prepared a script which asks for plugging in the USB stick
> and then uses the newly appeared device file in the output of lsblk.
> 
>   https://wiki.debian.org/XorrisoDdTarget

Nifty, I'll sure have a look into :)

> Have a nice day :)

Likewise & thanks
-- 
t


signature.asc
Description: PGP signature

Re: installing on Lenovo Ideapad 3 now working

[Thomas Schmitt]

Hi,

Andrew M.A. Cater wrote:
> > dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

to...@tuxteam.de wrote:
> Yes, thereabouts. [...]

For those who do not trust themselves to choose the right /dev/sdX
i have prepared a script which asks for plugging in the USB stick
and then uses the newly appeared device file in the output of lsblk.

  https://wiki.debian.org/XorrisoDdTarget

It is meanwhile in Debian Testing
  https://packages.debian.org/unstable/xorriso-dd-target

but can also be downloaded for other Linux systems from
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target.sig

It also unmounts possibly the possibly automounted filesystems on the
USB stick and overwrites a possible GPT backup header at the end of the
device.
Like
  sudo /bin/umount /dev/sdd1
  sudo /bin/umount /dev/sdd2
  sudo /bin/umount /dev/sdd3
  sudo /bin/dd if=/dev/zero of=/dev/'sdd' bs=512 seek='7864318' count=1 
status=none
  sudo /bin/dd if='debian-10.0.0-amd64-netinst.iso' bs=1M of=/dev/'sdd' 
status=progress oflag=dsync ; sync


> The default, 512, is definitely too small for somewhat-more-or-less
> current-ish [1] hardware configurations.

I guess dd is from a time when the drives were so slow that this did
not matter.
There are meanings attributed to the block size which matter with
(at least) conv={block,unblock,sync}. So changing the default bs= might
break very old and venerable scripts.


Have a nice day :)

Thomas

Re: installing on Lenovo Ideapad 3 now working

[tomas]

On Wed, Mar 30, 2022 at 08:43:06AM +, Andrew M.A. Cater wrote:

[...]

> So, something close to:
> 
> Where sdX is the drive your USB shows up as when you do a dmesg 
> 
> dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

Yes, thereabouts. The difference with my proposal is you are using
a 4M buffer size while I had 64k. Not a big deal -- as I said, my
informal measurements once gave a very broad maximum, noticeably
falling off (slowly!) in the 1G region.

The default, 512, is definitely too small for somewhat-more-or-less
current-ish [1] hardware configurations.

Cheers

[1] I always buy refurbished computers :)

-- 
t


signature.asc
Description: PGP signature

Re: installing on Lenovo Ideapad 3 now working

[Andrew M.A. Cater]

On Wed, Mar 30, 2022 at 07:14:39AM +0200, to...@tuxteam.de wrote:
> On Tue, Mar 29, 2022 at 08:31:38PM +0100, Brian wrote:
> > On Tue 29 Mar 2022 at 20:57:48 +0200, to...@tuxteam.de wrote:
> 
> [...]
> 
> > > One of the caveats with dd (or cat, or...) is that you might
> > > be tempted to pull the USB stick too early [...]
> 
> > A reasonable observation. However, it should be noted that there has
> > never been a well-documneted case of dd, cat or cp failing. I doubt
> > the OP will provide substantial reproducible evidence, whatever
> > "worked" meant.
> 
> What I have observed, and that is a strong hint, is that if you do
> a simple "dd", it comes back as soon as the stuff is in the buffers
> (they're there exactly for that). If you then do "sync", it takes
> quite a while (especially for USB 2 and larger media).
> 
> If you think things are done as soon as dd comes back and pull the
> stick, chances are that your write is incomplete.
> 
> So my recommendation is still: either do the sync or dd with
> oflag=sync.
> 
> Cheers
> -- 
> t

So, something close to:

Where sdX is the drive your USB shows up as when you do a dmesg 

dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

if is the input file name  - the iso

of is the output file to write to

bs is the block size

oflag=sync will sync each write and flush buffers

status=progress gives you an indication of how far through the process is

dd if=debian-10.12.0-amd64-i386-netinst.iso of=/dev/sdb bs=4M oflag=sync 
status=progress 

is a command I wrote the other day to write the multi-arch netinst to USB
for testing the Buster release.

Hope this helps - all the very best, as ever,

Andy Cater

Re: Out of memory killer misconfigured?

[Tixy]

On Tue, 2022-03-29 at 19:39 +0100, piorunz wrote:
> On 29/03/2022 10:56, Sven Hoexter wrote:
> 
> > The in kernel oom killing is a constant issue. If you look through the
> > lwn.net articles of the past years there is work done to improve the
> > situation, but I believe that's not in a default setup yet.
> 
> Yes it's terrible, how this can be broken so badly? Logic is very simple
> here, even back in Windows XP times it was already solved by Microsoft?
> Just one simple thing, one line of logic:
> 
> 1. If RAM memory usage > 95% AND no swap available AND I/O cache already
> dropped THEN kill most memory hungry process
> 2. Repeat
> 
> Job done!

I may be wrong here, but I seem to remember that something like that
used to happen a long time ago, and it had a habit of picking the X
server as the first thing to kill, not very friendly for GUI users.

-- 
Tixy

Problemas con Debian 11 (Era: Sistema de fichero ntfs...)

[Camaleón]

El 2022-03-29 a las 22:47 -0400, luis escribió:

Cambio el asunto del mensaje.

> Logré conectar la laptop por cable con la conexión de casa de un amigo
> pero... quiero contarles algo:
> 
> 1. Sin querer me he formateado la partición que montaba en /home con todos
> los código y doc de estudio de años! Por favor, algún comando para recuperar
> todo lo perdido  :(

Tienes varias utilidades de recupración de datos, pero recuerda siempre 
ejecutar cualquier operación sobre la partición que contiene los datos 
«en frío», es decir, desde una LiveCD o con la partición SIN montar:

Top 20 Best Linux Data Recovery Tools to Recover Deleted/Corrupted 
Files
https://www.journaldev.com/36900/top-best-linux-data-recovery-tools

> 2. No he podido lograr configurar mis tarjetas wifi. Conservo las notas de
> cómo lo hacía en debian 5, 6 y 7, pero no me sirven acá en la 11, y tampoco
> tengo esos paquetes pues para las versiones anteriores tenía los repo pero
> para la 11 solo cuento con lo que está en internet y por cable.

Ejecuta lspci y manda la salida para que veamos el chipset que llevan

> 3. Instalé gnome y ahora ejecuto 'startx' y no levanta. Algo cambió?

Ufff, y tanto que han cambiado las cosas.
Será por tema de permisos... si quieres levantar GNOME manualmente 
tendrás que editar algún archivo, espera que busco:

https://wiki.archlinux.org/title/GNOME#Manually


Starting

GNOME can be started either graphically with a display manager or 
manually from the console (some features may be missing). The display 
manager included in gnome is GDM.

Note: Support for screen locking (and more) in GNOME is provided by 
GDM. If GNOME is not started with GDM, another screen locker may be 
used. See List of applications/Security#Screen lockers.

Graphically

If you installed the gnome group and want GNOME to start automatically 
on next boot, enable gdm.service. You can then select the desired 
session: GNOME, GNOME Classic (only displayed if gnome-shell-extensions 
is installed), or GNOME on Xorg from the display manager's session 
menu.

If you prefer to start GNOME right away, thereby avoiding a reboot, 
start the aforementioned gdm.service from a graphically unoccupied tty 
instead.

Manually
Xorg sessions

For the GNOME on Xorg session, add to the ~/.xinitrc file (see [1] 
for details):

export XDG_SESSION_TYPE=x11
export GDK_BACKEND=x11
exec gnome-session

For the GNOME Classic session, add to the ~/.xinitrc file:

export XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME
export GNOME_SHELL_SESSION_MODE=classic
exec gnome-session

After editing the ~/.xinitrc file, GNOME can be launched with the 
startx command (see xinitrc for additional details, such as preserving 
the logind session). After setting up the ~/.xinitrc file it can also 
be arranged to Start X at login, e.g. on tty1 by adding to 
.bash_profile:

if [[ -z $DISPLAY && $(tty) == /dev/tty1 ]]; then
  XDG_SESSION_TYPE=x11 GDK_BACKEND=x11 exec startx
fi
***

Saludos,

-- 
Camaleón 

Re: Sistema de fichero ntfs...

[Camaleón]

El 2022-03-29 a las 11:19 -0400, Luis escribió:
> Hola,Me he actualizado mi laptop. Tenía debian 9 e instalé la 11. No tengo 
> repos locales para la 11. Conservo los de la 7.Resulta que no tengo conexión 
> por cable, solo por datos a través del móvil mediante zona wifi. Estoy 
> tratando de instalar algunas cosas desde el repo de la 7 pero no me deja 
> montar el disco porque no tengo el paquete ntfs-3g. Recuerdo que antes cuando 
> yo había una nueva instalación, podía montar el repo local en modo lectura 
> para actualizar. Luego, uno de los paquetes que instalaba era el ntfs-3g para 
> poder escribir en las particiones windows pero parece que debían 11 no 
> permite ahora montar las particiones ntfs sin antes instalar el ntfs-3g.Qué 
> puedo hacer para resolver este problema?Saludos,Luis Esteban.Sent from my 
> Metro By T-Mobile 4G LTE Android Device

No le encuentro mucho sentido a tener una versión del sistema operativo 
actualizado y con paquetes antiguos, amén de los problemas y conflictos 
que puede generarte mezclar paquetes/bibliotecas/módulos de la 7 y la 11.

Un dislate, pero sigamos :-)

Ciertamente, el paquete ntfs ya no se usa en debian, lo han vinculado a 
ntfs-3g¹, por lo que tendrás que instalar el paquete ntfs-3g para poder 
montar una partición NTFS.

Puedes ver los módulos del kernel para los sistemas de archivo 
disponibles con la orden:

ls -l /lib/modules/$(uname -r)/kernel/fs/

Yo sí tengo el ntfs (a secas) pero estoy con Stretch (9) que me parece 
es la última versión del kernel en Debian que lo incorpora.

Conclusión: instala el paquete ntfs-3g para montar localmente la 
partición NTFS o conecta ese disco a un sistema con Windows que lo 
reconozca de forma nativa y compártelo a través de la red.

¹https://wiki.debian.org/NTFS

Saludos,

-- 
Camaleón