On 6/17/2013 2:33 PM, Greg Freemyer wrote:

I've had no issues with systemd. In general it just works.

Many people say the same thing about Windows. And even Windows 8. Yet there are non-trivial reason to choose one thing over another. They are not equivalent with the only differences being window dressing. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-06-17 at 14:33 -0400, Greg Freemyer wrote:

I'm a fairly heavy desktop openSUSE user the last couple years. I've had no issues with systemd. In general it just works. My biggest complaint is that Yast is not integrated into the systemd ecosystem, so I "assume" one would have problems enabling / disabling services via yast. I don't do that on my laptop, so I've been fine.

Have a look at "systemadm" (package systemd-ui). - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG/fBoACgkQtTMYHG2NR9UNhQCdFjT7xph3rc+Ol9RxoehDPZ4Y vfYAnjZT+7D2LxGgAFtm0lC/46J+gaYd =RyJD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 17/06/13 18:09, Bruce Ferrell escribió:

/usr/bin/systemadm /usr/bin/systemadm: symbol lookup error: /usr/lib64/libgtk-3.so.0: undefined symbol: g_type_get_type_registration_serial

You are running an incompatible version of glib, as it doesn't have symbol versioning, the package manager cannot warn you that upgrading it will cause other packages to fail at startup, yes it is broken, no, it has nothing to do with systemadm. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 17/06/13 18:09, Bruce Ferrell escribió:

Just installed it and executed it as root:

/usr/bin/systemadm /usr/bin/systemadm: symbol lookup error: /usr/lib64/libgtk-3.so.0: undefined symbol: g_type_get_type_registration_serial

I just fixed gtk3 in factory to avoid this from happening again. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Jun 17, 2013 at 6:30 PM, Robin Klitscher wrote:

...

The good news is that yast is likely to be released with python source for 13.1, so devs that know python can start hacking on it again and bring it back up to speed.

My mistake, the new version will be in ruby, not python. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

On 6/17/2013 1:49 PM, Ken Schneider - openSUSE wrote:

...

On 06/17/2013 11:57 AM, Istvan Gabor pecked at the keyboard and wrote:

...

Hello:

I see there are plenty of messages on this list related to systemd, and systemd related issues. For me this fact indicates that systemd is not matured and stable enough to be included in a RELEASE as default and standard.

To include a question too, I thought that post 12.1 openSUSE versions come with systemd and do not offer sysvinit as an alternative. Still I read here that some users are using or trying to use sysvinit on openSUSE 12.3. So, do openSUSE 12.2 and 12.3 offer sysvinit package(s) similarly to 12.1 which can be exchanged for systemd?

12.2 is the last version to offer sysvinit (it's what I'm using). 12.3 and newer will only have systemd.

Really?

Seems to be quite a few sysvinit packages in http://download.opensuse.org/distribution/12.3/repo/oss/suse/i586/ http://download.opensuse.org/distribution/12.3/repo/oss/suse/x86_64/

