Re: Ethernet trouble

[tomas]

On Sat, Feb 01, 2020 at 09:25:06AM +0200, Andrei POPESCU wrote:
> On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> > 
> > Exactly. I do prefer to be prepared for those corner cases and to
> > learn to deal with them. A 99.8% system is, in this context not
> > superior to a 92% system.
> 
> 89,24% of people quoting a statistic just invented it ;)

Except I wasn't quoting any statistic, but just making it up ;-P

Cheers
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 15:00:15, Bob Weber wrote:
> On 1/31/20 1:36 PM, Greg Wooledge wrote:
> > On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> > > First I created  /etc/systemd/network/10-eth0.link using the MAC address 
> > > and
> > > the name eth0.  If the MAC changes then there are other characteristics to
> > > add to the [Match] section to uniquely define the port (see above link).
> > > 
> > > ---
> > > 
> > > root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> > > [Match]
> > > MACAddress=52:54:00:ea:e3:53
> > > 
> > > [Link]
> > > Name=eth0
> > > 
> > > Second I linked the default to /dev/null.
> > > 
> > > -
> > > 
> > > link -s /dev/null /etc/systemd/network/99-Default.link
> > I'm almost 100% sure that should be all lower-case, if you expect
> > it to do anything.  The file it's overriding is 99-default.link
> > (lower-case).
> > 
> > > Parsed configuration file /usr/lib/systemd/network/99-default.link
> > > Skipping empty file: /etc/systemd/network/99-Default.link
> > It's going to use the 99-default.link file because you didn't actually
> > override it.  But since you're mapping explicitly on the MAC address of
> > the interface, it doesn't really matter.

Which proves it's not actually needed ;)
 
> Sorry I missed this.  I used the lower case in all the machines on my
> network  ... m ymind thinks in upper/lower case ... too bad systemd can't.

Not sure what you mean here... filenames on *nix are usually lowercase 
(easier to type?).
 
Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Ethernet trouble

[Andrei POPESCU]

On Vi, 31 ian 20, 23:42:52, to...@tuxteam.de wrote:
> 
> Exactly. I do prefer to be prepared for those corner cases and to
> learn to deal with them. A 99.8% system is, in this context not
> superior to a 92% system.

89,24% of people quoting a statistic just invented it ;)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: [HS] L’insolente santé de Microsoft, dopé par le Cloud

[TScholler]

D'autant que nous savons tous que la plus grosse part de la dette 
provient des entreprises!


Le 30/01/2020 à 14:52, ajh-valmer a écrit :

Tout est dans le sujet, l'article complet :

www.lefigaro.fr/societes/l-insolente-sante-de-microsoft-dope-par-le-cloud-20200130

Sa capitalisation boursière  atteint 1.282 milliards de dollars.
(elle pourrait rembourser la moitié de la dette de la France).

Et dire que Microsoft n'est plus dans les GAFAM, devenu maintenant GAFA.
(au fait, pourquoi... ?).

Heads up: persistent journal has been enabled in systemd

[Michael Biebl]

Hi,

with today's upload of systemd 244.1-2 I finally enabled persistent
journal by default [1]. It has been a long requested feature.

The package will create a directory /var/log/journal on upgrades and new
installs, which enables persistent journal in so called auto mode.

If you decide, that you want to disable the persistent journal again,
you can run:
journalctl --relinquish-var; rm -rf /var/log/journal

Future package updates will respect this choice and not re-create the
directory. You can, of course, also configure this explicitly via the
Storage= option in journald.conf.

Depending on how it goes, I might ask the ftp-masters to lower the
priority of rsyslog from important to optional, so it would no longer be
installed by default on new bullseye installations.
This would avoid, that we store log messages twice on disk.
Users that prefer text logs can of course still install rsyslog by
default (or their syslogger of choice).
Alternative init systems might consider adding a Recommends on a syslog
implementation of their choice or creating a task, which would pull in a
syslogger.

Here are some resources that you might find useful:
- man journald.conf
  https://www.freedesktop.org/software/systemd/man/journald.conf.html#
- man journalctl
  https://www.freedesktop.org/software/systemd/man/journalctl.html#
- man systemd-journald.service
  https://www.freedesktop.org/software/systemd/man/systemd-journald.html#

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717388





signature.asc
Description: OpenPGP digital signature

Re: Ethernet trouble

[ghe]

On 1/31/20 2:42 PM, Reco wrote:

> As a programmer, you should be familiar with it :)

Very. And misconfigs too...

-- 
Glenn English

Re: Ethernet trouble

[David Wright]

On Fri 31 Jan 2020 at 14:31:56 (-0700), ghe wrote:
> On 1/31/20 11:31 AM, Bob Weber wrote:
> 
> > I just ran a test on a VM that I installed last week so it is pretty
> > much up to date.  I ran the command "ip a" which gave me the current
> > undesirable name "enp1s0" and MAC address.
> 
> Check.
> 
> > First I created  /etc/systemd/network/10-eth0.link using the MAC address
> > and the name eth0.  
> 
> Check. (changed the MAC in your cat of the link file and changed the
> name in the interfaces file)
> 
> Rebooted and:
> 
> Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
> Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
> 'exit-code'.
> Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.
> 
> To the best of my knowledge, there is no enp7s0 anymore. Where does:
> 
> [2.445808] e1000e :07:00.0 enp7s0: renamed from eth0
> 
> happen? (dmesg | egrep enp)
> 
> Then there's another line:
> 
> [   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0
> 
> That should have put eth0 back. Current guess is that sometime between
> 2.44 and 12.13, somebody tried to bring up the network interfaces and
> failed.
> 
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Assuming you followed Bob Weber, do you still have a symlink, ie,
link -s /dev/null /etc/systemd/network/99-Default.link
in place? What happens if you boot without it?

> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?
> 
> After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
> shows it active and with the right name and IP. (So does ip a -- I keep
> using ifconfig because that's what's in my scripts and it's what I'm
> used to.)

I really would avoid changing the interface name back to the one
the kernel chose, or any string that the kernel *might* choose;
ie, be original.

Cheers,
David.

Nettoyage du spam : janvier 2020

[Jean-Pierre Giraud]

Bonjour,
Comme nous sommes en février, il est désormais possible de
traiter les archives du mois de janvier 2020 des listes francophones.

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs
pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:19:19PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> >On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> >>because they don't need to know that. This is an issue
> >>mostly for people who know a little bit, want to tinker, and become
> >>irrationally angry when they need to learn something new.)
> >
> >This is insulting. I'll try to explain.
> 
> Also, it's not insulting, it's descriptive. I'll explain.
> 
> >Once I understood it, my reaction was "meh".
> 
> And that's fine. In that case, the interface names *are not an
> issue*. They're just something that's there. If you don't like them,
> you change them. No big deal, not an issue, just a thing that can be
> configured to personal taste.

Kept from your previous post:

  "So does dismising everything new as broken because it fixes
   things you don't care about."

And this is exactly what I perceive as highly insulting: I don't
dismiss "everything new as broken...". It's a classical anti-pattern
in this discussion: "You're just resistant to change" =~ "you have
actually no sensible argument". That seems subtle, but it is
pretty condescendent.

That's not better than...

> But some people don't just say "meh",
> they get angry. They insult the software, they insult the
> developers [...]

And I find that unacceptable too. Especially insulting people.
I'm on record for coming forward and speaking up against that,
too.

I'd hope we could just get along and respect each other.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 12:05:34PM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

[...

> >See? I do care.
> 
> In context, Greg talked about the "common case" [...]

Yes, and I do appreciate highly that the "non-common case" is
still possible.

> >Once I understood it, my reaction was "meh".
> 
> You still seem to not fully understand it. (Specifically, the
> difference between "persistent" names and "predictable" names.

Oh, I sure do.
> One
> of the problems systemd was trying to solve was predictability in
> the absence of persistent storage at boot time, e.g., for initial
> installation, or for remote storage.)

I get that. As I already mentioned, I was confronted with that kind
of problem "back then", Debian 3.1 aka Sarge. "Meh" means... "it
doesn't really solve the problem -- so it's not worth the added
complexity" -- as always, to me.

[...]

> So does dismising everything new as broken because it fixes things
> you don't care about.

Keep that for the next post...

> The bottom line is that in most cases the predictable names "just
> work". In some corner cases something goes wrong, just like in some
> corner cases every preceding system went wrong.

Exactly. I do prefer to be prepared for those corner cases and to
learn to deal with them. A 99.8% system is, in this context not
superior to a 92% system.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Sat, Feb 01, 2020 at 12:28:51AM +0300, Reco wrote:

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:

FWIW, I would never force something to use "eth0" because it makes it
impossible to see at first glance that all of the default behavior has
been overridden.


If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


Actually, eth0 is the default for most VMs. But the point is that 
"predictable names turned off" would be the likely suspicion, and 
"someone forced a particular interface to be named eth0 based on its mac 
address" would be much more unexpected.



I suspect it would also break horribly if you add another NIC that
initializes before the one you're trying to rename to eth0.


... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?


Because that's what someone wanted to do. I'm just saying I wouldn't do 
it.

Re: Ethernet trouble

[Reco]

On Fri, Jan 31, 2020 at 02:31:56PM -0700, ghe wrote:
> So in my current config, eth0 gets changed to enp7s0, ifup is called to
> bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
> interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
> I'm quite used to flaws in software, but lordie...

Using any software (and udev in particular) in a wrong way will give you
wrong results. As a programmer, you should be familiar with it :)

Try this link file:

[Match]
Driver=e1000e
[Link]
MACAddressPolicy=none
NamePolicy=kernel


Long story short, NIC double renaming is wrong, and matching a NIC by
its MAC alone is wrong too.


> And systemd is calling ifup? Which relies on the old interfaces file,
> and systemd relies on additional interface config file(s)?

The software merely does what it's told to do.

Reco

Re: Ethernet trouble

[ghe]

On 1/31/20 11:31 AM, Bob Weber wrote:

> I just ran a test on a VM that I installed last week so it is pretty
> much up to date.  I ran the command "ip a" which gave me the current
> undesirable name "enp1s0" and MAC address.

Check.

> First I created  /etc/systemd/network/10-eth0.link using the MAC address
> and the name eth0.  

Check. (changed the MAC in your cat of the link file and changed the
name in the interfaces file)

Rebooted and:

Jan 31 12:37:56 sbox systemd[1]: Starting Raise network interfaces...
Jan 31 12:37:56 sbox ifup[2147]: ifup: unknown interface enp7s0
Jan 31 12:37:56 sbox systemd[1]: networking.service: Main process
exited, code=exited, status=1/FAILURE
Jan 31 12:37:56 sbox systemd[1]: networking.service: Failed with result
'exit-code'.
Jan 31 12:37:56 sbox systemd[1]: Failed to start Raise network interfaces.

To the best of my knowledge, there is no enp7s0 anymore. Where does:

[2.445808] e1000e :07:00.0 enp7s0: renamed from eth0

happen? (dmesg | egrep enp)

Then there's another line:

[   12.130525] e1000e :07:00.0 eth0: renamed from enp7s0

That should have put eth0 back. Current guess is that sometime between
2.44 and 12.13, somebody tried to bring up the network interfaces and
failed.

So in my current config, eth0 gets changed to enp7s0, ifup is called to
bring up enp7s0, ifup fails because enp7s0 doesn't exist in the
interfaces file, then enp7s0 gets changed back to eth0. As a programmer,
I'm quite used to flaws in software, but lordie...

And systemd is calling ifup? Which relies on the old interfaces file,
and systemd relies on additional interface config file(s)?

After the boot, 'ifup eth0' by hand brings up the interface and ifconfig
shows it active and with the right name and IP. (So does ip a -- I keep
using ifconfig because that's what's in my scripts and it's what I'm
used to.)

-- 
Glenn English

Re: Ethernet trouble

[Reco]

Hi.

On Fri, Jan 31, 2020 at 03:57:44PM -0500, Michael Stone wrote:
> FWIW, I would never force something to use "eth0" because it makes it
> impossible to see at first glance that all of the default behavior has
> been overridden.

If you see a network interface called eth0 in a "modern" Debian it can
mean three things only:

1) Said default behaviour is overridden already.
2) You're using that rare ARM SOC to which x86-centric udev rules just
do not apply, and yes, that particular NIC is not USB-attached.
3) You're in a container, there's no udev here.


