Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 12-04-16 11:24: >> Regular hardware should not suddenly appear out of nowhere, but I do not >> know about that Thunderbolt thing you mentioned > > that is nonsense > > * USB hardware is often *onboard* like SD-card slots on ProLiant > machines down to the HP

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Manuel Amador (Rudd-O) schreef op 12-04-16 12:46: > On 04/12/2016 02:26 AM, Xen wrote: >> That is completely nonsensical because it would imply that some network >> device could be initialized 2 hours after the system had booted. > > Greg KH is completely correct -- th

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 12-04-16 20:54: >> Then do it yourself. > > what? Design or propose something better. Maybe you thought the original system was better, I guess you mentioned something like that. > i am just a user like you but with technical understanding, the point is > that you

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Just want to summarize here very shortly. If you turn the hotplug naming scheme into something more attractive. If you turn the USB naming scheme into something more attractive. If you accept like a 99.9% confidence interval for waiting until hardware has shown itself, then taking the

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 13-04-16 01:16: > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: >> All you need to do is wait a few seconds before you start renaming > > Most machines boot to login faster than a "few seconds", so: Most machines boot to login faster than a fe

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 12-04-16 21:35: > > > Am 12.04.2016 um 21:24 schrieb Xen: >> However currently for me, biosdev renumbers these, while my scheme >> wouldn't > > wow - you even don't realise that "biosdevname" and > https://w

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Jordan Hargrave schreef op 13-04-16 01:24: > I am the primary developer of biosdevname. I've been wanting this > naming functionality built into systemd or even the OS itself. > Primarily I am interested in servers with multiple physical and > virtual NICs but getting it working on desktops

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 13-04-16 02:06: > > > Am 13.04.2016 um 01:20 schrieb Xen: >> Greg KH schreef op 13-04-16 01:16: >>> On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: >>>> All you need to do is wait a few seconds before you start renaming >&g

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 13-04-16 01:29: > On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: > All execpt for 4-socket and larger servers. They take tens of minutes > in the BIOS and then less than a minute in the kernel/userspace, > depending on the amount of memory. > > D

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 13-04-16 02:04: > > > Am 13.04.2016 um 00:03 schrieb Xen: >> Reindl Harald schreef op 12-04-16 21:35: >>> >>> Am 12.04.2016 um 21:24 schrieb Xen: >>>> However currently for me, biosdev renumbers these, while my scheme >&

[systemd-devel] on the default for PredictableNetworkInterfaceNames

I just want to add another opinion, but I am going to keep it really short. 1. I believe most users do not like the "enp5s0" scheme 2. I do not think there are any good reasons for making it the default. As a single illustration, I will cite this reason from the website: "Finally, many

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Xen schreef op 11-04-16 23:13: > No. You are causing pain and suffering to millions of people. > > You (...) have not inquired with anyone whether they really wanted this. > > So you push something and then you say "oh, but you can opt out". > > So you place the

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Xen schreef op 12-04-16 04:26: > I didn't even know it was that bad, jeez. > > My apologies. My sound stopped working as well because it was now a new device ;-) (different PCI bus number). The system sees it now as two devices, one of which is not present. They are the same device

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 12-04-16 00:14: > On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote: >>>> You can put usb devices at the end of the list. >>> >>> Why last? How do you know they go last when scanning? How do you know >>> when / if they will show up?

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Martin Pitt schreef op 12-04-16 12:57: > Xen [2016-04-12 3:37 +0200]: >> The trick to turn it off on the website doesn't work: >> >> ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules > > It does (at least on Debian, Ubuntu, and Fedora), but you need to > r

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 12-04-16 14:02: > Am 12.04.2016 um 14:00 schrieb Xen: >> Martin Pitt schreef op 12-04-16 12:57: >>> Xen [2016-04-12 3:37 +0200]: >>>> The trick to turn it off on the website doesn't work: >>>> >>>> ln

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

Thank you Andrei and Reindl for your answers. Let's stick to the facts for the moment or as much of it as we can. Martin Pitt schreef op 10-04-16 10:17: > There are very good reasons for having a mechanism for stable names by > default. Most importantly, to keep your machine actually >

[systemd-devel] Network Interface Names: solution for a desktop OS

I just want to present my conclusion here succintly. https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Was introduced to safeguard against a rare occasion where an important network computer in a critical environment would suffer from the kernel anomaly that

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Michael Biebl schreef op 11-04-16 00:22: > So why don't you implement such a scheme? Talk is cheap Criticising an idea by saying "do it yourself" is even cheaper. MUCH MUCH cheaper. Idiot. ___ systemd-devel mailing list

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

Martin Pitt schreef op 11-04-16 10:40: > Reindl Harald [2016-04-10 17:44 +0200]: >>> Because we had a mechanism for stable (but not predictable) interfaces >>> names, the 75-persistent-net-generator.rules thingy. Without either, >>> the first time you plugged in a second card/USB dongle/add an

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 11-04-16 01:05: > On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote: >> Michael Biebl schreef op 11-04-16 00:22: >>> So why don't you implement such a scheme? Talk is cheap >> >> Criticising an idea by saying "do it yourself"

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