Yes, the packages are still present, but I believe other bits have been removed or have stopped working. I have not tried sysvinit on 12.3 myself, but I think somebody else reported problems only just yesterday. -- Per Jessen, Zürich (23.4°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2013. június 18. 10:30 napon Cristian Rodríguez írta:

On 06/18/2013 03:12 AM, Per Jessen wrote:

...

Yes, the packages are still present, but I believe other bits have been removed or have stopped working.

Correct, the underlying base structure is no longer there and many, many important or rather say critical packages will no longer work at all.

Thank you all. The reason I asked this because in openSUSE 12.1 I had (still have) boot problems. First I thought it was systemd's fault but I switched to sysvinit and it did not help. This problem is dual: 1. The network is occasionally not started. At some boot it is started, at other boots it is not set up and gives error message. Generally it is not big deal, since I can start it from my desktop using kinternet. But is may inhibit logins from other sites if someone doesn't start it manually by logging in, and it should not happen. And it never happened in previous versions. 2. Samba nmb demon occasionally dies or not started at boot. nmb daemon is necessary for printing from my virtual machine. If it is not started the user can not print from it. I can start nmb manually, but other users can not. So this is a serious problem too. This never happened in previous SUSE version either. Why I involved systemd when the problem occurs with sysvinit as well? I suspect that the changing of the whole boot process may have resulted the bugs. The boot does not work well because it was not adjusted correctly to systemd, and the same time it does not work with sysvinit either due to the changes. Cheers, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. said the following on 06/18/2013 07:28 AM:

I had network problems in 12.3. Both ifup and nm were started and competed one with another. Other services failed as consequence.

I had to manually disable nm.

As I've mentioned, I had network problems with 12.2. I have a huge DNS list - see http://pgl.yoyo.org/as/serverlist.php?hostformat=bindconfig&showintro=1&mimetype=plaintext - and it takes a bit longer for DNS to start since it has to digest all that, so spamd, ntp and others were failing. I had to make them dependent on on dns and adjust the dns time-out. Manually. Of course I needed to make use of the logs to find out what was going on. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan said the following on 06/18/2013 07:57 AM:

* Anton Aylward [06-18-13 07:47]:

...

Carlos E. R. said the following on 06/18/2013 07:28 AM:

...

I had network problems in 12.3. Both ifup and nm were started and competed one with another. Other services failed as consequence.

I had to manually disable nm.

As I've mentioned, I had network problems with 12.2. I have a huge DNS list - see http://pgl.yoyo.org/as/serverlist.php?hostformat=bindconfig&showintro=1&mimetype=plaintext - and it takes a bit longer for DNS to start since it has to digest all that, so spamd, ntp and others were failing. I had to make them dependent on on dns and adjust the dns time-out.

Manually.

didn't do 12.2 as such, Tumbleweed also didn't manually switch to systemd, Tumbleweed did.

But, I had/have/noticed no such probs with DNS and use the same spam filtering server list, not updated as regularily as should be.

That may be it. The real issue was TimeOut. When there's no updates, boots take a few seconds. When there's updates, it takes about 2 min to digest that list again. (will vary with machine, memory disk etc) DNS was failing with timeout - systemd was killing it thinking it was hung/runaway. So I set TimeOut to 90 seconds and all was fine. But because systemd is async I also had to make it very clear that spam etc depended on dns. My point is that this is all logical and easily determined from looking at the logs and status. But its the kind of thing that has some other people claiming that systemd is broken, insufficiently tested and such like. The problems - as Crisitan keeps pointing out - aren't with systemd but with what other things are doing or failing to do. And a lot of that - as the contrast between your system and mine in the way we handle that list illustrates - is very specific and not "one size fits all". -- He smiled gently. "It is of the first importance," he said, "not to allow your judgement to be biased by personal qualities. A client is to me a mere unit, -- a factor in a problem. The emotional qualities are antagonistic to clear reasoning. I assure you that the most winning woman I ever knew was hanged for poisoning three little children for their insurance-money, and the most repellent man of my acquaintance is a philanthropist who has spent nearly a quarter of a million upon the London poor." -- Sherlock Holmes, in "The Sign of the Four" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 18/06/13 05:31, Istvan Gabor escribió:

1. The network is occasionally not started. At some boot it is started, at other boots it is not set up and gives error message.

Sir, systemd has zero control over the how the networking tools work.

2. Samba nmb demon occasionally dies or not started at boot. nmb daemon is necessary for printing from my virtual machine. If it is not started the user can not print from it. I can start nmb manually, but other users can not. So this is a serious problem too. This never happened in previous SUSE version either.

What do you mean "it dies" ? does it crash ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. said the following on 06/18/2013 01:01 PM:

On Tuesday, 2013-06-18 at 12:55 -0400, Cristian Rodríguez wrote:

...

Sir, systemd has zero control over the how the networking tools work.

Mmm.

The messages I got that both nm and ifup were starting came from systemd >:-)

Indeed. And xinetd of old had zero control over how cups, rsync, vnc, ftp, ssh and others work ... But they are all started by the xinet daemon. The daemon was a dispatcher. Similarly systemd serves as a dispatcher and starts up named and many others. That's all it can do - how they work "internally" has nothing to do with systemd. If you have a device whose start up requires you to shove coal into the furnace, light it and "press enter" when the steam pressure reaches 90psi then systemd has no control over the shovel or the over-pressure escape safety valve either. Of course some things end up being done by rules in udev. Systemd start up the daemon for all that ... something I'm just begining to learn about Its a shame that USG went in a different direction from Plan9 so we can't have network devices and names under /dev .... Reading from /dev/ipv4/www.amazon.com/80 makes so much sense ... :-) Who knows? maybe that will be possible in the near future :-/ -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. said the following on 06/18/2013 02:21 PM:

The decission to start simultaneously two mutually exclusive services is not mine, it is from the system, and implemented by systemd. When I found out, I had to manually tell systemd to disable one of the two.

Hmmm. Now I wonder what _you_ did that I didn't do to get them _both_?

The services themselves are inoccent of something else telling them to run, even if that decission is wrong. And it was systemd who told them to start.