> I suspect it would also break horribly if you add another NIC that
> initializes before the one you're trying to rename to eth0.

... Unless you do it the right way by using NamePolicy=kernel. Why
bother with renaming eth0 to eth0 if you can avoid renaming at all?

But the real fun with binding an interface name to a MAC starts once one
discovers 802.1q and tries to use it :) 

Reco

Re: How to configure e-net port again -- SOLVED (sort of)

[Michael Stone]

On Fri, Jan 31, 2020 at 02:57:13PM -0600, Dennis Wicks wrote:

Michael Stone wrote on 1/31/20 2:00 PM:
Do you remember which one you used? Both can be used, but if you try 
to use both at the same time you'll have problems. I'd suggest 
uninstalling one of them, or at the very least make sure that they 
aren't both trying to control the same interface. Neither will 
modify /etc/network/interfaces, so just ignore that.



Michael, thanks for that tip. I got rid of both network managers and 
setup the port in /etc/network/interfaces and that works -- sometimes.


In future if you do want to use /etc/network/interfaces then be aware 
that NetworkManager will ignore anything that's configured there. If you 
never want to use it, though, it doesn't matter if you remove it.


If I try to use IP address reservation in my dhcp server ifup will not 
work. I get this:

- - - - -

root@ichiban:~# ifup enp3s0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/10:7b:44:50:39:8b
Sending on   LPF/enp3s0/10:7b:44:50:39:8b
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.1.2 from 192.168.254.254
DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
DHCPNAK from 192.168.254.254
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 6
DHCPOFFER of 192.168.1.2 from 192.168.254.254
DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
DHCPNAK from 192.168.254.254

- - - - - 
If I remove IP address reservation ifup works and I get the following:
- - - - -

root@ichiban:~# ifup enp3s0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/10:7b:44:50:39:8b
Sending on   LPF/enp3s0/10:7b:44:50:39:8b
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.34.220 from 192.168.254.254
DHCPREQUEST for 192.168.34.220 on enp3s0 to 255.255.255.255 port 67
DHCPACK of 192.168.34.220 from 192.168.254.254
bound to 192.168.34.220 -- renewal in 6833 seconds.
root@ichiban:~#

- - - - -
This machine is running Buster 10 64 bit, I have a machine that is 
running Buster 10 32 bit that works fine with Network Manager Applet 
1.8.22. This machine (64 bit) had 1.8.20 and it did not work. Just 
looped continuously until I deleted the address reservation from the 
dhcp server. When I run ifup it does the same thing so the problem 
must be buried deeper somewhere.


Check the logs on the dhcp server. DHCPNAK means that the server is 
telling the client that the client can't have that IP, that's why it's 
looping. (Because it first offers that IP.) Some possibilities are that 
you have multiple dhcp clients running, the dhcp server thinks the IP 
isn't in the proper subnet (I notice that you're using 192.16.254, 
192.168.1, and 192.168.34--is your netmask consistently 255.255.0.0 or 
/16 everywhere?), you're trying to assign the same IPs both statically 
and dynamically, you've got multiple hosts using the same IP for some 
other reason, or you've got multiple DHCP servers fighting with each 
other.

Re: How to configure e-net port again -- SOLVED (sort of)

[john doe]

On 1/31/2020 9:57 PM, Dennis Wicks wrote:
> Michael Stone wrote on 1/31/20 2:00 PM:
>> On Fri, Jan 31, 2020 at 11:27:06AM -0600, Dennis Wicks wrote:
>>> john doe wrote on 1/31/20 1:00 AM:
 On 1/31/2020 2:48 AM, Dennis Wicks wrote:
> I am running Debian Buster 10, upgrade within the past week.
>
> I tried to change my e-net to use dhcp, which I thought it was but it

 How did you try to change your e-net to use dhcp?

> wasn't picking up all the info from the DHCP server, specifically
> the IP
> addr. Now it doesn't work at all. How can I run through the setup/init
> process that it went through at install to get back at least a working
> communications port.
>

 I would say, revert the change(s)that you have done.

 -- 
 John Doe



>>> I have tried that to no avail. There are two possibilities:
>>>
>>> (1) I don't remember exactly what was there before
>>> (2) One of the two network management programs that are running
>>> changed something that I don't know about.
>>>
>>> In my Notification Area there are two programs that seem to be
>>> controlling the interfaces, and perhaps causing my problems. They are
>>> Network Manager Applet and WICD Network Manager.
>>
>> Do you remember which one you used? Both can be used, but if you try
>> to use both at the same time you'll have problems. I'd suggest
>> uninstalling one of them, or at the very least make sure that they
>> aren't both trying to control the same interface. Neither will modify
>> /etc/network/interfaces, so just ignore that.
>>
>>
> Michael, thanks for that tip. I got rid of both network managers and
> setup the port in /etc/network/interfaces and that works -- sometimes.
>
> If I try to use IP address reservation in my dhcp server ifup will not
> work. I get this:
> - - - - -
>> root@ichiban:~# ifup enp3s0
>> Internet Systems Consortium DHCP Client 4.4.1
>> Copyright 2004-2018 Internet Systems Consortium.
>> All rights reserved.
>> For info, please visit https://www.isc.org/software/dhcp/
>>
>> Listening on LPF/enp3s0/10:7b:44:50:39:8b
>> Sending on   LPF/enp3s0/10:7b:44:50:39:8b
>> Sending on   Socket/fallback
>> DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 8
>> DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
>> DHCPOFFER of 192.168.1.2 from 192.168.254.254
>> DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
>> DHCPNAK from 192.168.254.254
>> DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 6
>> DHCPOFFER of 192.168.1.2 from 192.168.254.254
>> DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
>> DHCPNAK from 192.168.254.254
> - - - - - 
> If I remove IP address reservation ifup works and I get the following:
> - - - - -
>> root@ichiban:~# ifup enp3s0
>> Internet Systems Consortium DHCP Client 4.4.1
>> Copyright 2004-2018 Internet Systems Consortium.
>> All rights reserved.
>> For info, please visit https://www.isc.org/software/dhcp/
>>
>> Listening on LPF/enp3s0/10:7b:44:50:39:8b
>> Sending on   LPF/enp3s0/10:7b:44:50:39:8b
>> Sending on   Socket/fallback
>> DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
>> DHCPOFFER of 192.168.34.220 from 192.168.254.254
>> DHCPREQUEST for 192.168.34.220 on enp3s0 to 255.255.255.255 port 67
>> DHCPACK of 192.168.34.220 from 192.168.254.254
>> bound to 192.168.34.220 -- renewal in 6833 seconds.
>> root@ichiban:~#
> - - - - -
> This machine is running Buster 10 64 bit, I have a machine that is
> running Buster 10 32 bit that works fine with Network Manager Applet
> 1.8.22. This machine (64 bit) had 1.8.20 and it did not work. Just
> looped continuously until I deleted the address reservation from the
> dhcp server. When I run ifup it does the same thing so the problem must
> be buried deeper somewhere.
>
> Thanks for all the help and suggestions!
> Dennis
>

One thing, let the network manager to enable/disable the interface if
you want the CLI use CLI for the network manager that you use.

That would be 'nmcli' for NetworkManager.

--
John Doe

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 03:29:44PM -0500, Bob Weber wrote:

On 1/31/20 1:41 PM, Michael Stone wrote:
   You went through more effort than you needed to. You can turn off
   predictable names by simply booting with net.ifnames=0 on the kernel
   command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= in
   /etc/default/grub and running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago. 
Messed up my firewall rules.  Not very nice to have the internet side connected
to LAN port!   That's when I went through the pain of understanding the systemd
way!


Yup, there's definitely a problem that needed to be solved. But when 
people keep asking for things to go back to the way they used to be 
because the new way is overly complicated, that's how to do it quickly 
and simply.


There's also no need to disable 99-default.link if you add a new .link 
with new rules that override the defaults.


FWIW, I would never force something to use "eth0" because it makes it 
impossible to see at first glance that all of the default behavior has 
been overridden. I suspect it would also break horribly if you add 
another NIC that initializes before the one you're trying to rename to 
eth0. Instead I'd give it a name like "internal0" or somesuch, so it's 
clear that there's manual naming, and as a bonus it's a name that 
includes a description of its intended use.

Re: How to configure e-net port again -- SOLVED (sort of)

[Dennis Wicks]

Michael Stone wrote on 1/31/20 2:00 PM:

On Fri, Jan 31, 2020 at 11:27:06AM -0600, Dennis Wicks wrote:

john doe wrote on 1/31/20 1:00 AM:

On 1/31/2020 2:48 AM, Dennis Wicks wrote:
I am running Debian Buster 10, upgrade within the past 
week.


I tried to change my e-net to use dhcp, which I thought 
it was but it


How did you try to change your e-net to use dhcp?

wasn't picking up all the info from the DHCP server, 
specifically the IP
addr. Now it doesn't work at all. How can I run through 
the setup/init
process that it went through at install to get back at 
least a working

communications port.



I would say, revert the change(s)that you have done.

--
John Doe




I have tried that to no avail. There are two possibilities:

(1) I don't remember exactly what was there before
(2) One of the two network management programs that are 
running changed something that I don't know about.


In my Notification Area there are two programs that seem 
to be controlling the interfaces, and perhaps causing my 
problems. They are Network Manager Applet and WICD Network 
Manager.


Do you remember which one you used? Both can be used, but if 
you try to use both at the same time you'll have problems. 
I'd suggest uninstalling one of them, or at the very least 
make sure that they aren't both trying to control the same 
interface. Neither will modify /etc/network/interfaces, so 
just ignore that.



Michael, thanks for that tip. I got rid of both network 
managers and setup the port in /etc/network/interfaces and 
that works -- sometimes.


If I try to use IP address reservation in my dhcp server 
ifup will not work. I get this:

- - - - -

root@ichiban:~# ifup enp3s0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/10:7b:44:50:39:8b
Sending on   LPF/enp3s0/10:7b:44:50:39:8b
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.1.2 from 192.168.254.254
DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
DHCPNAK from 192.168.254.254
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 6
DHCPOFFER of 192.168.1.2 from 192.168.254.254
DHCPREQUEST for 192.168.1.2 on enp3s0 to 255.255.255.255 port 67
DHCPNAK from 192.168.254.254

- - - - - 
If I remove IP address reservation ifup works and I get the 
following:

- - - - -

root@ichiban:~# ifup enp3s0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/10:7b:44:50:39:8b
Sending on   LPF/enp3s0/10:7b:44:50:39:8b
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 192.168.34.220 from 192.168.254.254
DHCPREQUEST for 192.168.34.220 on enp3s0 to 255.255.255.255 port 67
DHCPACK of 192.168.34.220 from 192.168.254.254
bound to 192.168.34.220 -- renewal in 6833 seconds.
root@ichiban:~# 

- - - - -
This machine is running Buster 10 64 bit, I have a machine 
that is running Buster 10 32 bit that works fine with 
Network Manager Applet 1.8.22. This machine (64 bit) had 
1.8.20 and it did not work. Just looped continuously until I 
deleted the address reservation from the dhcp server. When I 
run ifup it does the same thing so the problem must be 
buried deeper somewhere.


Thanks for all the help and suggestions!
Dennis

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Yvan Masson]

Le 31/01/2020 à 21:24, Jonas Smedegaard a écrit :

Quoting john doe (2020-01-31 20:54:09)

On 1/31/2020 8:37 PM, Yvan Masson wrote:

Le 31/01/2020 à 16:50, john doe a écrit :

On 1/31/2020 10:36 AM, Yvan Masson wrote:

Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :

Le 29/01/2020 à 14:50, Yvan Masson a écrit :


However, before loading preseed.cfg, installer asks for computer
name: I
would like this question to be asked in French and more importantly to
have the keyboard layout configured in French.

I have tried many boot parameters (layout=fr, layout=fr(latin9),
language=fr, language=fr_FR.UTF-8…) but could not find anything
working.

After answering this question, preseed.cfg is loaded so language and
keyboard layout are properly applied.


It's a well known bug unfortunately

I have asked the same question some time ago on the French debian-user
list, and frederic boiteux gave me some interesting clues.

You may search for this thread :

"Configurer un clavier français via preseed"

A similar bug was reported with an Hungarian keyboard, without any
fixes
so far.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368

Regards