Greg KH schreef op 11-04-16 15:42: > On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote: >> The predictability issue seems to be due to using a MAC address. >> >> AFAIK a reinstall will not change PCI bus devices etc. > > No, PCI device numbers change all the ti

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

Greg KH schreef op 11-04-16 22:19: >> My device is enp3s0, which implies 3rd bus number, which it indeed is: >> >> E: ID_PATH=pci-:03:00.0 >> >> Are you telling me there are systems where this is not guaranteed to be >> stable? > > Yes, including your own. So biosdev is not guaranteed to be

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 11-04-16 22:21: > On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote: >> It will just not be "predictable" when you remove or add hardware, >> because that reorders the resulting lists. >> >> Ie, if you have: >> >> ethernet0

Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames

Reindl Harald schreef op 14-04-16 12:02: > > > Am 14.04.2016 um 11:45 schrieb Jetchko Jekov: >> On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald > > can iterate over. >> > >> > $ ip -o a | awk '{print $2}' | uniq >> >> blub - gives a (incomplete) list of

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 15-04-16 18:06: > > > Am 15.04.2016 um 18:02 schrieb Xen: >> Reindl Harald schreef op 15-04-16 17:55: >>>>> so 3 seconds is unacceptable and the idea ist a joke in general >>>>> because >>>>> you wait for somet

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 13-04-16 10:26: > > > Am 13.04.2016 um 03:08 schrieb Xen: >> Reindl Harald schreef op 13-04-16 02:06: >>> >>> Am 13.04.2016 um 01:20 schrieb Xen: >>>> Greg KH schreef op 13-04-16 01:16: >>>>> On Wed, Apr 13, 20

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 13-04-16 10:24: > > > Am 13.04.2016 um 02:42 schrieb Xen: >> Greg KH schreef op 13-04-16 01:29: >>> On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: >> >>> All execpt for 4-socket and larger servers. They take tens of min

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 15-04-16 17:55: > > > Am 15.04.2016 um 17:48 schrieb Xen: >> Reindl Harald schreef op 13-04-16 10:24: >>> 4xHDD raid-10, hardware from 2011 >>> Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s >>> (userspace) =

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 13-04-16 05:04: > On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote: >> When you say that probing on the PCI bus never ends, and if we are >> talking not about some form of hotplugging, then I really wonder what >> you're on about ;-) because I do

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Greg KH schreef op 13-04-16 05:04: > On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote: >> When you say that probing on the PCI bus never ends, and if we are >> talking not about some form of hotplugging, then I really wonder what >> you're on about ;-) because I do

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Andrei Borzenkov schreef op 13-04-16 05:39: > Yes. And I do not see how all this information is expected to be stuffed > into 14 characters available for interface name, or even less if we > account to VLAN numbers. > > I am not aware of any OS that tries to do it. All of them maintain >

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

ng from a user experience point of view. Currently if I want to consistently mount a Windows share on my linux system I have to put this in fstab: //diskstation/media /store/media cifs ip=192.168.1.3,uid=xen,gid=staff,username=xen,password=,noauto 0 0 In Windows it is just a matter of br

Re: [systemd-devel] PredictableInterfaceNames and Debian

Reindl Harald schreef op 16-04-16 21:25: > interesting that you do exactly the same the whole thread - after your > offlist mail about psychiatry may i suggest you disturb somewhere else? I knew you were a pig, but that doesn't matter. ___

Re: [systemd-devel] PredictableInterfaceNames and Debian

Tobias Hunger schreef op 16-04-16 21:13: > > Am 16.04.2016 18:46 schrieb "Xen" <l...@xenhideout.nl > <mailto:l...@xenhideout.nl>>: >> And if you did need to write stuff: why not queue the changes and then >> apply them after the remount rw, if that

Re: [systemd-devel] PredictableInterfaceNames and Debian

Reindl Harald schreef op 16-04-16 19:13: > honestly: what about just create your own operating system and leave us > all in peace with endless mails mixing a dozen of rarely topics or just > use a distribution like RHEL/CentOS/Fedora where you can just use > ifup/ifdown scripts and tie MAC-address

[systemd-devel] PredictableInterfaceNames and Debian

Reindl was trying to give me links on Debian. Andrei alluded to the fact that the infrastructure has been removed. Indeed in systemd 215 in Debian the file /lib/udev/rules.d/75-persistent-net-generator.rules still exists, but in 220 it was removed. The original solution was a persistent file

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

Reindl Harald schreef op 16-04-16 12:07: > > > Am 16.04.2016 um 06:46 schrieb Andrei Borzenkov: >> 16.04.2016 03:14, Reindl Harald пишет: >>> >>> >>> Am 15.04.2016 um 21:06 schrieb Xen: >>>> If you cannot give me a default mapping autom

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

Jóhann B. Guðmundsson schreef op 16-08-2016 18:58: I personally recommend the project should stick with the original line drew in the sand, for the master branch and all the "experimental" stuff which may or may not come to pass, be kept in it's own experimental branch which would be the best

Re: [systemd-devel] alternate cryptsetup