See above. See also my comments about context and the difficulty of a 'one size fits all' when we've already done customizations ... We've been though this before , such as when we made /dev/ 'dynamically generated'. It didn't fit everyone's needs right away. (I'm not sure it does even now.) Right now all I see in in rules.d/77-network.rules which uses ifup/ifdown and rules.d/70-persistent-net.rules which maps an Ethernet address to eth0 YMMV - it probably does :-) So check your riles and see what else you have ... -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 18/06/13 15:55, Per Jessen escribió:

Speaking professionally, we have some 50+ openSUSE systems spanning 10.2 to 12.2. They are all SNMP monitored, locally and externally. The change of network device naming introduced by systemd (yes, this IS a systemd issue),

No it is not, it is a change in udev, systemd does nothing with network interfaces. I am hoping the openSUSE comm^H^H^H^H do-ocracy will see

sense and at least retain the ability to rename devices automagically as we are used to. Maybe we can take over some stuff from upstream SLES.

The old code is gone from udev, because it did not work correctly, if you think you have a better idea, talk to Kay and Greg KH in the systemd-devel mailing list, they will explain to you why your are wrong ;P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Tue, 18 Jun 2013 21:55:15 +0200 Per Jessen пишет:

...

Anton Aylward wrote:

...

We've been though this before , such as when we made /dev/ 'dynamically generated'. It didn't fit everyone's needs right away. (I'm not sure it does even now.)

Right now all I see in in rules.d/77-network.rules which uses ifup/ifdown and rules.d/70-persistent-net.rules which maps an Ethernet address to eth0

YMMV - it probably does :-)

Don't hold your breath, in 13.1 we're headed toward socalled "PredictableNetworkInterfaceNames", such as enp13s0, enp14s0, enp3s1f0, enp3s1f1, enp6s2 ...

It will be a bit more complicated than that ... those predictable interface names are defined for PCI attached devices only. There is nothing for other classes of devices.

Yes, I know - I'm dreading it. On a xen domu, the devices will be eth0, eth1. On the dom0, I will have enp13s0, enp14s0, enp3s1f0, enp3s1f1, enp6s2 plus perhaps vif0, vif1, vif2. I have some boxes with vlan interfaces named 'vlanX@ethY' - they'll be very pretty if I were to use the new naming scheme. My ip-ip tunnels will presumably remain as ipip0, ipip1 and my vpn interface will still be tun0. Brilliant scheme.

So at one side we do not have old method to shuffle the names around anymore, on the other hand we also do not have any persistent names generated automatically.

You still can rename them, of course, just make sure it will not clash with kernel auto-generated names.

That is functionality I suggest we retain - if nothing else, to maintain some of the former user-friendliness of openSUSE. -- Per Jessen, Zürich (23.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-06-19 at 00:23 -0400, Anton Aylward wrote:

At that level does it really matter what the nomenclature is? "ethX" is nice but the alternative aren't show stoppers.

If it doesn't matter, why not let the names be what they were, why change? What's the rationale for changing the names, do we need that? - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHBR90ACgkQtTMYHG2NR9XAGQCeP1zpVUmbO05hIzrOxjScufxN 9/4AniZJwYBWx/smMcQ05PcMLOqm4aQB =5cLl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2013-06-19 at 08:13 +0200, Per Jessen wrote:

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday, 2013-06-19 at 00:23 -0400, Anton Aylward wrote:

...

At that level does it really matter what the nomenclature is? "ethX" is nice but the alternative aren't show stoppers.

If it doesn't matter, why not let the names be what they were, why change? What's the rationale for changing the names, do we need that?

There is roughly zero rationale, but rest assured Carlos, you DO need it. Don't your network interfaces change their names all the time?

I welcome the new names. We use ethernet cards to capture data from various measurement transducers (cameras, lasers, distance/time gauges, etc). If a card breaks (and they do), replacing it is a pita because the original ethX names are replaced by then next unused ones. Unless you fiddle around in YaST. If the name could be based on the slot the card is in, then swapping out a card would be much easier. I need to check how multi-port cards are named based on the slot the card is in... Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Jun 19, 2013 at 10:40 AM, Per Jessen wrote:

I think they're given names with 'fN' appended. The names I keep referring to:

enp13s0, enp14s0 - embedded interfaces. enp3s1f0, enp3s1f1 - dual-port NIC. enp6s2 - single fibre interface.

enpXXX is PCI device. Slot based enumeration starts with ensXXX. Not every system supports it, unfortunately. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Wed, 19 Jun 2013 13:41:41 +0200 Per Jessen пишет:

Andrey Borzenkov wrote:

...

On Wed, Jun 19, 2013 at 10:40 AM, Per Jessen wrote:

...

I think they're given names with 'fN' appended. The names I keep referring to:

enp13s0, enp14s0 - embedded interfaces. enp3s1f0, enp3s1f1 - dual-port NIC. enp6s2 - single fibre interface.

enpXXX is PCI device. Slot based enumeration starts with ensXXX. Not every system supports it, unfortunately.

Isn't the 's' in enp3s1f1 also a slot# ?

No. It is PCI bus/PCI device. Device 00:03.1 would result in enp0s3f1.

The ensXXX are supposedly for hot-plug slots, but I haven't had time to play with that yet.

Yes, this is for the cases when system supplies slot names. Check if you have anything below /sys/bus/pci/slots -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

I don't recall when I last had to replace a broken network card

I experienced a defective NIC a while ago. It was used in my firewall, when it started failing. Since I had another NIC in the same computer that was no longer being used, I just reconfigured to use it instead. But then, a few months ago, I had to remove that bad NIC, as it was killing the computer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 06/18/2013 03:55 PM:

...

Anton Aylward wrote:

...

We've been though this before , such as when we made /dev/ 'dynamically generated'. It didn't fit everyone's needs right away. (I'm not sure it does even now.)