Thanks for the information. However I just checked by doing a fresh
installation with BIOS PXE boot, di-netboot-assistant and a preseed file
served by TFTP: locale and keyboard layout are properly applied:
- during install once preseed.cfg is loaded
- after reboot


Yes, because this is delayed after the preseed file is fetched! :)

But if I'm not mistaking, you want to be able to specify the hostname
manually because you have no control over the dhcp server?


Exactly, so I want to preseed most of the question but:
- hostname
- user password

As the hostname and domain are asked before preseed file is fetched, I
tried to use boot options to set the domain (it works) and the locale
(which does not work).

Maybe preseeding has not been designed to use both file and command line
options… I will submit a bug report, please tell me if you think I
shouldn't.



Note that the debian-boot mailing list is responsible for the Debian
installer, before filing a bugreport I would first seak advice there.

Maybe (1) could help you getting what you want.

Actually, what you want, as kernel boot parameter could be 'install '.

1)
https://wiki.debian.org/DebianInstaller/Preseed#Adding_the_preseed_file_to_the_installer.27s_initrd.gz


Well, there is indeed the option of cranking open the install media and
hack its guts - I consider that less of a user option and more of
development related.  But sure...Totally agree :-)


It struck me, however, that perhaps it really isn't locale which is
missing, but instead keyboard setup.  Perhaps something like this
(passed as kernel option, so it is applied early enough!) helps:
https://superuser.com/questions/724294/set-keyboard-layout-in-debian-wheezy-with-preseed
Passing boot options works (see my previous mails), but not always when 
auto=url is also used: "domain" works, but not "locale" nor "keymap".


Yvan



  - Jonas

Re: Can't find a way to preseed keyboard layout for all d-i questions

[john doe]

On 1/31/2020 9:38 PM, Yvan Masson wrote:
>
>
> Le 31/01/2020 à 20:54, john doe a écrit :
>> On 1/31/2020 8:37 PM, Yvan Masson wrote:
>>> Le 31/01/2020 à 16:50, john doe a écrit :
 On 1/31/2020 10:36 AM, Yvan Masson wrote:
> Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :
>> Le 29/01/2020 à 14:50, Yvan Masson a écrit :
>>
>>> However, before loading preseed.cfg, installer asks for computer
>>> name: I
>>> would like this question to be asked in French and more
>>> importantly to
>>> have the keyboard layout configured in French.
>>>
>>> I have tried many boot parameters (layout=fr, layout=fr(latin9),
>>> language=fr, language=fr_FR.UTF-8…) but could not find anything
>>> working.
>>>
>>> After answering this question, preseed.cfg is loaded so language and
>>> keyboard layout are properly applied.
>>
>> It's a well known bug unfortunately
>>
>> I have asked the same question some time ago on the French
>> debian-user
>> list, and frederic boiteux gave me some interesting clues.
>>
>> You may search for this thread :
>>
>> "Configurer un clavier français via preseed"
>>
>> A similar bug was reported with an Hungarian keyboard, without any
>> fixes
>> so far.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368
>>
>> Regards
>
> Thanks for the information. However I just checked by doing a fresh
> installation with BIOS PXE boot, di-netboot-assistant and a preseed
> file
> served by TFTP: locale and keyboard layout are properly applied:
> - during install once preseed.cfg is loaded
> - after reboot

 Yes, because this is delayed after the preseed file is fetched! :)

 But if I'm not mistaking, you want to be able to specify the hostname
 manually because you have no control over the dhcp server?

>>> Exactly, so I want to preseed most of the question but:
>>> - hostname
>>> - user password
>>>
>>> As the hostname and domain are asked before preseed file is fetched, I
>>> tried to use boot options to set the domain (it works) and the locale
>>> (which does not work).
>>>
>>> Maybe preseeding has not been designed to use both file and command line
>>> options… I will submit a bug report, please tell me if you think I
>>> shouldn't.
>>>
>>
>> Note that the debian-boot mailing list is responsible for the Debian
>> installer, before filing a bugreport I would first seak advice there.
>
> Thanks, I will ask there.
>>
>> Maybe (1) could help you getting what you want.
>
> Thanks, but no, I really don't to modify the installer's initrd :-)
>>
>> Actually, what you want, as kernel boot parameter could be 'install
>> '.
> I am sorry but is it documented somewhere?
>>

From (1):

"The "auto" command launches the installation in the automated mode,
where the configuration of hostname, locale and keymap are postponed so
that they can be answered from the preseed file loaded from the network.
You could use "install url=..." but you'd have to answer these questions
manually, regardless of what you have in the preseed config. "

1)
https://wiki.debian.org/DebianInstaller/Preseed#Loading_the_preseeding_file_from_a_webserver

--
John Doe

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Yvan Masson]

Le 31/01/2020 à 20:54, john doe a écrit :

On 1/31/2020 8:37 PM, Yvan Masson wrote:

Le 31/01/2020 à 16:50, john doe a écrit :

On 1/31/2020 10:36 AM, Yvan Masson wrote:

Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :

Le 29/01/2020 à 14:50, Yvan Masson a écrit :


However, before loading preseed.cfg, installer asks for computer
name: I
would like this question to be asked in French and more importantly to
have the keyboard layout configured in French.

I have tried many boot parameters (layout=fr, layout=fr(latin9),
language=fr, language=fr_FR.UTF-8…) but could not find anything
working.

After answering this question, preseed.cfg is loaded so language and
keyboard layout are properly applied.


It's a well known bug unfortunately

I have asked the same question some time ago on the French debian-user
list, and frederic boiteux gave me some interesting clues.

You may search for this thread :

"Configurer un clavier français via preseed"

A similar bug was reported with an Hungarian keyboard, without any
fixes
so far.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368

Regards


Thanks for the information. However I just checked by doing a fresh
installation with BIOS PXE boot, di-netboot-assistant and a preseed file
served by TFTP: locale and keyboard layout are properly applied:
- during install once preseed.cfg is loaded
- after reboot


Yes, because this is delayed after the preseed file is fetched! :)

But if I'm not mistaking, you want to be able to specify the hostname
manually because you have no control over the dhcp server?


Exactly, so I want to preseed most of the question but:
- hostname
- user password

As the hostname and domain are asked before preseed file is fetched, I
tried to use boot options to set the domain (it works) and the locale
(which does not work).

Maybe preseeding has not been designed to use both file and command line
options… I will submit a bug report, please tell me if you think I
shouldn't.



Note that the debian-boot mailing list is responsible for the Debian
installer, before filing a bugreport I would first seak advice there.


Thanks, I will ask there.


Maybe (1) could help you getting what you want.


Thanks, but no, I really don't to modify the installer's initrd :-)


Actually, what you want, as kernel boot parameter could be 'install '.

I am sorry but is it documented somewhere?


1)
https://wiki.debian.org/DebianInstaller/Preseed#Adding_the_preseed_file_to_the_installer.27s_initrd.gz

--
John Doe

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:41 PM, Michael Stone wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off predictable 
names by simply booting with net.ifnames=0 on the kernel command line (you can 
make that permanent by editing GRUB_CMDLINE_LINUX= in /etc/default/grub and 
running update-grub).


The net.ifnames=0 used to work on my 2 port machine but quit about a year ago.  
Messed up my firewall rules.  Not very nice to have the internet side connected 
to LAN port!   That's when I went through the pain of understanding the systemd way!


--


*...Bob*

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Jonas Smedegaard]

Quoting john doe (2020-01-31 20:54:09)
> On 1/31/2020 8:37 PM, Yvan Masson wrote:
> > Le 31/01/2020 à 16:50, john doe a écrit :
> >> On 1/31/2020 10:36 AM, Yvan Masson wrote:
> >>> Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :
>  Le 29/01/2020 à 14:50, Yvan Masson a écrit :
> 
> > However, before loading preseed.cfg, installer asks for computer
> > name: I
> > would like this question to be asked in French and more importantly to
> > have the keyboard layout configured in French.
> >
> > I have tried many boot parameters (layout=fr, layout=fr(latin9),
> > language=fr, language=fr_FR.UTF-8…) but could not find anything
> > working.
> >
> > After answering this question, preseed.cfg is loaded so language and
> > keyboard layout are properly applied.
> 
>  It's a well known bug unfortunately
> 
>  I have asked the same question some time ago on the French debian-user
>  list, and frederic boiteux gave me some interesting clues.
> 
>  You may search for this thread :
> 
>  "Configurer un clavier français via preseed"
> 
>  A similar bug was reported with an Hungarian keyboard, without any
>  fixes
>  so far.
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368
> 
>  Regards
> >>>
> >>> Thanks for the information. However I just checked by doing a fresh
> >>> installation with BIOS PXE boot, di-netboot-assistant and a preseed file
> >>> served by TFTP: locale and keyboard layout are properly applied:
> >>> - during install once preseed.cfg is loaded
> >>> - after reboot
> >>
> >> Yes, because this is delayed after the preseed file is fetched! :)
> >>
> >> But if I'm not mistaking, you want to be able to specify the hostname
> >> manually because you have no control over the dhcp server?
> >>
> > Exactly, so I want to preseed most of the question but:
> > - hostname
> > - user password
> >
> > As the hostname and domain are asked before preseed file is fetched, I
> > tried to use boot options to set the domain (it works) and the locale
> > (which does not work).
> >
> > Maybe preseeding has not been designed to use both file and command line
> > options… I will submit a bug report, please tell me if you think I
> > shouldn't.
> >
> 
> Note that the debian-boot mailing list is responsible for the Debian
> installer, before filing a bugreport I would first seak advice there.
> 
> Maybe (1) could help you getting what you want.
> 
> Actually, what you want, as kernel boot parameter could be 'install '.
> 
> 1)
> https://wiki.debian.org/DebianInstaller/Preseed#Adding_the_preseed_file_to_the_installer.27s_initrd.gz

Well, there is indeed the option of cranking open the install media and 
hack its guts - I consider that less of a user option and more of 
development related.  But sure...


It struck me, however, that perhaps it really isn't locale which is 
missing, but instead keyboard setup.  Perhaps something like this 
(passed as kernel option, so it is applied early enough!) helps: 
https://superuser.com/questions/724294/set-keyboard-layout-in-debian-wheezy-with-preseed


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Fresh install UEFI debian-10.2.0-amd64-xfce-CD-1 will not boot

[David Christensen]

On 2020-01-29 23:07, Keith Bainbridge wrote:

Good afternoon

I take it that you have booted the .iso and run the installer - on
to a separate usb stick.


Where did you install grub?If by chance it installed on to sda, 
then allowing the PC to just boot should run grub and offer the 
choice of booting debian or win10.


What happens if boot from the .iso and plug the other usb in.   It 
should open thunar and list the contents.


Running gparted from the .iso and looking at the other usb stick may 
show something of interest - like did it set to bootable.  Are there 
boot and efi partitions as well as a system partition - showing about

5G used?


I'm working on instinct, so feel free to ignore me.



On 2020-01-29 23:22, Alexander V. Makartsev wrote:
Here is info about one of my disks, GPT partition table with EFI 
partition, boots fine into UEFI mode without Secure Boot. It's a 
dual-boot setup (Debian 10 + Windows 10) with GRUB bootloader.


Information about partitions from "gdisk" utility: Disk /dev/sdb: 
500118192 sectors, 238.5 GiB Model: KINGSTON Sector size 
(logical/physical): 512/512 bytes Disk identifier (GUID): 
20DF70EC-1097-4EE4-9BBE-569BE071281B Partition table holds up to 128 
entries Main partition table begins at sector 2 and ends at sector 33

First usable sector is 34, last usable sector is 500118158 Partitions
will be aligned on 2048-sector boundaries Total free space is 2669
sectors (1.3 MiB)

Number  Start (sector)End (sector)  Size   Code  Name 1 2048
923647   450.0 MiB   2700  Basic data partition 2 923648
1128447   100.0 MiB   EF00  EFI system partition 3 1128448
1161215   16.0 MiB0C01  Microsoft reserved ... 4 1161216
163842047   77.6 GiB0700  Basic data partition 5 163842048
500117503   160.3 GiB   8300  Debian-system



On 2020-01-30 00:40, didier.gau...@gmail.com wrote:
In your case (USB removable device), perhaps (not sure) you will 
succeed with the --removable or --force-extra-removable options of 
grub-install. There is a similar option in the expert mode of 
installation of Debian at the grub installation step.


