[opensuse] ssytemd and openSUSE
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? Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/17/2013 11:57 AM, Istvan Gabor 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.
Bullshit, sysvinit gone forever, is not coming back and no, systemd is not unstable, all those messages you see in this list have absolutely nothing to do with systemd, but with applications misusing it, buggy packages, buggy unit files. I have read them all and so far, systemd it is working exactly as documented. You can see this messages use systemd on the subject, because people have the nasty habit of blaming systemd for whatever problem they have, whatever its origin might be. (generally blamed for problems with networkmanger, yast,..etc..) This is because of a lack of understading and a lack of lecture of the FM :-P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Jun 17, 2013 at 11:57 AM, Istvan Gabor
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.
No, it indicates there is a learning curve. Almost anything worth using has a learning curve if the job at hand is complex. 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. If I ran 12.3 on server, I need to find out how to do that without that help of Yast. Not a big deal, but I admit to having been spoiled by yast's knowledge of sys5init config files. 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. I have no idea if 13.1 will see systemd knowledge in yast or not. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
* Brian K. White
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.
And *most* of those do not have a clue!
Yet there are non-trivial reason to choose one thing over another. They are not equivalent with the only differences being window dressing.
that is universally true. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- 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
On 06/17/2013 02:14 PM, Carlos E. R. wrote:
-----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-----
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 -- 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
Cristian Rodr�������������������������������� wrote:
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
They are not running glib. It is a library, not a program. It is installed by SuSE installers. It isn't something that users usually install -- so he isn't running anything. SuSE has installed the wrong library -- and when systemadm was installed it didn't tell the installer it's specific requirements. Sounds like a systemadm bug to me. , 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.
The fact that systemadm uses a broken library of course, is not a design decision, and the fact that systemadm cannot use multiple versions and dynamically load the one the user has and can't adapt it's feature set to the libraries on the user's system, has nothing to do with the systemadm...right....it's always the user's fault. Software was supposed to adapt to the user -- not the other way around. -- 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 18/06/13 06:33, Greg Freemyer wrote:
On Mon, Jun 17, 2013 at 11:57 AM, Istvan Gabor
wrote: 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.
No, it indicates there is a learning curve. Almost anything worth using has a learning curve if the job at hand is complex.
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.
If I ran 12.3 on server, I need to find out how to do that without that help of Yast. Not a big deal, but I admit to having been spoiled by yast's knowledge of sys5init config files.
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. I have no idea if 13.1 will see systemd knowledge in yast or not.
Greg
Absolutely! One of the more sensible posts in these threads, if I may be so bold. I'm neither developer nor sysadmin. Just a Linux desktop user (15 years plus); not a guru of any sort. In the process of taking oS forward - a necessity if it is to survive or even to be usable for the great unwashed like me - the sky hasn't fallen in so far. Systemd in my usage has given me no troubles at all, and neither has grub2. If there are faults beyond birthpangs they are not obvious to me. They are certainly not showstoppers. And I'm also very happy to see that yast2 will be given the attention it needs. Keep up the good work. Here's to progress! -- Robin K Wellington "Harbour City" New Zealand -- 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
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
Its odd you are having so much problems with that card since my much
On 17/06/13 19:54, John Andersen wrote: older and less capable
x1400 series laptop card seems to work quite well. I had several issues initially but I found (and posted) that obtaining a newer xorg seemed to fix all my issues except one.
See http://lists.opensuse.org/opensuse/2013-05/msg00970.html
The only remaining issue is if desktop effects is on, sound can become very "stuttery" but simply not using so much bling solves that problem. This is due solely to Mesa I believe.
The problem occurs regardless of whether I have desktop effects / compositing enabled. And since the problem has existed through the last 5 or 6 versions of openSUSE I cannot imagine using the latest xorg will make any difference. Thanks for responding though. Given the post history on this list of recent days it seems that unless I make some reference to and have a heated philosophical debate about the merits or otherwise of systemd then nobody is going to pay a blind bit of notice or be motivated to reply. I just experienced this problem at the earliest stage ever, causing consistent pauses and hangs in typing my password at the KDM login screen. Unfortunately I had another two failed boots after that trying with nomodeset so I didn't save the log file, not that posting such a thing seems to inspire anybody to investigate further anyway. Oh well, looks like this laptop will sooner rather than later be destined for the mid-Pacific waste mountain where it can happily pollute a few thousand fish and embed plastics in the seabed with a half-life of a few million years. But don't anybody at openSUSE feel guilty though for not fixing this issue over the last 4 years I've been calling for help. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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/ -- _____________________________________ ---This space for rent--- -- 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
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. -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-06-18 at 11:31 +0200, Istvan Gabor wrote:
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.
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. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHARGwACgkQtTMYHG2NR9UThwCfRfGwScR4Mvkd/L8A+2ELtEkG J/oAnjmFTB90e7lygytReAD3FfqdBYq2 =dnRT -----END PGP SIGNATURE----- -- 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
* Anton Aylward
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. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- 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
Istvan Gabor said the following on 06/18/2013 05:31 AM:
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.
I don't have any machines running 12.1 but it sounds like you have other problems. Its hard to tell without seeing the boot logs and your config. Are you running grub or grub2 or what? What about updates? Any other repositories configured?
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.
What are those error messages? Are they the same every time ? Are you connected to the 'net directly or is there a switch or firewall? -- I have a firewall and if there's a problem such as suse coming up before the firewall has done all it needs to then my DNS is delayed and hence other services such as ntp can't start properly and errors cascade..
2. Samba nmb demon occasionally dies or not started at boot.
Again .. logs please.
This never happened in previous SUSE version either.
The changes between 11.4 and 12.1 were very significant! I recall seeing a huge cascade of issues here which warned me off using 12.1. The 12.2 and 12.3 I have were cleaner installs (all that stuff about keeping /home etc) and I still have 11.4 on the older laptop.
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.
Well the changes from 11.4 to 12.1 involved a lot more than the boot process!
The boot does not work well because it was not adjusted correctly to systemd,
I don't think that is the case. As Felix pointed out there were (and still are if you hit them at the right angle) problems with using grub2 that have nothing to do with systemd, sys5init or which kernel you use. I really hate posts like this, Istvan. Without details - logs, details of the exact error messages - than this is no better than the 'non technical' articles that appear in the mainstream press... "Linux expert says Suse doesn't work -- Reuters, 18th June Istvan Gabor, a well known Linux expert, told our reporter that that the openSuse version of Linux cannot be relied on. "It won't boot reliably," he said, "probably because it was adjusted to run with new, experimental software." Oh right, yes, journalists are good at misquoting or rephrasing to suit their 'style' or editorial demand, or simply make it more dramatic. So, give us FACTS. -- "In solving a problem of this sort, the grand thing is to be able to reason backwards. That is a very useful accomplishment, and a very easy one, but people do not practise it much. In the every-day affairs of life it is more useful to reason forwards, and so the other comes to be neglected. There are fifty who can reason synthetically for one who can reason analytically." -- Sherlock Holmes, in "A Study in Scarlet" -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-06-18 at 12:55 -0400, Cristian Rodríguez wrote:
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.
Mmm. The messages I got that both nm and ifup were starting came from systemd >:-) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHAklcACgkQtTMYHG2NR9UIqQCfepnVZMohv/7kW8fsWMOwivH1 coYAn1X+GYWVJ38lVRr6fqbpaUJ6z+of =C1W+ -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-06-18 at 13:39 -0400, Anton Aylward wrote:
Carlos E. R. said the following on 06/18/2013 01:01 PM:
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.
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. 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. Ergo... >;-P 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 - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHApTEACgkQtTMYHG2NR9W6sQCfVAUnKVnp12kuCkFHC2U7MPLP vy8AnAlU6Hdt5bVH3fukA1o1VkzhhpsT =DtFT -----END PGP SIGNATURE----- -- 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
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 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), will mean our systems will be unable/unlikely to move beyond 12.3. 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. -- Per Jessen, Zürich (26.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
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
В 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. 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.
https://bugzilla.novell.com/show_bug.cgi?id=820589
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), will mean our systems will be unable/unlikely to move beyond 12.3. 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.
-- 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
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 ...
I agree with Cristian. a) this is a udev issue not a systemd issue 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. 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! At that level does it really matter what the nomenclature is? "ethX" is nice but the alternative aren't show stoppers. We succeed only as we identify in life, or in war, or in anything else, a single overriding objective, and make all other considerations bend to that one objective. Dwight D. Eisenhower, speech, April 2, 1957 -- 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
-----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
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? -- 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
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
Roger Oberholtzer wrote:
On Wed, 2013-06-19 at 08:13 +0200, Per Jessen wrote:
Carlos E. R. wrote:
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),
Your cards are in a rough(er) environment I guess - I don't recall when I last had to replace a broken network card. The majority of my network interfaces are probably embedded anyway. In my experience, fans, disks, power-supplies and optical drives break and batteries need replacing from time to to time.
replacing it is a pita because the original ethX names are replaced by then next unused ones. Unless you fiddle around in YaST.
Or simply amend '/etc/udev/rules.d/70-persistent-network-names.conf' with the new MAC address.
If the name could be based on the slot the card is in, then swapping out a card would be much easier.
That's what you'll be getting in 13.1. Careful that you put the new card in the same slot, otherwise you'll get a new name.
I need to check how multi-port cards are named based on the slot the card is in...
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. -- Per Jessen, Zürich (23.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:40 AM, Per Jessen
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
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# ? The ensXXX are supposedly for hot-plug slots, but I haven't had time to play with that yet. /Per -- Per Jessen, Zürich (29.7°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
В 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 said the following on 06/19/2013 02:40 AM:
Your cards are in a rough(er) environment I guess - I don't recall when I last had to replace a broken network card.
You're lucky! The clients I deal with seem to have bean-counters dominating some aspects of IT. The servers are all good machines, meaty things from IBM and HP (I had clients that used Data general boxes that were considered suitable for 'raised-floor' use running SVR4-variant but really they were not reliable and WTF it was government anyway... I'm better off out of it), but desktop and issue-laptop are another matter. These seem to be lowest-cost bulk purchase on what I call a 'toilet paper' approach. The servers have support agreements. The desktops don't. They break and they get flushed and a new one is puled from inventory. When inventory gets low another - different - batch of low-cost bulk purchase is set in motion. I've seen over half a dozen clients that do this in one form or another and the bean-counters justify in various details but it always comes down to the same thing. With low cost items its cheaper to replace than repair. And often not just low cost. I have a nice wide-screen LG Flatron that was consigned to the dumpster. I replaced an (obviously to my eyes) blown capacitor and have a working screen :-) I thought OK, and went back to the dumpster for more but it had been emptied :-( So there is the 'Closet of Anxieties - the graveyard of machines that are termed "dead" for one reason or another, but which by playing around with cables, drives, memory maybe one in five can be resurrected. From the bean-counters POV is not with doing, but they are there and in the idle time between fighting other fires ... I can't say its a lifestyle I prefer, but its not as if it amounts to more than a 'hobby'. Still, it beats building models of Rideau Palace out of matchsticks :-) -- 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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-06-19 at 08:13 +0200, Per Jessen wrote:
Carlos E. R. 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?
Nope, I have never seen that. I have eth0, eth1, ppp0, lo, wlan0 in the lappy... and vmnet something for those from vmaware. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHBUJgACgkQtTMYHG2NR9WN6wCfZ6JELegkSRjsXuc3BFZTDRPM jjQAn270/nCiFvDY3xVWRHi3vI0RVHDs =MUgo -----END PGP SIGNATURE----- -- 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 ...
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:02 AM, Per Jessen
The current enumeration of network interfaces ...
1) overall works very well
You are preaching to the wrong chore. 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. Linux is not the only operating system where device names changed from release to release.
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".
3a) corresponds to the style of enumeration used by the manufacturer
Sorry? Who manufactures Linux?
4) is easy to pronounce
For English native speakers. Others may not even know how to pronounce those letters at all.
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? Using net0, net1, etc. It is even easier to pronounce than eth :) Even better would be support for interface aliasing. There were patches floating around. -- 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 Wed, Jun 19, 2013 at 10:41 AM, Dr. Werner Fink
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? -- 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
On Wed, Jun 19, 2013 at 03:41:24AM -0400, Brian K. White wrote:
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 ;)
Then as a clear message: I want to see on the first sight which device are listed and this includes a short and catchy but unique name/number scheme anything else is not not sweet but b*llsh*t ;) 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
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
On Wed, Jun 19, 2013 at 10:33:02AM +0200, Per Jessen wrote:
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?
AFAIK and AFAICS yes. Indeed I've removed my workaround to load the ethernet driver for eth0 (and br0 later on) in initrd. Otherwise it would be very annoying as dsl0 as well as tun0 is on eth0 whereas eth1 is my home intranet 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
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
On Wed, Jun 19, 2013 at 11:25 AM, Per Jessen
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. -- 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
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?" -- 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
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
В 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. -- 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
В Thu, 20 Jun 2013 08:54:05 +0200
Per Jessen
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 ?
Err ... nothing. It is there by default. Just create udev rules to set interface names using whatever criteria suits you. -- 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
Anton Aylward wrote:
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
If anyone is interested - the page above is a bit old, current OUIs can be found here: http://standards.ieee.org/develop/regauth/oui/oui.txt -- Per Jessen, Zürich (30.2°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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-06-19 at 09:25 +0200, Per Jessen wrote:
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' ....
Eternet cero, eternet uno, eternet dos... Easy. Alternatively, we spell the 3 initial letters, then the number.
How will one say 'enp3s1f1'?
Impossible to pronounce or remember. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHBr9oACgkQtTMYHG2NR9UErACgiiMAPYw8tzDYswprFTYhxAWK T2kAmwRVN4K2RViPztzIZyf/eqbx9cmu =HVSw -----END PGP SIGNATURE----- -- 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
Anton Aylward wrote:
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?
Nothing. Partitions have numbered slots. With DOS label, primary 1-4, with GPT label, primary 1-16. -- Per Jessen, Zürich (29.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
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
Per Jessen wrote:
https://bugzilla.novell.com/show_bug.cgi?id=820589 I agree with Cristian. a) this is a udev issue not a systemd issue
Um "systemd.udev" you mean? systemd ate udev... So if it is a udev issue, by definition, it is a systemd issue. -- 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
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 .... -- Robin K Wellington "Harbour City" New Zealand -- 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
On Thu, 20 Jun 2013 08:52:01 +0200 Per Jessen wrote:
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.
Sorry for my little outburst :-) I understand the impetus and rationale, but my eyes always play tricks on me. Couldn't a simple config file, say, a table comparable to /etc/hosts, map these eyeball twisting names into human readable form? Thanks for advocating some sanity, Per! -- 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
Carlos E. R. said the following on 06/18/2013 07:27 PM:
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.
Methinks that one or the other is 'debris' left over from the initial install. -- 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
-----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
-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHBGGYACgkQR6LMutpd94zk2QCeOFr2S5S6QVJDV/Uvteur8vfO s9AAoKf3+L3Sv0D2dhMGzoMi/TGasblD =ym3G -----END PGP SIGNATURE-----
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
On 6/18/2013 1:39 PM, Anton Aylward wrote:
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 :-/
Don't at least ksh and bash implement that in the shell? zsh also has a tcp module but it gives a tcp_shoot command that works like netcat not a virtual device node or file. But you're right, the shell doing it doesn't help your c/other program that would like to do it. That said, I never do use this feature even though it's been around forever in ksh, which I have also been using forever. -- 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
participants (20)
-
Andrey Borzenkov
-
Anton Aylward
-
Brian K. White
-
Bruce Ferrell
-
Carl Hartung
-
Carlos E. R.
-
Carlos E. R.
-
Cristian Rodríguez
-
Dr. Werner Fink
-
Greg Freemyer
-
Istvan Gabor
-
James Knott
-
John Andersen
-
Ken Schneider - openSUSE
-
Linda Walsh
-
Patrick Shanahan
-
Per Jessen
-
Peter
-
Robin Klitscher
-
Roger Oberholtzer