Right now all I see in in rules.d/77-network.rules which uses ifup/ifdown and rules.d/70-persistent-net.rules which maps an Ethernet address to eth0

YMMV - it probably does :-)

Don't hold your breath, in 13.1 we're headed toward socalled "PredictableNetworkInterfaceNames", such as enp13s0, enp14s0, enp3s1f0, enp3s1f1, enp6s2 ...

https://bugzilla.novell.com/show_bug.cgi?id=820589

I agree with Cristian. a) this is a udev issue not a systemd issue

Apologies, I don't how I could have mistaken the two. :-(

b) we don't want special 'suse' hacks on this.

As far as I can make out we can still have deterministic mapping of a specific ethernet port (card, slot, whatever you want to call it) to "ethX' for whatever value of X. Deterministic meaning the same on every boot.

If that is the case, I have no case :-), but as far as I have understood that is not correct. If you're certain a user can maintain the current deterministic enumeration of eth0, eth1, eth2 with a minimum of effort, we can close that report as invalid.

That is a fundamental requirement of a system running as a firewall, isn't it? That WAN, DMZ, LAN and WLAN wiring match what the ports are named - every time!

Sure, that's how it works today. See udev/rules.d/70-persistent-network-names

At that level does it really matter what the nomenclature is?

Yes it does. The network interface names are used for loads of things outside the system - monitoring, measurement etc. Inside the system the new naming would mean amending scripts etc. (ref. YaST2 in 13.1M2), whereas keeping the naming would mean being able to move stuff from one box to another without having to think about the network naming scheme.

"ethX" is nice but the alternative aren't show stoppers.

I beg to differ. In a working environment of more than one system, having a mix of ethX and enp13s0, enp14s0, enp3s1f0, enp3s1f1 and enp6s2 will not work without a significant effort in adapting the rest of the environment. Like I said in the bugreport: The current enumeration of network interfaces ... 1) overall works very well 2) is integrated into everything else 3) corresponds to the style of enumeration we're used to working with in linux 3a) corresponds to the style of enumeration used by the manufacturer 4) is easy to pronounce 5) is consistent when one is dealing with multiple systems. We really ought to retain the option for the user to use the existing scheme of renaming at start up. -- Per Jessen, Zürich (22.6°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, Jun 19, 2013 at 10:22:21AM +0400, Andrey Borzenkov wrote:

On Wed, Jun 19, 2013 at 10:02 AM, Per Jessen wrote:

...

5) is consistent when one is dealing with multiple systems.

We really ought to retain the option for the user to use the existing scheme of renaming at start up.

Just stick with unified naming space that dies not conflict with kernel one, as was already done for other devices. udev no more supports renaming of sda to sdb. Why it should support renaming of eth0 to eth1?

Simply because to avoid trouble with random interface names as I've detected with bug #809843. This is the reason why systemd has now a patch 1006-udev-always-rename-network.patch as this avoids this.

Using net0, net1, etc. It is even easier to pronounce than eth :)

Hmmm ... I'm aware that systemd/udev upstream tend to break with traditions but IMHO net<number> isn't very helpful in the daily work of an system admin ... eth<number> show me more than net<number> ... /home/werner> ifconfig | awk '/^[a-z]/ {print $1}' br0 br1 dsl0 eth0 eth1 lo tun0 now if this becomes net0 upto net6

Even better would be support for interface aliasing. There were patches floating around.

Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/19/2013 3:03 AM, Andrey Borzenkov wrote:

On Wed, Jun 19, 2013 at 10:41 AM, Dr. Werner Fink wrote:

...

...

Using net0, net1, etc. It is even easier to pronounce than eth :)

Hmmm ... I'm aware that systemd/udev upstream tend to break with traditions but IMHO net<number> isn't very helpful in the daily work of an system admin ... eth<number> show me more than net<number> ...

A rose by any other name would smell as sweet ...

...

/home/werner> ifconfig | awk '/^[a-z]/ {print $1}' br0 br1 dsl0 eth0 eth1 lo tun0

now if this becomes net0 upto net6

is it complete sentence?

This message wasn't clear to you, yet we are to value your opinions on things? Careful there ;) -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dr. Werner Fink wrote:

On Wed, Jun 19, 2013 at 10:22:21AM +0400, Andrey Borzenkov wrote:

...

On Wed, Jun 19, 2013 at 10:02 AM, Per Jessen wrote:

...

5) is consistent when one is dealing with multiple systems.

We really ought to retain the option for the user to use the existing scheme of renaming at start up.

Just stick with unified naming space that dies not conflict with kernel one, as was already done for other devices. udev no more supports renaming of sda to sdb. Why it should support renaming of eth0 to eth1?

Simply because to avoid trouble with random interface names as I've detected with bug #809843. This is the reason why systemd has now a patch 1006-udev-always-rename-network.patch as this avoids this.

That's a lengthy bugreport, but it looks like we're moving in the right direction with this. Is this already in the current milestone? -- Per Jessen, Zürich (25.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

On Wed, Jun 19, 2013 at 10:02 AM, Per Jessen wrote:

...

The current enumeration of network interfaces ...

1) overall works very well

You are preaching to the wrong chore.

Well, this particular choir (the openSUSE user community) doesn't seem to have been much aware of the planned change.

Do you really believe that naming scheme was changed just to annoy users? Please discuss it on linux-hotplug list if you have convincing arguments that it was wrong decision.

Andrey, this discussion belongs here. I am only proposing we try not to annoy/upset/alienate _our_ users by allowing them to retain our current enumeration scheme.

Linux is not the only operating system where device names changed from release to release.

Irrelevant. openSUSE/Linux is the only operating system up for discussion here. (except when Anton and I go nostalgic).

...

2) is integrated into everything else 3) corresponds to the style of enumeration we're used to working with in linux

I have wlan0 on my notebook. My customer systems I have to support have bond, vlanXXX and something more. So even now there is no unified "style of enumeration".

Yes there is. We have 'aaaaN' where 'aaaa' indicates the type of interface and N is 0-999. Very consistent.

...

3a) corresponds to the style of enumeration used by the manufacturer

Sorry? Who manufactures Linux?

The hardware manufacturer, of course: http://files.jessen.ch/hp-dl380.jpeg http://files.jessen.ch/sun-4port-nic.jpeg http://files.jessen.ch/ibm-bladecenter-6port.jpeg

...

4) is easy to pronounce

For English native speakers. Others may not even know how to pronounce those letters at all.

Easy to pronounce for _anyone_ who speaks English, native or otherwise. Anyway, what is your point? The proposed scheme will (afaik) not change the character set to Cyrillic, Greek or Sanskrit. My point about pronunciation is that I expect people say 'ethernet-zero' and 'ethernet-one' when referring to 'eth0' and 'eth1'. Maybe in other languages people say 'ethernet-eins', 'ethernet-zwei', 'ethernet-et', 'ethernet-to', 'ethernet-ena', 'ethernet-dio', 'ethernet-yksi', 'ethernet-kaksi' .... How will one say 'enp3s1f1'?

...

5) is consistent when one is dealing with multiple systems.

We really ought to retain the option for the user to use the existing scheme of renaming at start up.

Just stick with unified naming space that dies not conflict with kernel one, as was already done for other devices. udev no more supports renaming of sda to sdb. Why it should support renaming of eth0 to eth1?