I have already run Debian in UEFI (non Legacy mode), GPT and Secure 
Boot with no  problem (Secure Boot mode: briefly, I am using

Insecure Mode).



On 2020-01-30 01:04, Phil Wyett wrote:

Hi,

I am running buster with two disk setup in laptop (PC Specialist - 
Lafite 3) - GPT, (U)EFI and Secure Boot enabled. First disk (NVME) 
is> '/' and second (SSD) is '/home'.


Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors 
Disk model: WDS500G3X0C-00SJG0 Units: sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes I/O size 
(minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk 
identifier: 245E1C83-E8A6-4F79-90E6-BB2020B3E161


Device Start   End   Sectors  Size Type 
/dev/nvme0n1p1  2048   1953791   1951744  953M EFI System 
/dev/nvme0n1p2 914272256 976771071  62498816 29.8G Linux swap 
/dev/nvme0n1p3   1953792 914272255 912318464  435G Linux filesystem


Partition table entries are not in disk order.


Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Disk 
model: Seagate BarraCud Units: sectors of 1 * 512 = 512 bytes Sector 
size (logical/physical): 512 bytes / 512 bytes I/O size 
(minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk 
identifier: 841BBA13-490B-4A02-BB6A-80C088CF51B0


Device Start   End   Sectors   Size Type /dev/sda1   2048 
976771071 976769024 465.8G Linux filesystem


Regards

Phil



On 2020-01-30 16:38, Steve McIntyre wrote:

Unetbootin has caused many difficult support problems over the years,
wasting lots of time for me and other Debian developers. We've worked
very hard to make the installer boot and run on diverse computers,
then unetbootin has broken things for users. We explicitly
disrecommend it for that exact reason.

This is even more important with new features like UEFI and Secure
Boot.

Rufus is a different matter - it has a "DD mode" which*is*  useful
for writing an image to a USB stick unmolested.



On 2020-01-30 16:47, Steve McIntyre wrote:

OK. How exactly have you partitioned the target USB drive? What
files are on the EFI System Partition there? Did you tell the
installer to also install grub to the removable media path? That
would be my first guess for what's missing.




On 2020-01-30 16:47, Steve McIntyre wrote:
You don't need to tell grub-install to use x86_64-efi-signed as a 
target - it should work things out automatically and install shim 
etc. as needed. There is*not*  a modinfo.sh for the signed grub 
packaging as the signed binaries we build for grub are monolithic 
(i.e. no loadable modules allowed).


Thank you, everyone, for the replies.  :-)


Given that the 'grub-install ...' idea did not fix the problem, and also 
made changes to the "buster" stick, I decided it would be best to wipe 
the target USB stick and start over.



Here is the d-i image I started with:

2020-01-30 

Re: How to configure e-net port again

[Michael Stone]

On Fri, Jan 31, 2020 at 11:27:06AM -0600, Dennis Wicks wrote:

john doe wrote on 1/31/20 1:00 AM:

On 1/31/2020 2:48 AM, Dennis Wicks wrote:

I am running Debian Buster 10, upgrade within the past week.

I tried to change my e-net to use dhcp, which I thought it was but it


How did you try to change your e-net to use dhcp?


wasn't picking up all the info from the DHCP server, specifically the IP
addr. Now it doesn't work at all. How can I run through the setup/init
process that it went through at install to get back at least a working
communications port.



I would say, revert the change(s)that you have done.

--
John Doe




I have tried that to no avail. There are two possibilities:

(1) I don't remember exactly what was there before
(2) One of the two network management programs that are running 
changed something that I don't know about.


In my Notification Area there are two programs that seem to be 
controlling the interfaces, and perhaps causing my problems. They are 
Network Manager Applet and WICD Network Manager.


Do you remember which one you used? Both can be used, but if you try to 
use both at the same time you'll have problems. I'd suggest uninstalling 
one of them, or at the very least make sure that they aren't both trying 
to control the same interface. Neither will modify 
/etc/network/interfaces, so just ignore that.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 1:36 PM, Greg Wooledge wrote:

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to
add to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).


Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Sorry I missed this.  I used the lower case in all the machines on my network  
... m ymind thinks in upper/lower case ... too bad systemd can't.  I went back 
and renamed the file to lower case and got this output from the udevadm command.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/eth0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Skipping overridden file '/usr/lib/systemd/network/99-default.link'.
Skipping empty file: /etc/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
eth0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
eth0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
eth0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


New lines:

Skipping overridden file '/usr/lib/systemd/network/99-default.link'

Skipping empty file: /etc/systemd/network/99-default.link


That's more like it.


--


*...Bob*

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Jonas Smedegaard]

Quoting Yvan Masson (2020-01-31 20:37:29)
> Le 31/01/2020 à 16:50, john doe a écrit :
> > On 1/31/2020 10:36 AM, Yvan Masson wrote:
> >> Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :
> >>> Le 29/01/2020 à 14:50, Yvan Masson a écrit :
> >>>
>  However, before loading preseed.cfg, installer asks for computer name: I
>  would like this question to be asked in French and more importantly to
>  have the keyboard layout configured in French.
> 
>  I have tried many boot parameters (layout=fr, layout=fr(latin9),
>  language=fr, language=fr_FR.UTF-8…) but could not find anything working.
> 
>  After answering this question, preseed.cfg is loaded so language and
>  keyboard layout are properly applied.
> >>>
> >>> It's a well known bug unfortunately
> >>>
> >>> I have asked the same question some time ago on the French debian-user
> >>> list, and frederic boiteux gave me some interesting clues.
> >>>
> >>> You may search for this thread :
> >>>
> >>> "Configurer un clavier français via preseed"
> >>>
> >>> A similar bug was reported with an Hungarian keyboard, without any fixes
> >>> so far.
> >>>
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368
> >>>
> >>> Regards
> >>
> >> Thanks for the information. However I just checked by doing a fresh
> >> installation with BIOS PXE boot, di-netboot-assistant and a preseed file
> >> served by TFTP: locale and keyboard layout are properly applied:
> >> - during install once preseed.cfg is loaded
> >> - after reboot
> > 
> > Yes, because this is delayed after the preseed file is fetched! :)
> > 
> > But if I'm not mistaking, you want to be able to specify the hostname
> > manually because you have no control over the dhcp server?
> > 
> Exactly, so I want to preseed most of the question but:
> - hostname
> - user password
> 
> As the hostname and domain are asked before preseed file is fetched, I 
> tried to use boot options to set the domain (it works) and the locale 
> (which does not work).
> 
> Maybe preseeding has not been designed to use both file and command line 
> options… I will submit a bug report, please tell me if you think I 
> shouldn't.

I certainly think you should file this as a bugreport!

Even if this turns out to not be a bug in the code, it seems to be that 
at least it is arguably a bug in the documentation.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Can't find a way to preseed keyboard layout for all d-i questions

[john doe]

On 1/31/2020 8:37 PM, Yvan Masson wrote:
> Le 31/01/2020 à 16:50, john doe a écrit :
>> On 1/31/2020 10:36 AM, Yvan Masson wrote:
>>> Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :
 Le 29/01/2020 à 14:50, Yvan Masson a écrit :

> However, before loading preseed.cfg, installer asks for computer
> name: I
> would like this question to be asked in French and more importantly to
> have the keyboard layout configured in French.
>
> I have tried many boot parameters (layout=fr, layout=fr(latin9),
> language=fr, language=fr_FR.UTF-8…) but could not find anything
> working.
>
> After answering this question, preseed.cfg is loaded so language and
> keyboard layout are properly applied.

 It's a well known bug unfortunately

 I have asked the same question some time ago on the French debian-user
 list, and frederic boiteux gave me some interesting clues.

 You may search for this thread :

 "Configurer un clavier français via preseed"

 A similar bug was reported with an Hungarian keyboard, without any
 fixes
 so far.

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368

 Regards
>>>
>>> Thanks for the information. However I just checked by doing a fresh
>>> installation with BIOS PXE boot, di-netboot-assistant and a preseed file
>>> served by TFTP: locale and keyboard layout are properly applied:
>>> - during install once preseed.cfg is loaded
>>> - after reboot
>>
>> Yes, because this is delayed after the preseed file is fetched! :)
>>
>> But if I'm not mistaking, you want to be able to specify the hostname
>> manually because you have no control over the dhcp server?
>>
> Exactly, so I want to preseed most of the question but:
> - hostname
> - user password
>
> As the hostname and domain are asked before preseed file is fetched, I
> tried to use boot options to set the domain (it works) and the locale
> (which does not work).
>
> Maybe preseeding has not been designed to use both file and command line
> options… I will submit a bug report, please tell me if you think I
> shouldn't.
>

Note that the debian-boot mailing list is responsible for the Debian
installer, before filing a bugreport I would first seak advice there.

Maybe (1) could help you getting what you want.

Actually, what you want, as kernel boot parameter could be 'install '.

1)
https://wiki.debian.org/DebianInstaller/Preseed#Adding_the_preseed_file_to_the_installer.27s_initrd.gz

--
John Doe

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Yvan Masson]

Le 31/01/2020 à 16:50, john doe a écrit :

On 1/31/2020 10:36 AM, Yvan Masson wrote:

Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :

Le 29/01/2020 à 14:50, Yvan Masson a écrit :


However, before loading preseed.cfg, installer asks for computer name: I
would like this question to be asked in French and more importantly to
have the keyboard layout configured in French.

I have tried many boot parameters (layout=fr, layout=fr(latin9),
language=fr, language=fr_FR.UTF-8…) but could not find anything working.

After answering this question, preseed.cfg is loaded so language and
keyboard layout are properly applied.


It's a well known bug unfortunately

I have asked the same question some time ago on the French debian-user
list, and frederic boiteux gave me some interesting clues.

You may search for this thread :

"Configurer un clavier français via preseed"

A similar bug was reported with an Hungarian keyboard, without any fixes
so far.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368

Regards


Thanks for the information. However I just checked by doing a fresh
installation with BIOS PXE boot, di-netboot-assistant and a preseed file
served by TFTP: locale and keyboard layout are properly applied:
- during install once preseed.cfg is loaded
- after reboot


Yes, because this is delayed after the preseed file is fetched! :)

But if I'm not mistaking, you want to be able to specify the hostname
manually because you have no control over the dhcp server?


Exactly, so I want to preseed most of the question but:
- hostname
- user password

As the hostname and domain are asked before preseed file is fetched, I 
tried to use boot options to set the domain (it works) and the locale 
(which does not work).


Maybe preseeding has not been designed to use both file and command line 
options… I will submit a bug report, please tell me if you think I 
shouldn't.


Yvan


I'm kind of lost on what you realy want to have.

--
John Doe

Re: Problem with fish in plasma

[mick crane]

On 2020-01-31 13:24, Kenneth Parker wrote:

Package kio (KDE Input Output Framework), allowing remote access to 
files.
The package description included mention of "ssh (fish)", hence your 
url.


was please to see mc does ssh connections

mick

--
Key ID4BFEBB31

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:

First I created  /etc/systemd/network/10-eth0.link using the MAC address and
the name eth0.  If the MAC changes then there are other characteristics to add
to the [Match] section to uniquely define the port (see above link).

---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


You went through more effort than you needed to. You can turn off 
predictable names by simply booting with net.ifnames=0 on the kernel 
command line (you can make that permanent by editing GRUB_CMDLINE_LINUX= 
in /etc/default/grub and running update-grub).

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 01:31:43PM -0500, Bob Weber wrote:
> First I created  /etc/systemd/network/10-eth0.link using the MAC address and
> the name eth0.  If the MAC changes then there are other characteristics to
> add to the [Match] section to uniquely define the port (see above link).
> 
> ---
> 
> root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
> [Match]
> MACAddress=52:54:00:ea:e3:53
> 
> [Link]
> Name=eth0
> 
> 
> Second I linked the default to /dev/null.
> 
> -
> 
> link -s /dev/null /etc/systemd/network/99-Default.link

I'm almost 100% sure that should be all lower-case, if you expect
it to do anything.  The file it's overriding is 99-default.link
(lower-case).

> Parsed configuration file /usr/lib/systemd/network/99-default.link
> Skipping empty file: /etc/systemd/network/99-Default.link

It's going to use the 99-default.link file because you didn't actually
override it.  But since you're mapping explicitly on the MAC address of
the interface, it doesn't really matter.

Re: Ethernet trouble

[Bob Weber]