Xen schreef op 29-08-2016 18:18: (...) I have found it impossible to turn systemd-cryptsetup off. How can I do that, in any case? I have presently been able to mask the actual systemd-cryptsetup@ services so they will not run. The funny thing is though that if you add one of those

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

Andrei Borzenkov schreef op 26-09-2016 15:28: What effect do you expect? If service Requires mount point and mount point is not available, service startup fails. That is correct and expected behavior. If service does not require mount point, service should be saying Wants and After. Which is at

[systemd-devel] proper way for shutdown script

Hi, the libnss-ldap package on my system used to contain (and still contains) a script that is run on system reboot and shutdown and installs itself into SysV directories for runlevel 0 and 6. However on SystemD I believe these are not run? What would be the proper way to run them?

Re: [systemd-devel] proper way for shutdown script

Lennart Poettering schreef op 05-10-2016 13:16: Why does nss-ldap require something like this? Sounds strange to me... Thanks man. I was just gonna charge you $40 for missed time... ;-). There are services during startup that are going to hang if you configure nsswitch.conf to also use ldap

Re: [systemd-devel] proper way for shutdown script

Xen schreef op 05-10-2016 14:37: And this works. But now the service must be started first before it will be called on shutdown... :-/. I guess the package installer would have to start the service after installation which would be a solution in that sense, it needs to enable the service

Re: [systemd-devel] proper way for shutdown script

Mantas Mikulėnas schreef op 05-10-2016 14:49: On Wed, Oct 5, 2016 at 1:47 PM, Xen <l...@xenhideout.nl> wrote: Hi, the libnss-ldap package on my system used to contain (and still contains) a script that is run on system reboot and shutdown and installs itself into SysV directories for ru

Re: [systemd-devel] proper way for shutdown script

Lennart Poettering schreef op 05-10-2016 14:52: nss_initgroups_ignoreusers

Re: [systemd-devel] proper way for shutdown script

Kai Krakow schreef op 07-10-2016 9:40: Am Wed, 05 Oct 2016 14:40:52 +0200 schrieb Xen <l...@xenhideout.nl>: Xen schreef op 05-10-2016 14:37: > And this works. But now the service must be started first before it > will be called on shutdown... :-/. I guess the package installe

Re: [systemd-devel] proper way for shutdown script

Lennart Poettering schreef op 06-10-2016 19:12: The way to have a process executed at shutdown is by using ExecStop= and making sure the unit is started at start-up time. Current systemd versions permit unit files without any ExecStart= to cover for this case, really old systemd versions

[systemd-devel] thoughts on different command structure

Just some considerations I posted elsewhere: - I think there are good reasons to do away with -ctl nomenclature no matter how prevalent these days across Linux systems. - You could call the journalctl tool "journals" -- it doesn't exist, could give access to various system logs, and become

Re: [systemd-devel] proper way for shutdown script

Mantas Mikulėnas schreef op 05-10-2016 18:34: If you mean "would not perform lookups _below_ a certain ID", then sure, that exists. In /etc/nslcd.conf you can specify "nss_min_uid 1000", for example, to avoid lookups for all system UIDs. Thank you. It seems interesting. I just think that they

Re: [systemd-devel] thoughts on different command structure

Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago… Right now it would only bring pointless differentation between older and newer

Re: [systemd-devel] thoughts on different command structure

Reindl Harald schreef op 05-10-2016 21:33: Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh, it is way too late for such changes. Maybe if you brought this five years ago

Re: [systemd-devel] thoughts on different command structure

Xen schreef op 05-10-2016 22:09: Reindl Harald schreef op 05-10-2016 21:50: as long as your are not able to distinct between firstname and lastname or at least quote the last name correctly: well, go pee, it's more productive than ideas change anything for no reason to bomb us (us

Re: [systemd-devel] thoughts on different command structure

Reindl Harald schreef op 05-10-2016 21:50: Am 05.10.2016 um 21:42 schrieb Xen: Reindl Harald schreef op 05-10-2016 21:33: Am 05.10.2016 um 21:26 schrieb Xen: Tomasz Torcz schreef op 05-10-2016 19:12: On Wed, Oct 05, 2016 at 07:00:11PM +0200, Xen wrote: [ … renaming propositions … ] Uh

[systemd-devel] alternate cryptsetup

How can I notify systemd-cryptsetup.service that cryptsetup has been done in a different way, and succeeded? Or, what exit status should systemd-cryptsetup have to signal success? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org

Re: [systemd-devel] alternate cryptsetup

Lennart Poettering schreef op 29-08-2016 11:46: On Sat, 27.08.16 23:20, Xen (l...@xenhideout.nl) wrote: How can I notify systemd-cryptsetup.service that cryptsetup has been done in a different way, and succeeded? Why would you do this? Note that systemd-cryptsetup.service is really just

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

Reindl Harald schreef op 26-09-2016 12:31: Am 26.09.2016 um 11:27 schrieb Oliver Neukum: On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote: Am 25.09.2016 um 23:52 schrieb Sergei Franco: I am looking at correct way to disable the "feature" of emergency mode when systemd encounters