It does now. Why throw it away? -- Per Jessen, Zürich (24.0°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

On Wed, Jun 19, 2013 at 11:25 AM, Per Jessen wrote: ...

...

Andrey, this discussion belongs here.

...

...

...

Just stick with unified naming space that dies not conflict with kernel one, as was already done for other devices. udev no more supports renaming of sda to sdb. Why it should support renaming of eth0 to eth1?

It does now. Why throw it away?

We are going in circles. It is thrown away because this renaming had problems that were considered as not solvable by maintainers of udev. If maintainers are wrong, you have to show it. If maintainers are correct, you request to maintain indefinitely known broken approach.

I don't think you understand my point. The new naming scheme will introduce far more and far greater problems than what the current scheme currently does. I am only proposing we give the user (for whom we are doing all this work, right?) the _choice_ of keeping "maybe some minor issues" vs. introducing "lots of big issues and effort". -- Per Jessen, Zürich (24.8°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

Per Jessen said the following on 06/19/2013 04:00 AM:

...

I don't think you understand my point. The new naming scheme will introduce far more and far greater problems than what the current scheme currently does. I am only proposing we give the user (for whom we are doing all this work, right?) the_choice_ of keeping "maybe some minor issues" vs. introducing "lots of big issues and effort".

But you *HAVE* that option.

Go to

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...

and scroll down to the section titled "I don't like this, how do I disable this?"

You ought to try it, Anton - it reverts to the kernel naming, not the persistent naming we have with openSUSE today. -- Per Jessen, Zürich (30.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov wrote:

В Wed, 19 Jun 2013 10:00:52 +0200 Per Jessen пишет:

...

Andrey Borzenkov wrote:

...

On Wed, Jun 19, 2013 at 11:25 AM, Per Jessen wrote: ...

...

Andrey, this discussion belongs here.

...

...

...

Just stick with unified naming space that dies not conflict with kernel one, as was already done for other devices. udev no more supports renaming of sda to sdb. Why it should support renaming of eth0 to eth1?

It does now. Why throw it away?

We are going in circles. It is thrown away because this renaming had problems that were considered as not solvable by maintainers of udev. If maintainers are wrong, you have to show it. If maintainers are correct, you request to maintain indefinitely known broken approach.

I don't think you understand my point. The new naming scheme will introduce far more and far greater problems than what the current scheme currently does. I am only proposing we give the user (for whom we are doing all this work, right?) the _choice_ of keeping "maybe some minor issues" vs. introducing "lots of big issues and effort".

Patch to implement old renaming behavior is still present in factory.

Cool, thanks for bringing us up-to-date, Andrey. Do you happen to know what is needed to activate this in e.g. 13.1M2 ? -- Per Jessen, Zürich (22.9°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 06/19/2013 03:25 AM:

...

...

3a) corresponds to the style of enumeration used by the manufacturer

Sorry? Who manufactures Linux?

The hardware manufacturer, of course:

http://files.jessen.ch/hp-dl380.jpeg http://files.jessen.ch/sun-4port-nic.jpeg http://files.jessen.ch/ibm-bladecenter-6port.jpeg

Or in more basic terms, different cards (i.e from different vendors) have different drivers. http://www.cavebear.com/archive/cavebear/Ethernet/vendor.html -- "Extremism in the defence of liberty is no vice; moderation in the pursuit of justice is no virtue." -- Barry Goldwater (actually written by Karl Hess) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen said the following on 06/19/2013 03:25 AM:

My point about pronunciation is that I expect people say 'ethernet-zero'

Or possible 'ethernet-naught' :-) I recall being told as a child growing up in the UK that Zed is pronounced Zee If you come from overzees. -- “People often say that motivation doesn’t last. Well, neither does bathing—that’s why we recommend it daily.“—Zig Ziglar -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrey Borzenkov said the following on 06/19/2013 02:22 AM:

Linux is not the only operating system where device names changed from release to release.

Indeed! I've had a 12.2 and 12.3 installed on similar hardware (the 800Mhz pieces of crap out of the Closet of Anxieties that I speak of) One got eth0 the other eth1 - same hardware, same family of motherboard and embedded system. But more to the point: what's magic about "ertyhX' rather than a descriptive name? If you are running NetworkManager rather than the command line then details are hidden from you. If you are running from the command line you can do what I'm doing to cope with the fact that what is eth0 - the single ethernet port - on one machine is eth1 on the other. Heck, even if you are scripting its easy enough to run grep/sed/awk to pull it out of a query. If you are debugging, the the names are more useful than a mere "eth0". There is also the POV that these descriptive device names are really no different from the use of UUID for disk names. They stay the same across releases, even across changes in the distribution. Look at this way. Suppose I have three partitions. I then use fdisk to split one of them into two partitions. What happens to the names of the other two? +---------------------+---------------------+----------------------+ | a | b | c | +---------------------+---------------------+----------------------+ becomes +---------+-----------+---------------------+----------------------+ | | | b | c | +---------+-----------+---------------------+----------------------+ or +---------------------+---------+-----------+----------------------+ | a | | | c | +---------------------+---------+-----------+----------------------+ Oh, and try that with different distributions not just different releases! If you use UUID the names stay the same; if you use 'partition-based' the /dev/sda2 and /dev/sda3 might (or might not depending on things you may be unaware of) change. This is one reason I use LVM! Even if I move a LV to another physical drive it keeps the same name :-) I can - and have - taken such drives from one machine to another, booted them under other distributions and the persistent naming if partitions based on UUID and LVM naming meant that I had no hassle. Now you may live in an idealised world where your hardware never fails, you never upgrade. Maybe you aren't one of the people who are unhappy with the way Suse is going and want to move to Fedora, Mageia or CentOS. If you use UUID for your partition naming in /etc/fstab then life will be much nice because you are using persistent naming. But you really can't tell what those other distributions will do with your other devices names. Or the partitions that don't use UUID or LVM. -- "No, no. No crime," said Sherlock Holmes, laughing. "Only one of those whimsical little incidents which will happen when you have four million human beings all jostling each other within the space of a few square miles. Amid the action and reaction of so dense a swarm of humanity, every possible combination of events may be expected to take place, and many a little problem will be presented which may be striking and bizarre without being criminal. We have already had experience of such." -- From "The Adventure of the Blue Carbuncle" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

The key thing is, with disks/partitions/filesystems, you get to choose how they are identified (at least you do since the last several years). Sometimes uuid is the sanest answer for what you need. Sometimes uuid is the exact opposite of what you need and you really need is (the human settable and arbitrary) volume id. Sometimes you even really need the plain old device name like sda1. There IS NO one rightest way for all. Each of those methods has use cases where it makes the most sense, and other use cases where it is entirely broken and unusable. They are all the only possible way, and they are all the absolutely impossible way, each at different times in different situations. So for disks, you get to choose. For network devices, naming the devices only after their physical installation and discovery by the kernel seems like a step backwards. True, as with disks, *sometimes* you will need exactly that. You can still identify disks as /dev/sda1. But there is a pretty big reason why it's the least recommended thing to look at. Because hardware isn't predictable any more. The drive with your filesystem on it might be sda one boot and might be sdd the next boot purely because of things outside the OS's control, like bios settings and whether any other drives are plugged in, where they are plugged in, or maybe the whole drive was cloned to a new machine when the old one failed. So many years ago they developed the means to find filesystems by their names or uuids wherever they might be, *instead* of finding disk and partitions by "2nd scsi disk, 1st partition" The same is true for network devices. Sometimes you care about the hardware type and physical connection most of all. "My 1st wifi device is my WAN interface. I don't care what it's called, I might have replaced a dead usb nic with a new one and it will have a different mac address and might be from a different manufacturer and use a different chip driver and might be plugged in to a different usb port or pci slot. I might have 2 motherboard built-in gigabit nics that may or may not be enabled in the bios, and may or may not have cables plugged in at any given time, but they are not wi-fi. But it's always true that my 1st wifi device is my wan!" Sometimes you care about an arbitrarily assigned name and nothing else. "I have huge complicated firewall rules, and they all refer to "nic0" as the all-important internet-facing interface. I need to be able to rename or alias any interface to "nic0". It might be ethernet one day, it might be wifi another day, it might be a bridge or virtual interface another day. It might have any mac address. I don't need the system to recognize which device I want automatically at boot if something changed, I just need to be able to take any device, and rename it or provide an alias for it, to the name of my choice, so that a bunch of scripts and fierwall tables and other config files can all be made to work by me just changing one thing in one spot." Sometimes you care about a particular device. "My wan is on the device with this mac address. Due to bios settings or me moving plugs/slots around, it might show up as the 1st 2nd or 3rd device, but the ethernet cable is plugged in to this device so this mac address is my wan, whatever slot number it happens to be in, or no matter if I plugged in 3 other new nics and the numbers all changed around so what used to be 1 is now 4" etc etc You need to be able to choose how you identify things for the same reasons as is already understood to be true for disks. -- bkw On 6/19/2013 7:55 AM, Anton Aylward wrote:

Andrey Borzenkov said the following on 06/19/2013 02:22 AM:

...

Linux is not the only operating system where device names changed from release to release.

Indeed! I've had a 12.2 and 12.3 installed on similar hardware (the 800Mhz pieces of crap out of the Closet of Anxieties that I speak of) One got eth0 the other eth1 - same hardware, same family of motherboard and embedded system.

But more to the point: what's magic about "ertyhX' rather than a descriptive name?

If you are running NetworkManager rather than the command line then details are hidden from you.

If you are running from the command line you can do what I'm doing to cope with the fact that what is eth0 - the single ethernet port - on one machine is eth1 on the other. Heck, even if you are scripting its easy enough to run grep/sed/awk to pull it out of a query.

If you are debugging, the the names are more useful than a mere "eth0".

There is also the POV that these descriptive device names are really no different from the use of UUID for disk names. They stay the same across releases, even across changes in the distribution.

Look at this way. Suppose I have three partitions. I then use fdisk to split one of them into two partitions. What happens to the names of the other two?

+---------------------+---------------------+----------------------+ | a | b | c | +---------------------+---------------------+----------------------+

becomes

+---------+-----------+---------------------+----------------------+ | | | b | c | +---------+-----------+---------------------+----------------------+

or

+---------------------+---------+-----------+----------------------+ | a | | | c | +---------------------+---------+-----------+----------------------+

Oh, and try that with different distributions not just different releases! If you use UUID the names stay the same; if you use 'partition-based' the /dev/sda2 and /dev/sda3 might (or might not depending on things you may be unaware of) change.

This is one reason I use LVM! Even if I move a LV to another physical drive it keeps the same name :-)