On 1/31/20 2:05 AM, ghe wrote:



On Jan 30, 2020, at 04:48 PM, Bob Weber  wrote:
"Example 3. Debugging NamePolicy= assignments" near the bottom of the page at
"https://www.freedesktop.org/software/systemd/man/systemd.link.html;

Yeah. That's one I looked at. The one with the table of the Ethernet speeds and 
duplexity. And the list and descriptions of data that're sometimes needed in 
the file.

I'll look at this again tomorrow, Bob, but I'm really not impressed with the way systemd 
is setting up the Ethernet interfaces. Like I said before, "Counting Ethernet 
interfaces isn't rocket science." But it can be made so if you make things complex 
and spread the config over several dirs and several files, some of which are explained in 
the dox but turn out not to exist on my Buster disk.

Somehow, back in the eth days, the data in Debian's /etc/network/interfaces 
file was enough to get networking going. Then, on an Ethernet network, the 
Ethernet chips pretty well figured out the best speed and duplex all by 
themselves as soon as they connected to something.


This nameing configuration has worked on 5 Debian systems all running updated 
testing.

And counting interfaces has worked for me for a couple decades, on many systems 
and several OSs. But I'll find your earlier email and try systemd one more 
time. It'd be nice for the interface names to be, as systemd calls it, 
'consistent.'

And, FWIF, I appreciate your help and advice...

I just ran a test on a VM that I installed last week so it is pretty much up to 
date.  I ran the command "ip a" which gave me the current undesirable name 
"enp1s0" and MAC address.


First I created  /etc/systemd/network/10-eth0.link using the MAC address and the 
name eth0.  If the MAC changes then there are other characteristics to add to 
the [Match] section to uniquely define the port (see above link).


---

root@debian-ZFS ~ # cat /etc/systemd/network/10-eth0.link
[Match]
MACAddress=52:54:00:ea:e3:53

[Link]
Name=eth0


Second I linked the default to /dev/null.

-

link -s /dev/null /etc/systemd/network/99-Default.link


Next I ran the test command from Example 3 at the above link to see what udevadm 
thinks.


-

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
ID_NET_DRIVER=virtio_net
enp1s0: Config file /etc/systemd/network/10-eth0.link is applied
ethtool: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
enp1s0: Device has name_assign_type=4
Using default interface naming scheme 'v243'.
enp1s0: Policies didn't yield a name, using specified Name=eth0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=eth0
Unload module index
Unloaded link configuration context.


Notice the ID_NET_NAME=eth0 is what I wanted.  Also option to the udevadm 
command /sys/class/net/enp1s0 contains the current undesirable name of the 
interface (enp1s0).


Now I rebooted the VM.  I ran the "ip a" command again.

-
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000

    link/ether 52:54:00:ea:e3:53 brd ff:ff:ff:ff:ff:ff
    inet 192.168.240.228/24 brd 192.168.240.255 scope global dynamic 
noprefixroute eth0

   valid_lft 3550sec preferred_lft 3550sec
    inet6 fe80::5054:ff:feea:e353/64 scope link noprefixroute
   valid_lft forever preferred_lft forever


Just what I wanted.


Now running the udevadm command from before with the old name fails:

SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/enp1s0
Trying to open "/etc/systemd/hwdb/hwdb.bin"...
Trying to open "/etc/udev/hwdb.bin"...
Trying to open "/usr/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/systemd/hwdb/hwdb.bin"...
Trying to open "/lib/udev/hwdb.bin"...
=== trie on-disk ===
tool version:  244
file size:    10287564 bytes
header size 80 bytes
strings    2145012 bytes
nodes  8142472 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Skipping empty file: /etc/systemd/network/99-Default.link
Parsed configuration file 

Re: How to configure e-net port again

[john doe]

On 1/31/2020 6:16 PM, Dennis Wicks wrote:
> Daryl wrote on 1/30/20 7:52 PM:
>> On Thu, 30 Jan 2020 19:48:36 -0600
>> Dennis Wicks  wrote:
>>
>>> I am running Debian Buster 10, upgrade within the past week.
>>>
>>> I tried to change my e-net to use dhcp, which I thought it
>>> was but it wasn't picking up all the info from the DHCP
>>> server, specifically the IP addr. Now it doesn't work at
>>> all. How can I run through the setup/init process that it
>>> went through at install to get back at least a working
>>> communications port.
>>>
>>> Many, many TIA!!
>>> Dennis
>>>
>>
>> What's in /etc/network/interfaces?
>>
>>
>>
>
> A couple of comments, a source cmd for interfaces.d, which is
> empty,another comment, then the following:
>
> auto lo
> iface lo inet loopback
> 
>

That's fine given that you are using a frontend to manage your interfaces.

From one of your other e-mail in this thread, I would strongly suggest
to only use one network manager unless you want to play! :)

So 'purging' 'NetworkManager' or 'wicd' is your first step, if you don't
have the time reinstalling from scratch might be cleaner.

--
John Doe

CVE : Vulnérabilités signalées par mail dans mbox

[TScholler]

Bonjour, j'ai le problème ci-dessous depuis plusieurs jours.

Dans mbox, j'ai ---> https://termbin.com/1nhd ;(

Je ne sais pas trop quel est le problème mais je crois comprendre qu'il 
me signale des vulnérabilités sur des paquets obsolètes mais je ne sais 
pas quoi faire.


J'ai quand même effectué ce qui suit :

1) #update,
2) #rm -rf /var/lib/apt/lists,
3) #update && #upgrade
4) #apt dist-upgrade qui s'est déroulé normalement.

Malheureusement rien n'a changé, j'ai toujours le même contenu dans mbox 
même après un reboot. Quelqu'un-e aurait-il-elle une idée svp?


D'avance merci.
ThS.

Re: How to configure e-net port again

[Kenneth Parker]

On Fri, Jan 31, 2020, 12:27 PM Dennis Wicks  wrote:

> john doe wrote on 1/31/20 1:00 AM:
> > On 1/31/2020 2:48 AM, Dennis Wicks wrote:
> >> I am running Debian Buster 10, upgrade within the past week.
> >>
> >> I tried to change my e-net to use dhcp, which I thought it was but it
> >
> > How did you try to change your e-net to use dhcp?
> >
> >> wasn't picking up all the info from the DHCP server, specifically the IP
> >> addr. Now it doesn't work at all. How can I run through the setup/init
> >> process that it went through at install to get back at least a working
> >> communications port.
> >>
> >
> > I would say, revert the change(s)that you have done.
> >
> > --
> > John Doe
> >
> >
> >
> I have tried that to no avail. There are two possibilities:
>
> (1) I don't remember exactly what was there before
> (2) One of the two network management programs that are
> running changed something that I don't know about.
>
> In my Notification Area there are two programs that seem to
> be controlling the interfaces, and perhaps causing my
> problems. They are Network Manager Applet and WICD Network
> Manager.
>

Network Manager and wicd have been known to fight with each other.

Good luck!

Kenneth Parker

Re: How to configure e-net port again

[Dennis Wicks]

john doe wrote on 1/31/20 1:00 AM:

On 1/31/2020 2:48 AM, Dennis Wicks wrote:

I am running Debian Buster 10, upgrade within the past week.

I tried to change my e-net to use dhcp, which I thought it was but it


How did you try to change your e-net to use dhcp?


wasn't picking up all the info from the DHCP server, specifically the IP
addr. Now it doesn't work at all. How can I run through the setup/init
process that it went through at install to get back at least a working
communications port.



I would say, revert the change(s)that you have done.

--
John Doe




I have tried that to no avail. There are two possibilities:

(1) I don't remember exactly what was there before
(2) One of the two network management programs that are 
running changed something that I don't know about.


In my Notification Area there are two programs that seem to 
be controlling the interfaces, and perhaps causing my 
problems. They are Network Manager Applet and WICD Network 
Manager.

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

because they don't need to know that. This is an issue
mostly for people who know a little bit, want to tinker, and become
irrationally angry when they need to learn something new.)


This is insulting. I'll try to explain.


Also, it's not insulting, it's descriptive. I'll explain.


Once I understood it, my reaction was "meh".


And that's fine. In that case, the interface names *are not an issue*. 
They're just something that's there. If you don't like them, you change 
them. No big deal, not an issue, just a thing that can be configured to 
personal taste. But some people don't just say "meh", they get angry. 
They insult the software, they insult the developers, they rant about 
how all the decisions were stupid. They may explain that there's a 
simple solution that should have been implemented if only the developers 
were smarter or not part of a *conspiracy* to make horrible software. 
Now, for no good reason, a trivial matter like an interface name has 
become "an issue". If that's not you--great!--there's no need to be 
insulted because it must not have been about you.


Even at their worst the debian lists are actually pretty good. But you 
might be surprised at the level of vitriol that developers can get over 
what are really unimportant matters in the grand scheme of things. If 
you aren't the kind to get angry about interface names you might be 
surprised that developers actually get death threats over such trivial 
nonsense. Anyway, that's how I define "an issue" vs "a configurable 
default".

Re: How to configure e-net port again

[Dennis Wicks]

Daryl wrote on 1/30/20 7:52 PM:

On Thu, 30 Jan 2020 19:48:36 -0600
Dennis Wicks  wrote:


I am running Debian Buster 10, upgrade within the past week.

I tried to change my e-net to use dhcp, which I thought it
was but it wasn't picking up all the info from the DHCP
server, specifically the IP addr. Now it doesn't work at
all. How can I run through the setup/init process that it
went through at install to get back at least a working
communications port.

Many, many TIA!!
Dennis



What's in /etc/network/interfaces?





A couple of comments, a source cmd for interfaces.d, which 
is empty,another comment, then the following:


auto lo
iface lo inet loopback

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
>The primary drawback of this method is that in the common case of a
>single-user home desktop system with a single NIC, the name "eth0" is
>expected to Just Work for whatever NIC happens to be in the system at
>the time.

It's also fundamentally unpredictable for the same reason that you
can't just rely on the kernel name in the first place [...]