I can - and have - taken such drives from one machine to another, booted them under other distributions and the persistent naming if partitions based on UUID and LVM naming meant that I had no hassle.

Now you may live in an idealised world where your hardware never fails, you never upgrade. Maybe you aren't one of the people who are unhappy with the way Suse is going and want to move to Fedora, Mageia or CentOS. If you use UUID for your partition naming in /etc/fstab then life will be much nice because you are using persistent naming.

But you really can't tell what those other distributions will do with your other devices names. Or the partitions that don't use UUID or LVM.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 19 Jun 2013 08:02:36 +0200 Per Jessen wrote:

I beg to differ. In a working environment of more than one system, having a mix of ethX and enp13s0, enp14s0, enp3s1f0, enp3s1f1 and enp6s2 will not work without a significant effort in adapting the rest of the environment.

enp1I3s0 enp1don't4s0 enp3knows1f0 enp3whats1f1 enpyou're6s2 enpcomplaining13s0 enp1about,on4s0 enp3Per.s1f0 enp3Thiss1f1 enpsyntax6s2 enpis13s0 enp1the4s0 enp3easiests1f0 enp3things1f1 enpI've6s2 enp1read3s0 enp1all4s0 enp3week.s1f0 enp3As1f1 enpchild6s2 enpcould13s0 enpmaster4s0 enp3its1f0 enpafter3s1f1 enpa6s2 enp1morning's3s0 enp1lesson!4s0 enp3:-) enp1regards3s0 enp1Carl4s0 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Robin Klitscher wrote:

On 20/06/13 11:22, Carl Hartung wrote:

...

On Wed, 19 Jun 2013 08:02:36 +0200 Per Jessen wrote:

...

I beg to differ. In a working environment of more than one system, having a mix of ethX and enp13s0, enp14s0, enp3s1f0, enp3s1f1 and enp6s2 will not work without a significant effort in adapting the rest of the environment.

enp1I3s0 enp1don't4s0 enp3knows1f0 enp3whats1f1 enpyou're6s2 enpcomplaining13s0 enp1about,on4s0 enp3Per.s1f0 enp3Thiss1f1 enpsyntax6s2 enpis13s0 enp1the4s0 enp3easiests1f0 enp3things1f1 enpI've6s2 enp1read3s0 enp1all4s0 enp3week.s1f0 enp3As1f1 enpchild6s2 enpcould13s0 enpmaster4s0 enp3its1f0 enpafter3s1f1 enpa6s2 enp1morning's3s0 enp1lesson!4s0 enp3:-)

enp1regards3s0

enp1Carl4s0

Ha bloody ha! Very good ....

ROFL ... yes, that was excellent, Carl! I almost choked on my morning coffee. -- Per Jessen, Zürich (23.1°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-06-18 at 15:29 -0400, Anton Aylward wrote:

Carlos E. R. said the following on 06/18/2013 02:21 PM:

...

The decission to start simultaneously two mutually exclusive services is not mine, it is from the system, and implemented by systemd. When I found out, I had to manually tell systemd to disable one of the two.

Hmmm. Now I wonder what _you_ did that I didn't do to get them _both_?

Me? Nothing. I just upgraded from 12.1 to 12.3. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHA7MwACgkQtTMYHG2NR9X/tgCfS8330tQ8hqkGxRQe3xKmo1SM 6KYAn0xpj9usixC81ZEUH+uyEOLtq/xG =daAG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-06-19 at 00:25 -0400, Anton Aylward wrote:

...

...

Hmmm. Now I wonder what _you_ did that I didn't do to get them _both_?

Me? Nothing. I just upgraded from 12.1 to 12.3.

Methinks that one or the other is 'debris' left over from the initial install.

12.1 didn't have that problem, and that was the system it was upgraded from. The automatic transition from systemv to systemd did badly, not me. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHBR0QACgkQtTMYHG2NR9VqiQCfa3NojywTJUMkC7PG0V12KFug G6wAmgMOcvRo6Y8PYXg0t+Go0ojZYZS6 =cjUi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/18/2013 10:33 PM, Andrey Borzenkov wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

В Tue, 18 Jun 2013 20:21:37 +0200 (CEST) "Carlos E. R." пишет:

...

You may argue who told systemd to start those two services simultaneously. Well, that was the installation system from the openSUSE DVD. Ergo, SUSE >:-P

Exactly. To fix the problem one first has to identify the problem. Blaming systemd for anything happening under the sun is not going to help anyone.

And apologizing for something that's bad is not going to help anyone. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian RodrC-guez wrote:

On 06/18/2013 03:12 AM, Per Jessen wrote:

...

Yes, the packages are still present, but I believe other bits have been removed or have stopped working.

Correct, the underlying base structure is no longer there and many, many important or rather say critical packages will no longer work at all.

The package names were left there to deliberate mislead users into uninstalling those packages. They aren't really sysVinit packages, they are dummy packages made to look like sysVinit packages. Hmm... when you package something to make it look like the real thing, but put a dummy product in it, isn't that like fraud? Interesting the things systemd gets people into. FWIW, sysVinit runs does run on 12.3 & latest factory...but not the dummy packages that Suse ships. I wouldn't ship it as a product with my patches at this point though... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org