to work around. (And really, in the single user/single nic desktop
case, the user doesn't even *care* if the installer configures eth0
or foo11


See? I do care.


In context, Greg talked about the "common case". In the common case, for 
the purpose of actually designing an OS, the user doesn't care. In your 
particular case, for aesthetic reasons or whatever, you care. That's not 
the common case, that's the you case. The common case is that the 
installer configures the network and then it never gets touched again. 
The common case is that the user probably doesn't even know what the 
interface name is, or thinks it's something like "my wireless card", 
because in the common case the user shouldn't have to know.



When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".


You still seem to not fully understand it. (Specifically, the difference 
between "persistent" names and "predictable" names. One of the problems 
systemd was trying to solve was predictability in the absence of 
persistent storage at boot time, e.g., for initial installation, or for 
remote storage.)



but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.


Solaris did it for reasons. Eventually linux tried to fill roles which 
required the same sort of solution for the same sort of reasons. "I 
don't want to" isn't a rational argument that anyone can address. If you 
just don't want to do it, then ok, but why share that with everyone?



Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.


So does dismising everything new as broken because it fixes things you 
don't care about.


The bottom line is that in most cases the predictable names "just work". 
In some corner cases something goes wrong, just like in some corner 
cases every preceding system went wrong. For the predictable scheme the 
most likely thing to go wrong is that you've got a system whose firmware 
is broken. Unfortunately that's really hard to fix. On the bright side 
there are workarounds and alternatives for those who need them or for 
particular use cases which aren't well suited to the defaults.


If you have some unusual requirement where you want the name to be one 
specific thing and you'll be unhappy if it's anything else, well, that 
can also be achieved! But it's certainly not something that needs to 
drive the common case defaults.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 11:05:32AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> > I see, thanks. I must admit that I don't know very much about how
> > systemd names network interfaces. In practice, what I get to see
> > roughly follows the known conventions (bus number, etc).
> > 
> > Udev is/was just a mechanism to implement those conventions. Or
> > different ones.
> 
> > Is it using something else than udev, these days?
> 
> Yes.
> 
> https://wiki.debian.org/NetworkInterfaceNames
> http://manpages.debian.org/systemd.link

Thanks.

Now I understand the confusion. What's being called "udev" here
was just that one MAC-based "70-persistent-rules" thingy. Nowadays
(Buster, no systemd but udev) Debian ships udev rules implementing
the "predictable" scheme (as it's called in the above wiki). Cf.
75-net-description.rules, for example.

And systemd relies on udev to actually implement its mechanism,
as can be guessed from the man page you link to above.

So -- strictly speaking, "udev" is just the mechanism, the
policy is defined by sets of udev rules (possibly disguised
as .link files whenever systemd is in control) -- and loosely
speaking, whenever folks say here "udev interface names", they
are talking about the now defunct MAC based [1] interface
names once-upon-a-time implemented by a sadly notorious
70-persistent-net.rules or something (the exact spelling
escapes me at the moment).

On my original post: I was talking about those (newer)
"predictable" interface names. I've no use for them.
Someone else might. YMMV. Etc.

Cheers

[1] This one bit me once in the ass. Remember that thing
   where a virtual machine used to roll dice on the mac
   address of its virtual interface?

-- tomás


signature.asc
Description: Digital signature

Re: [HS] Transmission de SSID

[MERLIN Philippe]

Merci, je confirme , effectivement cela marche sans problème.
Philippe Merlin

Le jeudi 30 janvier 2020, 23:57:06 CET max...@mxgo.fr a écrit :
> Bonjour.
> 
> Pour que la transparence soit effective, il faut que l'association
> ESSID+KEY+ENCryption soient identiques.
> 
> Les périphériques s'en rendrons compte car le BSSID est propre à chaque AP
> mais ne les empêcheront pas de se connecter (sauf si le BSSID est
> formellement stipulé dans la conf cliente de nm ou autre).
> Le 30 janv. 2020 15:33, Erwann Le Bras  a écrit 
:
> > bonjour
> > 
> > pour avoir expérimenté lors de la bascule de mon FAI de Bbox à Free : Si
> > le SSID est le même avec le mot de passe identique, les périphériques ne
> > se rendront compte de rien.
> > 
> > cordialement
> > 
> > Le 24/01/2020 à 21:20, MERLIN Philippe a écrit :
> > > Bonjour,
> > > Le problème que je pose ne concerne pas Debian c'est pourquoi j'ai mis
> > > un [HS] devant le sujet . Actuellement J'ai une connexion fibre
> > > arrivant sur une Freebox Mini 4K configurée en mode routeur et servant
> > > de serveur Wifi, ce serveur Wifi à un SSID et un mot de passe pour y
> > > accéder. La Mini 4K est un peu faible comme serveur Wifi , j'ai décidé
> > > de configurer la Mini 4K  en mode Bridge et confier à un routeur Wifi
> > > ce rôle de serveur Wifi le routeur aura le même SSID et le même mot de
> > > passe.
> > > J'aimerai savoir si ces modifications  dans le réseau local passeront
> > > complètement inaperçu des utilisateurs ou devront ils se réinitialiser
> > > complètement ?
> > > Cette question concerne également une imprimante Wifi ?
> > > Merci pour vos avis.
> > > Philippe Merlin

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:53:28PM +0100, to...@tuxteam.de wrote:
> I see, thanks. I must admit that I don't know very much about how
> systemd names network interfaces. In practice, what I get to see
> roughly follows the known conventions (bus number, etc).
> 
> Udev is/was just a mechanism to implement those conventions. Or
> different ones.

> Is it using something else than udev, these days?

Yes.

https://wiki.debian.org/NetworkInterfaceNames
http://manpages.debian.org/systemd.link

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:38:20AM -0500, Greg Wooledge wrote:
> On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> > When the persistent schema came up, I took interest in it, [...]
> 
> > but for me and my installations, it wasn't worth the more
> > complicated names. I still do "sudo ifup eth0" and don't really
> > want to do "sudo ifup &$#*@%#".
> 
> You are NOT talking about the udev persistent naming scheme.  You
> are talking about the systemd predictable naming scheme.
> 
> VERY different creatures.

I see, thanks. I must admit that I don't know very much about how
systemd names network interfaces. In practice, what I get to see
roughly follows the known conventions (bus number, etc).

Udev is/was just a mechanism to implement those conventions. Or
different ones.

> Under the systemd (current) scheme, you can choose whatever name
> you like for the interface.  If you want to call it "red", you can
> call it "red", and then plug a red cable in it.

Is it using something else than udev, these days?

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Can't find a way to preseed keyboard layout for all d-i questions

[john doe]

On 1/31/2020 10:36 AM, Yvan Masson wrote:
> Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :
>> Le 29/01/2020 à 14:50, Yvan Masson a écrit :
>>
>>> However, before loading preseed.cfg, installer asks for computer name: I
>>> would like this question to be asked in French and more importantly to
>>> have the keyboard layout configured in French.
>>>
>>> I have tried many boot parameters (layout=fr, layout=fr(latin9),
>>> language=fr, language=fr_FR.UTF-8…) but could not find anything working.
>>>
>>> After answering this question, preseed.cfg is loaded so language and
>>> keyboard layout are properly applied.
>>
>> It's a well known bug unfortunately
>>
>> I have asked the same question some time ago on the French debian-user
>> list, and frederic boiteux gave me some interesting clues.
>>
>> You may search for this thread :
>>
>> "Configurer un clavier français via preseed"
>>
>> A similar bug was reported with an Hungarian keyboard, without any fixes
>> so far.
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368
>>
>> Regards
>
> Thanks for the information. However I just checked by doing a fresh
> installation with BIOS PXE boot, di-netboot-assistant and a preseed file
> served by TFTP: locale and keyboard layout are properly applied:
> - during install once preseed.cfg is loaded
> - after reboot

Yes, because this is delayed after the preseed file is fetched! :)

But if I'm not mistaking, you want to be able to specify the hostname
manually because you have no control over the dhcp server?

I'm kind of lost on what you realy want to have.

--
John Doe

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 04:32:32PM +0100, to...@tuxteam.de wrote:
> When the persistent schema came up, I took interest in it, [...]

> but for me and my installations, it wasn't worth the more
> complicated names. I still do "sudo ifup eth0" and don't really
> want to do "sudo ifup &$#*@%#".

You are NOT talking about the udev persistent naming scheme.  You
are talking about the systemd predictable naming scheme.

VERY different creatures.

Under the systemd (current) scheme, you can choose whatever name
you like for the interface.  If you want to call it "red", you can
call it "red", and then plug a red cable in it.

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 10:10:25AM -0500, Michael Stone wrote:
> On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:
> >The primary drawback of this method is that in the common case of a
> >single-user home desktop system with a single NIC, the name "eth0" is
> >expected to Just Work for whatever NIC happens to be in the system at
> >the time.
> 
> It's also fundamentally unpredictable for the same reason that you
> can't just rely on the kernel name in the first place [...]

> to work around. (And really, in the single user/single nic desktop
> case, the user doesn't even *care* if the installer configures eth0
> or foo11

See? I do care.

> because they don't need to know that. This is an issue
> mostly for people who know a little bit, want to tinker, and become
> irrationally angry when they need to learn something new.)

This is insulting. I'll try to explain.

I, for one, knew about the inherent problem with the interface
names.

When the persistent schema came up, I took interest in it, since
I had hit the problem quite a few times and well, if someone
solved it, I'd like to know.

Once I understood it, my reaction was "meh".

Sure some progress for totally naive users (which were starting
to use Linux distros more and more, which is a Good Thing), so
it made (a bit of [1]) sense to

 (a) have it as default schema and
 (b) for us, the somewhat experienced folks to understand it,
 to be able to help newbies... 

but for me and my installations, it wasn't worth the more
complicated names. I still do "sudo ifup eth0" and don't really
want to do "sudo ifup &$#*@%#". I had seen those things before
(was it Solaris) and -- oh well.

Now dismissing folks who don't share your opinion on some
shiny new thing as "just resistant to change" or "tinkerers"
is a horrible antipattern. Please don't do that. It leads
to ugly discussions and hurt feelings. Been there, done that.

Cheers

[1] afaik the jury is still out on that, but let's concede
   it, for the sake of argument.

-- tomás


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 10:01:23AM -0500, Greg Wooledge wrote:

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.


It's also fundamentally unpredictable for the same reason that you can't 
just rely on the kernel name in the first place--even on the first 
install, if you have multiple NICs they will sometimes come up in 
a different order. For the single user/single nic desktop this isn't an 
issue, but if you're trying to on a large number of machines, and plug 
the LAN into (for example) the first on-board interface, it is a real 
PITA if sometime's that is eth0 and sometimes it's eth3 (or whatever) 
and that's a *much* harder problem to work around. (And really, in the 
single user/single nic desktop case, the user doesn't even *care* if the 
installer configures eth0 or foo11 because they don't need to know that. 
This is an issue mostly for people who know a little bit, want to 
tinker, and become irrationally angry when they need to learn something 
new.)

Re: Ethernet trouble

[tomas]

On Fri, Jan 31, 2020 at 09:52:29AM -0500, rhkra...@gmail.com wrote:
> On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> > All of this would be, I think, 99% better than what we have now.
> 
> +1 -- sounds good!

Yeah, but it isn't. As Michael points out, most solutions proposed
here have been tried and none is "always good". Mac addresses, for
example, aren't as "fixed" or "stable" as one would make them out
(and actually in some case they are forcibly changed, for privacy
reasons [1]).

Whoever has been admining or near-admining for a while (I've, for
nearly as long as Unix exists) can share a bunch of stories.

Dan, RH -- believe me, you're running in circles :-)

The best one can do is to offer the necessary building blocks to
fix the problem du jour (udev does, for the moment, at least).

Persistent device names, as we know them now, are just the last
(failed) attempt. Some folks like them, some dislike them, I'm
happy & thankful that there's a way to choose with a reasonable
amount of effort.

Cheers

[1] Mobile devices and their WiFi mac address.
-- t


signature.asc
Description: Digital signature

Re: Ethernet trouble

[Greg Wooledge]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:
> Maybe we should ask the OS to actually help, instead of
> "helping" us.
> 
> For example, the OS knows when it is being installed. At install
> time, it could enumerate NICs and assign them permanent names
> based on the MAC addresses: eth0, eth1...
> 
> At any subsequent boot, the OS could then continue to assign the
> same names. If a device appears to be missing, the name is
> skipped. eth3 doesn't become eth2, eth2 just goes missing for
> that boot. This is immensely useful in discovering when a NIC
> has suffered hardware damage or is otherwise not present.

This is basically how the udev persistent-naming scheme worked.
Support for it was officially discontinued in buster.

The primary drawback of this method is that in the common case of a
single-user home desktop system with a single NIC, the name "eth0" is
expected to Just Work for whatever NIC happens to be in the system at
the time.

If the NIC failed and was replaced, the replacement NIC would become eth1,
rather than eth0, and this confused some people.

Prior to the udev thing, when the kernel dynamically assigned names
to interfaces in whatever order they happened to pop up during boot,
replacing a single NIC with a different single NIC would have kept
the name "eth0" the whole time.  This is what many people were expecting,
and what the udev persistent-naming scheme took away.

Now, this is all historic.  Both the pre-udev "whatever you have
gets called whatever I want to call it" scheme, and the udev
persistent-naming scheme, are unsupported.  If you choose to use
them, they may work for you, or they may not.

The currently supported approach is systemd.link(5).  If you want to
assign a name to an interface, you create a file that sets up the
mapping as you wish it to be made.  Usually from the MAC address.

This puts a slightly higher burden of knowledge on the sysadmin, but
I really don't see a better choice.  Anything that tries to magically
do the Right Thing is going to fail in at least one common scenario.
Editing a systemd.link file isn't any harder than editing the udev
persistent rules file, and if you replace a NIC and want to keep the
same name, you'll have to edit one of these files anyway.

Re: Ethernet trouble

[rhkramer]

On Friday, January 31, 2020 09:39:37 AM Dan Ritter wrote:
> All of this would be, I think, 99% better than what we have now.

+1 -- sounds good!

Re: Ethernet trouble

[Michael Stone]

On Fri, Jan 31, 2020 at 09:39:37AM -0500, Dan Ritter wrote:

Michael Stone wrote:

As a programmer you should be concerned with making sure that the packets go
in and out of the correct physical hardware. If the name doesn't relate to
the physical harder that's a harder problem to solve. You (and everyone
else) could reimplement that in software at a higher level, or accept that
this is something the OS should help with.


Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...


It's been tried, and has other problems. (As you trimmed from the 
original email.) 


When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.


Which also has its own problems. (Is it "eth0" the old kernel version or 
"eth0" the renamed version? Don't worry, it's really easy to explain the 
difference to someone having problems on a mailing list.)



All of this would be, I think, 99% better than what we have now.


And yet, it wasn't. :) Maybe with the stuff you described that doesn't 
exist that you think should get written (by someone) it would be better, 
but we don't know since it hasn't been written. Even if it was written 
it wouldn't be reliably available for several kernel & OS releases 
because compatibility and upgrades. 

Really, if there was a simple solution that worked better than the 
existing solution for all cases, it would get used. Since it isn't, 
there may be reasons...

Re: Ethernet trouble

[Dan Ritter]

Michael Stone wrote: 
> As a programmer you should be concerned with making sure that the packets go
> in and out of the correct physical hardware. If the name doesn't relate to
> the physical harder that's a harder problem to solve. You (and everyone
> else) could reimplement that in software at a higher level, or accept that
> this is something the OS should help with.

Maybe we should ask the OS to actually help, instead of
"helping" us.

For example, the OS knows when it is being installed. At install
time, it could enumerate NICs and assign them permanent names
based on the MAC addresses: eth0, eth1...

At any subsequent boot, the OS could then continue to assign the
same names. If a device appears to be missing, the name is
skipped. eth3 doesn't become eth2, eth2 just goes missing for
that boot. This is immensely useful in discovering when a NIC
has suffered hardware damage or is otherwise not present.

When an unrecognized device is plugged in, whether during runtime or at
boot time, it gets the next sequential permanent name.

Finally, a simple lookup table of MAC to name should be exposed by the
kernel, and saved/loaded in the same way as firewall rules, so that people
who want to change interface name assignments can do so cleanly. The
one caveat is that a process which wants to change the MAC address of
the NIC will have to signal that specifically, rather than just
update the table. When the OS changes the MAC address, e.g. WiFi
MAC randomization, it just updates the table because it knows
what it is doing.

All of this would be, I think, 99% better than what we have now.

-dsr-

Re: Ethernet trouble

[David Wright]

On Thu 30 Jan 2020 at 11:58:47 (-0700), ghe wrote:
> On 1/29/20 7:06 PM, David Wright wrote:
> 
> > These boards, do their PCI addresses have the save bus number but
> > different slot/device numbers? dmesg or kern.log will give you
> > those: they look like NN:DD.F optionally preceded by :, where
> >  is the domain (typically ), NN is the bus, DD the device
> > of slot, F the function(s) provided by that card, eg
> > pci :00:0e.0: [10ec:8139] type 00 class 0x02
> 
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.

?

> I looked at dmesg a bit. I greped it for 'enp' and there was a funny
> joke in the first 2 lines (of the grep output):
> 
> [2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
> [2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

And did you happen upon the boards' addresses?

> So something took the rational Ethernet interface names and,
> intentionally I assume, broke hundreds of lines of code.
> 
> Once I was installing a computer that had a single Ethernet port
> soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
> put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
> mobo, 1 was the card. And it was eth1 no matter which slot it was in.

Yes, but the kernel's choice of eth0 and eth1 may not necessarily be
fixed. My experience with linux in the past was that, with two NICs,
there was no way of ensuring the order in which they were assigned.
With something like a firewall, you could end up with your WAN and LAN
interfaces reversed.

> Or if I put in a sound-card.
> 
> They were named by function, not by bus and slot. As a programmer, I'm
> much more interested in *what* they are, not *where* they are. I
> especially don't need some broken piece of software to rename them.

And take disks. With the proliferation of buses in modern PCs, there's
no guarantee that the machine will boot up and have the system disk
on the usual /dev/sda. My PC in the attic appear to enumerate the legacy
PATA before the SATAs. This laptop enumerates USB sticks in an order
that appears stable, but I have no idea whether it's really a race.

I have read of a case analogous to yours, where booting up a laptop
with a USB stick inserted would demote the internal disk to /dev/sdb.
(I think the internal disk was an SSD.)

> I know I can put them back to the 'inconsistent' names in Grub, and I'll
> be doing that -- and editing the shell scripts.
> 
> > AIUI it's nothing to do with the OS as these decisions are made by
> > the firmware on the mobo. Juggling cards in a mobo can even outwit
> > the BIOS so that the POST won't succeed: I've had mobos where I've
> > had to empty the box, power-up and save the settings, add one card
> > and repeat, add the next and so on, all to get a box with the cards
> > I wanted, located where I wanted them.
> 
> With all the 'puters I've dealt with, I've never seen anything like
> that. If I got one that did that, I'd have sent it back to Amazon and
> bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
> competently written and tested BIOS.

Said attic PC is a Dell Optiplex.

> Besides, we've got UDEV. It allegedly looks at hardware and makes it
> make sense. To do that, it must, I suspect, ignore what the BIOS says
> and scan the bus(es) itself. If it does that, my Ethernet ports would
> have had the same labels, unless somebody renamed them. Would be the
> same too, if they'd just been left alone.

In your case, the sensible thing might be to use the MAC addresses,
assuming you don't change them. These Super Micro thingies could have
an IPMI built in, allowing you to change MACs to your heart's content.

> I'm not looking forward to systemd.emacs.

I got the impression there was an agenda polarising the debate. BTW,
you know who started all this renaming NICs business? Your friends at Dell.

Cheers,
David.

Re: Ethernet trouble

[Michael Stone]

On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:

I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):

[2.181317] e1000e :08:00.0 enp8s0: renamed from eth1
[2.422105] e1000e :07:00.0 enp7s0: renamed from eth0

So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.


Because those "rational" ethernet names can be very unstable *in 
practice* on modern systems. (Devices are initialized in parallel, so 
when there are multiple interfaces present they may not always come up 
in the same order.)



Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.


See above. This worked reliably on old kernels, especially static 
kernels (pre-modules) with ISA/PCI devices and works much less reliably 
in a world of hotplug PCI, USB, and modular configurations with parallel 
intialization. There was a series of hacks on top of the "rational 
names" which mapped the name to a MAC address. In practice that *also* 
renamed the ethernet devices, except in a less transparent fashion, and 
caused its own headaches when NICs were replaced.



They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are.


As a programmer you should be concerned with making sure that the 
packets go in and out of the correct physical hardware. If the name 
doesn't relate to the physical harder that's a harder problem to solve. 
You (and everyone else) could reimplement that in software at a higher 
level, or accept that this is something the OS should help with.



AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.


With all the 'puters 


really?


I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.


Again, many desktops have lousy firmware. Yours seems to be one of them. :-)


Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself.


udev can't map a logical bus to a physical slot, only the firmware knows 
how to do that (and only if it's been properly configured by the 
vendor). udev can't even tell things like how many buses there are in 
the system, because the firmware may turn them on and off or create 
virtual buses and change those things between boots. As with most 
things, the systemd folks didn't just implement a solution looking for a 
problem, they tried to solve an actual problem that's a lot harder than 
people throwing rocks from the sidelines tend to understand.

Re: Ethernet trouble

[Stefan Monnier]

> And counting interfaces has worked for me for a couple decades, on many
> systems and several OSs.

FWIW, this whole mess exists for the simple reason that there isn't any
kind of "aliasing" available for network interfaces.  When stable names
were added to block devices, it didn't break anything because it was
introduced simply by adding the /dev/disk/by-*/* symlinks.

I wish stable interface names had been added via a similar mechanism
(which of course would have had to be added beforehand).


Stefan

Re: Problem with fish in plasma

[Kenneth Parker]

On Fri, Jan 31, 2020, 4:30 AM Hans  wrote:

> Am Freitag, 31. Januar 2020, 10:18:43 CET schrieb Kenneth Parker:
>
> Hi Kenneth,
>
>
>
> no, it is not the fish shell. I discovered, it is kioslave5, that is
> responsible. When I am at the user, I will check it, if the problem is
> solved, when I delete all kio* files below .kde, .config and .local.
>

Package kio (KDE Input Output Framework), allowing remote access to files.
The package description included mention of "ssh (fish)", hence your url.

>
>
> Hope this will help.
>

Once again, I learn something new.  Thanks!

Kenneth Parker

>
> On Thu, Jan 30, 2020, 1:35 PM Hans  wrote:
>
> Hi folks,
>
> I got into a problem with "fish" in plasma.
>
>
> Fish Shell?
>
>
> When I do the correct syntax like the following example
>
> fish://username@192.168.1.45:/home/username
>
>
> URL, as in plugged into a Browser?
>
>
> I am running into a gdbus.error.
>
> Examing the problem, I believe, the user has destroyed something in his
> profile. I created a new user for testing purposes and this one is working
> like
> a charme.
>
> However, as I do not want to delete the whole plasma configuration, maybe
> someone knows, which configuration file (possibly below ~/.kde, ~/.local
> or
> ~/.config) might be responsible for that, so that I could either delete it
> or
> check the settings.
>
> Any help is preciated!
>
>
> I am intrigued enough to install and try out this Shell (if I am
> understanding the Google Search enough).
>
>
> Thank you very much for any hints.
>
>
> This will be the first time I try a new Shell in years.  Maybe we can help
> each other.
>
>
> Best regards
>
> Hans
>
>
> Kenneth Parker
>
>
>
>
>
>

KDE failed to start and CPU lockups when openvswitch enabled

[John Mok]

Hi all,

I use Buster + Xen on Lenovo ThinkPad P52 (Intel 8750H). When enabled
openvswitch, the following problems found :-

1) KDE failed to start
2) frequent CPU lockups
3) USB storage failed to mount (and lockup)

I hope someone could point me how to resolve those problems.

Thanks a lot.


John Mok

  p52-xen-dmesg.txt


  p52-xen-cpuinfo.txt

Re: OT red por cable con portal captivo sin trafico interno.

[Antonio Trujillo Carmona]

El 29/1/20 a las 17:41, Paynalton escribió:
>
>
>
> El mié., 29 ene. 2020 a las 7:40, Antonio Trujillo Carmona
> ( >) escribió:
>
> El 28/1/20 a las 8:42, Antonio Trujillo Carmona escribió:
> >     En nuestro hospital tenemos una VLan de gracia para los
> equipos no
> > identificados.
> > Debido al abuso que se hace de esa vlan nos estamos planteando
> poner un
> > portal de validación y anular el trafico interno.
> > No se trata tanto de bloquear o filtrar usuarios como de evitar
> que se
> > puedan conectar dispositivos electromédicos u OT a la red, por
> lo que no
> > es importante el nivel de seguridad, cualquier elección haría que un
> > dispositivo automático fallara en adquirir red, que es lo que
> buscamos.
> > Los conmutadores (HP procurbe) solo admiten 2 de 3 posibles
> formas de
> > acceso y tienen activado el filtrado 802.1x y por MAC, por lo
> que no se
> > puede activar el acceso web.
> > ¿Alguna idea?
> >
> Muchas gracias a todos por las respuestas.
>
> Realmente mi pregunta no iba sobre que portal usar, aunque
> agradezco los
> apuntes y los probare, si no por como configurar una red por dhcp para
> que los equipos que estén en la misma red y en el mismo conmutador
> (switch) no se vean entre ellos.
>
>
>
> Para mantener aislamiento debes usar vlans, manteniendo a la red
> médica en una vlan y la red pública en otra.
>
> El mismo DHCP puede decidir a qué vlan se va cada equipo y qué
> servicios puede tener.
>
> En el gateway de la red pública debes colocar un acceso por proxy
> controlado por temporizador como te había mencionado en un correo
> anterior.
>
> El DHCP debe entregar la ruta de un wpad para la configuración
> automática del proxy.
>
> Debes tener un servicio web que entregue el archivo wpad, el cual
> indicará que la salida a internet es a través del proxy.
>
> Así, en un caso de uso típico sucede:
>
> Caso A:
>
> -visitante llega con su teléfono.
> -visitante se conecta a la red pública abierta
> -teléfono solicita configuración al DHCP
> -DHCP entrega configuración de red y una ruta para wpad
> -visitante intenta entrar a internet
> -navegador del teléfono consulta el wpad
> -navegador redirige la petición al proxy
> -proxy redirige al visitante a una página de error donde le pide
> contraseña, o una encuesta o la foto de la enfermera Salo en traje de baño
> -visitante interactúa con la página y gana el acceso temporizado
> -proxy permite el acceso por 15 minutos antes de mostrar de nuevo el
> pack de verano de la enfermera Salo.
>
> Caso B:
>
> -llega un interno con un novedoso aparato que no sirve para nada pero
> que consiguió barato en amazon.
> -interno conecta el aparato a la red pública por flojera de ir a
> sistemas a pedir acceso
> -aparato no tiene navegador, por lo que no puede ver las candentes
> fotos de la enfermera Salo
> -aparato no logra conectarse y el interno no tiene más remedio que ir
> a pedir acceso a la red controlada.
> -Helpdesk registra macaddress en el DHCP
> -aparato se vuelve a conectar a la red
> -DHCP encuentra al aparato en su waitlist y entrega IP de la vlan
> controlada.
>  

Muchas gracias por las aportaciones.

Si esto ya lo se, se trata de evitar que llegue un laboratorio e instale
unos equipos sin pasar por el servicio de informática, en la actualidad,
como no están identificados van a parar a la VLAN de gracia donde si se
ven entre ellos y verifican el funcionamiento con el portatil que lleva
el instalador, lo dan por bueno y se van, después llaman al servicio de
informática por que la red del hospital esta mal y no se ven desde los
ordenadores del hospital, porque ellos han verificado la instalación que
hicieron.

Como soy muy cabezota, tengo que encontrar la solución, me he planteado
varios caminos:

Investigar a fondo ipv6 que creo que traía algún protocolo para esto
(forzando a levantar una comunicación punto a punto entre la maquina y
un nodo centrar donde instalare alguno de los portales que me han
aconsejado).

Subdividir el rango de la VLAN en redes con prefijo 30, aunque en los
conmutadores solo admiten una vlan por defecto, esto reduciria de 254 a
64 los equipos que se permiten concurentemente en la Vlan de gracia,
pero espero que sea un numero suficiente.

Investigar el tema de la validación web para que "emule" la validación
MAC y puedan acceder tanto los equipos con MAC autorizada (en sus Vlanes
correspondientes) como los no autorizados a las Vlanes preparadas de la
forma que he dicho antes.


Contare como acaba la cosa, y otra vez muchas gracias por las aportaciones.




signature.asc
Description: OpenPGP digital signature

Re: cpu frequence

[Gerard ROBIN]

On Fri, Jan 31, 2020 at 12:11:49AM +0100, Linux-Fan wrote:
> Date: Fri, 31 Jan 2020 00:11:49 +0100
> From: Linux-Fan 
> To: debian-user@lists.debian.org
> Subject: Re: cpu frequence
> 
> Gerard ROBIN writes:
> 
> > Hello,
> > the maximum frequency of my cpu is 2.8 GHz and under "bullseye" the 
> > frequency
> > of my cpu is always higher than 2.7 GHz. If this is a bug how can we
> > determine which package is affected ?
> 
> Normally, modern CPUs go to high frequency only if they are "loaded". Thus,
> I'd suggest to check if there is any process obviously taking a lot of CPU
> time. `top` might be enough for a glance, but I normally like `htop` and
> `atop` outputs more (`htop` is more "friendly", but `atop` is more
> informative IMHO).
atop (buster):
PRC |  sys0.31s |  user   0.70s |  #proc205  | #trun  1  |  #tslpi  
 252 |  #tslpu 0 |  #zombie0  | #exit  6  |
CPU |  sys   2% |  user  4% |  irq   0%  | idle393%  |  wait
  0% |  ipc notavail |  curf  872MHz  | curscal  31%  |
cpu |  sys   0% |  user  1% |  irq   0%  | idle 98%  |  cpu001 
w  0% |  ipc notavail |  curf  851MHz  | curscal  30%  |
cpu |  sys   1% |  user  2% |  irq   0%  | idle 98%  |  cpu000 
w  0% |  ipc notavail |  curf  850MHz  | curscal  30%  |
cpu |  sys   1% |  user  1% |  irq   0%  | idle 98%  |  cpu003 
w  0% |  ipc notavail |  curf  881MHz  | curscal  31%  |
cpu |  sys   1% |  user  1% |  irq   0%  | idle 98%  |  cpu002 
w  0% |  ipc notavail |  curf  906MHz  | curscal  32%  |
CPL |  avg10.01 |  avg50.15 |  avg15   0.09  |   |  csw 
9428 |  intr4327 || numcpu 4  |
MEM |  tot 7.7G |  free5.6G |  cache 768.7M  | buff   25.6M  |  slab  
127.6M |  shmem  57.2M |  vmbal   0.0M  | hptot   0.0M  |
SWP |  tot 7.9G |  free7.9G ||   |  
 |   |  vmcom   2.5G  | vmlim  11.8G  |
DSK |   sda |  busy  0% |  read   0  | write 27  |  KiB/w   
   5 |  MBr/s0.0 |  MBw/s0.0  | avio 0.59 ms  |

atop (bullseye):
PRC |  sys0.33s |  user   0.63s |  #proc189 |  #trun  1 |  #tslpi   
260  | #tslpu 1  | #zombie0  | clones 6  | #exit  6  |
CPU |  sys   2% |  user  4% |  irq   0% |  idle393% |  wait 
 0%  | ipc notavail  | cycl unknown  | curf 2.75GHz  | curscal  98%  |
cpu |  sys   1% |  user  2% |  irq   0% |  idle 97% |  cpu000 w 
 0%  | ipc notavail  | cycl unknown  | curf 2.77GHz  | curscal  98%  |
cpu |  sys   0% |  user  1% |  irq   0% |  idle 99% |  cpu001 w 
 0%  | ipc notavail  | cycl unknown  | curf 2.74GHz  | curscal  97%  |
cpu |  sys   0% |  user  1% |  irq   0% |  idle 98% |  cpu003 w 
 0%  | ipc notavail  | cycl unknown  | curf 2.74GHz  | curscal  98%  |
cpu |  sys   1% |  user  1% |  irq   0% |  idle 99% |  cpu002 w 
 0%  | ipc notavail  | cycl unknown  | curf 2.73GHz  | curscal  97%  |
CPL |  avg10.10 |  avg50.11 |  avg15   0.09 |   |  csw
14895  |   | intr6027  |   | numcpu 4  |
MEM |  tot 7.8G |  free5.6G |  cache 730.0M |  buff   51.5M |  slab  
125.2M  | shmem 105.2M  | vmbal   0.0M  | hptot   0.0M  | hpuse   0.0M  |
SWP |  tot 7.9G |  free7.9G |   |   |   
 |   |   | vmcom   2.9G  | vmlim  11.8G  |
PSI |  cs 0/0/0 |  ms 0/0/0 |  mf 0/0/0 |  is 0/0/0 |  if 
0/0/0  |   |   |   |   |
DSK |   sdb |  busy  0% |  read   0 |  write  1 |  KiB/r
  0  | KiB/w 28  | MBr/s0.0  | MBw/s0.0  | avio 4.00 ms  |

PID   SYSCPU USRCPUVGROW RGROWRUID  EUID ST 
  EXC  THRS CPUNR   CPU CMD
1935  0.11s  0.26s -8K  -372K root  root -- 
   -   10 S  3   4%  Xorg
2302  0.06s  0.16s  0K 0K user  user -- 
   -7 S  2   2%  xfwm4
3716  0.01s  0.04s  0K 0K user  user -- 
   -4 S  0   1%  gnome-terminal
3656  0.01s  0.04s  0K 0K user  user -- 
   -4 S  0   1%  panel-17-weath
3594  0.01s  0.02s  0K 0K user  user -- 
   -3 S  0   0%  panel-25-cpugr


> The other thing is: As long as it is always below or equal to 2.8 GHz, it
> need not be wrong. However, most machines with U-processors (especially
> notebooks) have a cooling system which does not permit them to sustain the
> maximum frequency for long. You might investigate this by generating load on
> all cores e.g. like this:

Re: Can't find a way to preseed keyboard layout for all d-i questions

[Yvan Masson]

Le 29/01/2020 à 18:16, MAS Jean-Louis a écrit :

Le 29/01/2020 à 14:50, Yvan Masson a écrit :


However, before loading preseed.cfg, installer asks for computer name: I
would like this question to be asked in French and more importantly to
have the keyboard layout configured in French.

I have tried many boot parameters (layout=fr, layout=fr(latin9),
language=fr, language=fr_FR.UTF-8…) but could not find anything working.

After answering this question, preseed.cfg is loaded so language and
keyboard layout are properly applied.


It's a well known bug unfortunately

I have asked the same question some time ago on the French debian-user
list, and frederic boiteux gave me some interesting clues.

You may search for this thread :

"Configurer un clavier français via preseed"

A similar bug was reported with an Hungarian keyboard, without any fixes
so far.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931368

Regards


Thanks for the information. However I just checked by doing a fresh 
installation with BIOS PXE boot, di-netboot-assistant and a preseed file 
served by TFTP: locale and keyboard layout are properly applied:

- during install once preseed.cfg is loaded
- after reboot
If it can help, here is the interesting part of the preseed.cfg file:
  d-i debian-installer/language string fr
  d-i debian-installer/country string FR
  d-i debian-installer/locale string fr_FR.UTF-8
  d-i keyboard-configuration/xkb-keymap select fr(latin9)
  d-i time/zone string Europe/Paris

Yvan

Re: Problem with fish in plasma

[Hans]

Am Freitag, 31. Januar 2020, 10:18:43 CET schrieb Kenneth Parker:
Hi Kenneth,

no, it is not the fish shell. I discovered, it is kioslave5, that is 
responsible. When I am 
at the user, I will check it, if the problem is solved, when I delete all kio* 
files below 
.kde, .config and .local.

Hope this will help.

Best regards

Hans

 




On Thu, Jan 30, 2020, 1:35 PM Hans  wrote:


Hi folks,

I got into a problem with "fish" in plasma. 




Fish Shell? 


When I do the correct syntax like the following example

fish://username@192.168.1.45:/home/username




URL, as in plugged into a Browser? 




I am intrigued enough to install and try out this Shell (if I am understanding 
the 
Google Search enough). 




This will be the first time I try a new Shell in years.  Maybe we can help each 
other. 




Kenneth Parker 





[1] mailto:hans.ullr...@loop.de


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

Re: Problem with fish in plasma

[Kenneth Parker]

On Thu, Jan 30, 2020, 1:35 PM Hans  wrote:

> Hi folks,
>
> I got into a problem with "fish" in plasma.
>

Fish Shell?

When I do the correct syntax like the following example
>
> fish://username@192.168.1.45:/home/username
>

URL, as in plugged into a Browser?

>
> I am running into a gdbus.error.
>
> Examing the problem, I believe, the user has destroyed something in his
> profile. I created a new user for testing purposes and this one is working
> like
> a charme.
>
> However, as I do not want to delete the whole plasma configuration, maybe
> someone knows, which configuration file (possibly below ~/.kde, ~/.local
> or
> ~/.config) might be responsible for that, so that I could either delete it
> or
> check the settings.
>
> Any help is preciated!
>

I am intrigued enough to install and try out this Shell (if I am
understanding the Google Search enough).

>
> Thank you very much for any hints.
>

This will be the first time I try a new Shell in years.  Maybe we can help
each other.

>
> Best regards
>
> Hans


Kenneth Parker

>

Re: customização da Live CD

[Antonio Terceiro]

On Thu, Jan 30, 2020 at 10:18:12PM -0300, Qobi Ben Nun wrote:
> Olá Caio,
> 
> Creio que seja uma boa ideia entrar em contate com o pessoal da lista
> debian-l...@lists.debian.org, pois é onde se discute a respeito dessa
> versão do sistema.
> 
> Att, 
> 
> 
> On 30/01/20 03:11, Caio Ferreira wrote:
> > Lista
> > 
> > alguém saberia me dizer se existe a possibilidade de customizar a iso do
> > Live CD do Debian? eu estou querendo acrescentar o software minicom ou
> > putty no live CD do Debian

de qualquer forma, a resposta para a sua pergunta é sim. tudo no Debian
pode ser customizado, já que é tudo software livre. Isso não quer dizer
que qualquer customização seja fácil ou trivial.

mas nesse caso específico, pelo que eu já tentei no passado, gerar uma
imagem personalizada com alguns pacotes a mais do que o padrão é uma
tarefa relativamente simples.  eu não lembro mais os detalhes, senão já
te dizia aqui. mas comece pelo wiki:
https://wiki.debian.org/DebianLive


signature.asc
Description: PGP signature