[opensuse] Systemd and fstab
Hi, I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards. What could be the problem? I see the following strange thing: The network method is set to traditional. However systemctl tells me: NetworkManager.service loaded failed failed Network Manager I wonder why NetworkManger is mentioned here. Thanks Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/13/2011 02:44 PM:
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
RTFM Put them in /etc/fstab as server:/home/anton /mnt/server/anton nfs \ comment=systemd.automount 0 0 ^^^^^^^^^^^^^^^^^^^^^^^^^ Now you know what to look for in the documentation :-) OBTW: AutoFS still works, indirect maps and all, but is a bit redundant now. SystemD simplifies so many things by offering a "one ring to rule them all". You just have to know where to touch the ring. The Documentation is Out There -- to coin a phrase. I found this by googling. -- I wonder why. I wonder why. I wonder why I wonder. I wonder why I wonder why I wonder why I wonder! -- Richard Feynman -- 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, 2011-12-13 at 15:00 -0500, Anton Aylward wrote:
RTFM
Put them in /etc/fstab as
server:/home/anton /mnt/server/anton nfs \ comment=systemd.automount 0 0 ^^^^^^^^^^^^^^^^^^^^^^^^^
Now you know what to look for in the documentation :-)
What documentation? After reading your post I can do a google search for "comment=systemd.automount" and find references to it, but not in a manual. Not in a man page, as far as I can see. Man fstab, man mount, man nfs say nothing about that mount option. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7n0QgACgkQtTMYHG2NR9Uy/gCeNeM0Hxo8/bO/mZQuacyF0iDm 70gAn2ZIyEBQHstDws78Kjbw9Fd7yf4D =E5C2 -----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 12/13/2011 05:26 PM:
On Tuesday, 2011-12-13 at 15:00 -0500, Anton Aylward wrote:
RTFM
Put them in /etc/fstab as
server:/home/anton /mnt/server/anton nfs \ comment=systemd.automount 0 0 ^^^^^^^^^^^^^^^^^^^^^^^^^
Now you know what to look for in the documentation :-)
What documentation?
After reading your post I can do a google search for "comment=systemd.automount" and find references to it, but not in a manual. Not in a man page, as far as I can see. Man fstab, man mount, man nfs say nothing about that mount option.
This is about SystemD, right? Did you try man systemd.mount or man systemd.automount ? You can find them using apropos systemd or apropos mount I find 'apropos' useful but you may need to try various arguments. -- Teachers open the door. You enter by yourself. Chinese Proverb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/12/11 19:26, Carlos E. R. wrote:
What documentation?
There is plenty of documentation, probably even more than what sysvinit ever had :) either in the man pages, in Lennart's blog or fedora wikis. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 14 December 2011, Cristian Rodríguez wrote:
On 13/12/11 19:26, Carlos E. R. wrote:
What documentation?
There is plenty of documentation, probably even more than what sysvinit ever had :)
Obviously /etc/fstab is out of sysvinit's focus so no need to be documented there.
either in the man pages, in Lennart's blog or fedora wikis.
Don't blame users for not reading random blogs and random wikis. Changing syntax of such fundamental config files like fstab should have been mentioned in ReleaseNotes. There is a note about encrypted partitions. Why not about nfs? BTW is comment=systemd.automount added for nfs partitions on zypper dup? If not then it would be a another bug. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rüdiger Meier said the following on 12/13/2011 09:51 PM:
Don't blame users for not reading random blogs and random wikis.
For various values of the term 'user' depending on their experience and sophistication, my response is .. BAH HUMBUG! OK, so I'm a few weeks early with the Scrooge channelling. But you can use Google any time of the year. Man pages are just man pages. Great for the command syntax and what the various fields are. Many don't have examples. You want to know how things work, how to "just do it", to coin a phrase, then Go Google" and find the how-to articles, the developers blogs and wikis and the write-ups from the people who have experimented. I've got development time and sysadmin time under my belt, but but I found this by a "go google" and one of the articles I found from an experimenter who poured over the man ages in great detail did say that it was there and LO! it was when I looked, but I'd already got it working from reading a Wiki. I suppose in in that class of user that does "go google".
Changing syntax of such fundamental config files like fstab should have been mentioned in ReleaseNotes. There is a note about encrypted partitions. Why not about nfs?
Encrypted partitions under SystemD? Oh my! So the release notes has sophisticated stuff like that, how to rename files, but not basics like NFS mounting. Yes, I'd like to have everything managed by YAST but until the system is either sysvinit OR systemD and not a blend of the two I think that's going to be horrendous. After all, you could ignore the stuff about systemd.mount/nfs and use the automounter maps with a SystemD system. In fact you can use the automounter AS WELL but things will be a buqqer to debug if you get something in conflict. Perhaps a more sensible approach would be to give up entirely on the sysvinit compatibility, remove the /etc/rc[12345].d compatibility, remove the automounter and make it PURE SystemD. Throw 12.1 in the deep end. Like ripping off the adhesive plaster in one quick jerk. -- The trouble with troubleshooting is that trouble shoots back. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/12/11 00:17, Anton Aylward wrote:
Yes, I'd like to have everything managed by YAST but until the system is either sysvinit OR systemD and not a blend of the two I think that's going to be horrendous.
The yast runlevel editor still needs some hacking for that to really work.
Perhaps a more sensible approach would be to give up entirely on the sysvinit compatibility, remove the /etc/rc[12345].d compatibility, remove the automounter and make it PURE SystemD.
Most services have already native systemd units in Factory so sysvinit scripts are ignored. There are also several init scripts that do stuff they are not supposed to ..like loading kernel modules, working around old bugs..etc..and oh boy, it is an entangled mess :-P -- 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 2011-12-14 03:51, Rüdiger Meier wrote:
On Wednesday 14 December 2011, Cristian Rodríguez wrote:
On 13/12/11 19:26, Carlos E. R. wrote:
What documentation?
There is plenty of documentation, probably even more than what sysvinit ever had :)
But we look for mount options in fstab and mount manuals, not on systemd (and systemv) manuals - which are pretty difficult read, by the way. And the sysvinit was documented on the openSUSE PDF big manual, an entire chapter of well written documentation. Systemd is not.
Obviously /etc/fstab is out of sysvinit's focus so no need to be documented there.
either in the man pages, in Lennart's blog or fedora wikis.
Don't blame users for not reading random blogs and random wikis. Changing syntax of such fundamental config files like fstab should have been mentioned in ReleaseNotes. There is a note about encrypted partitions. Why not about nfs?
Exactly. Many things have changed in this release, and documentation is scarce, unless one is prepared to dig it out from all over internet - which may not apply to openSUSE. Yes, I have been told that in a bugzilla, that those docs do not apply to oS necessarily. The people that have prepared the distro and made the decisions should have taken time to document all that they did. And if they did not have time, the release should have been delayed so that they got the time.
BTW is comment=systemd.automount added for nfs partitions on zypper dup? If not then it would be a another bug.
Nor is it added by the YaST nfs module. I used it the other day and it did not add such an option. I reported a bug on it, and now I see two more that should be added. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk7oHeMACgkQtTMYHG2NR9WU2QCgjrkDva/JYj+LLJIzkEtrzJTe MVwAn0IUgevIFuwLiJWk6QRgAuJDFCjn =JJDx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 13.12.2011 21:00, schrieb Anton Aylward:
Christoph Bartoschek said the following on 12/13/2011 02:44 PM:
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
RTFM
Put them in /etc/fstab as
server:/home/anton /mnt/server/anton nfs \ comment=systemd.automount 0 0 ^^^^^^^^^^^^^^^^^^^^^^^^^
Now you know what to look for in the documentation :-)
OBTW: AutoFS still works, indirect maps and all, but is a bit redundant now. SystemD simplifies so many things by offering a "one ring to rule them all". You just have to know where to touch the ring.
The Documentation is Out There -- to coin a phrase. I found this by googling.
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now. Any additional hints? Thanks Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/14/2011 10:14 AM:
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now.
Any additional hints?
Its not two lines, its one line. I broke it into two (plus the "\" to indicate continuation, which, sadly, I don't think the parser for fstab can handle) so as to make it more readable. Heck, my reader would have line-wrapped anyway. Make it one line, take out the "\". OBTW, what do your logs say? -- "A witty saying proves nothing." -- Voltaire -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 14.12.2011 17:02, schrieb Anton Aylward:
Christoph Bartoschek said the following on 12/14/2011 10:14 AM:
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now.
Any additional hints?
Its not two lines, its one line.
I broke it into two (plus the "\" to indicate continuation, which, sadly, I don't think the parser for fstab can handle) so as to make it more readable.
Heck, my reader would have line-wrapped anyway.
Make it one line, take out the "\".
OBTW, what do your logs say?
I have two nfs mount entries. Therefore I wrote about two lines. My fault. I added the option to each of the nfs mount entries without wrapping. The logs give me no hint. See below. The boot started about at 14:49. At 14:51 there seems to be a timeout. Then the system tries to start the network. However nothing happens for the next hour. At 15:58 I have restarted the machine. Christoph Dec 14 14:49:52 conto kernel: [ 21.724513] e1000 0000:08:02.1: eth2: Intel(R) PRO/1000 Network Connection Dec 14 14:49:52 conto kernel: [ 22.179351] device-mapper: uevent: version 1.0.3 Dec 14 14:49:52 conto kernel: [ 22.179622] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialised: dm-devel@redhat.com Dec 14 14:49:52 conto haveged: haveged starting up Dec 14 14:49:52 conto haveged: arch: x86#012vendor: amd#012generic: 0#012i_cache: 64#012d_cache: 64#012loop_idx: 15#012loop_idxmax: 40#012loop_sz: 64806#012loop_szmax: 100861#012etime: 7959#012havege_ndpt 0 Dec 14 14:49:52 conto avahi-daemon[1104]: Found user 'avahi' (UID 106) and group 'avahi' (GID 107). Dec 14 14:49:52 conto avahi-daemon[1104]: Successfully dropped root privileges. Dec 14 14:49:52 conto avahi-daemon[1104]: avahi-daemon 0.6.30 starting up. Dec 14 14:51:22 conto network[1056]: Failed to get D-Bus connection: Failed to authenticate in time. Dec 14 14:51:23 conto network[1056]: Hint: you may set mandatory devices in /etc/sysconfig/network/config Dec 14 14:51:23 conto network[1056]: Setting up network interfaces: Dec 14 14:51:23 conto network[1056]: lo Dec 14 14:51:23 conto ifup: lo Dec 14 14:51:23 conto ifup: lo Dec 14 14:51:23 conto ifup: IP address: 127.0.0.1/8 Dec 14 14:51:23 conto network[1056]: lo IP address: 127.0.0.1/8 Dec 14 14:51:23 conto ifup: Dec 14 14:51:23 conto network[1056]: ..done eth0 device: Intel Corporation 82557/8/9/0/1 Ethernet Pro Dec 14 14:51:23 conto ifup: eth0 device: Intel Corporation 82557/8/9/0/1 Ethernet Pro Dec 14 14:51:23 conto network[1056]: No configuration found for eth0 Dec 14 14:51:23 conto ifup: No configuration found for eth0 Dec 14 14:51:23 conto network[1056]: ..unused eth1 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:23 conto ifup: eth1 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:23 conto network[1056]: No configuration found for eth1 Dec 14 14:51:23 conto ifup: No configuration found for eth1 Dec 14 14:51:24 conto network[1056]: ..unused eth2 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto ifup: eth2 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto kernel: [ 114.740414] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Dec 14 14:51:24 conto kernel: [ 114.744044] ADDRCONF(NETDEV_UP): eth2: link is not ready Dec 14 14:51:24 conto kernel: [ 114.748115] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Dec 14 14:51:24 conto ifup: eth2 Dec 14 14:51:24 conto ifup: IP address: 192.168.143.203/24 Dec 14 14:51:24 conto network[1056]: eth2 IP address: 192.168.143.203/24 Dec 14 14:51:24 conto ifup: Dec 14 14:51:24 conto network[1056]: ..done eth3 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto ifup: eth3 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto network[1056]: No configuration found for eth3 Dec 14 14:51:24 conto ifup: No configuration found for eth3 Dec 14 14:51:24 conto network[1056]: ..unused eth4 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto ifup: eth4 device: Intel Corporation 82546EB Gigabit Ethernet Co Dec 14 14:51:24 conto network[1056]: No configuration found for eth4 Dec 14 14:51:24 conto ifup: No configuration found for eth4 Dec 14 14:51:24 conto network[1056]: ..unusedSetting up service network . . . . . . . . . ...done Dec 14 15:09:52 conto rsyslogd: -- MARK -- Dec 14 15:29:52 conto rsyslogd: -- MARK -- Dec 14 15:49:53 conto rsyslogd: -- MARK -- Dec 14 15:58:49 conto kernel: imklog 5.8.5, log source = /proc/kmsg started. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/14/2011 11:11 AM:
I have two nfs mount entries. Therefore I wrote about two lines. My fault. I added the option to each of the nfs mount entries without wrapping.
:-)
The logs give me no hint. See below.
Yes, it seems, on the face of it, you have a problem with networking. Of course not knowing your network config ... The examples I gave are bare-bones. I'm not sure what you nfs defaults[1] are but its likely that the mount process is blocking because the network isn't available. If I were you I would consult the documentation on NFS mounting and make those mounts UDP rather than TCP and mount in the background But I would try sorting out your network problems first. [1] See /etc/configuring/nfs and MAN nfsmount.conf(5) -- In the beginning was The Word and The Word was Content-type: text/plain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Christoph Bartoschek said the following on 12/14/2011 11:11 AM:
I have two nfs mount entries. Therefore I wrote about two lines. My fault. I added the option to each of the nfs mount entries without wrapping.
:-)
The logs give me no hint. See below.
Yes, it seems, on the face of it, you have a problem with networking. Of course not knowing your network config ...
The examples I gave are bare-bones. I'm not sure what you nfs defaults[1] are but its likely that the mount process is blocking because the network isn't available.
It looks like it is available though - eth2 comes up fine. -- Per Jessen, Zürich (6.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 14.12.2011 21:41, schrieb Per Jessen:
Anton Aylward wrote:
Christoph Bartoschek said the following on 12/14/2011 11:11 AM:
I have two nfs mount entries. Therefore I wrote about two lines. My fault. I added the option to each of the nfs mount entries without wrapping.
:-)
The logs give me no hint. See below.
Yes, it seems, on the face of it, you have a problem with networking. Of course not knowing your network config ...
The examples I gave are bare-bones. I'm not sure what you nfs defaults[1] are but its likely that the mount process is blocking because the network isn't available.
It looks like it is available though - eth2 comes up fine.
Yes. Network is fine when I start without the comment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/12/11 13:11, Christoph Bartoschek wrote:
Am 14.12.2011 17:02, schrieb Anton Aylward:
Dec 14 14:51:24 conto kernel: [ 114.740414] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Dec 14 14:51:24 conto kernel: [ 114.744044] ADDRCONF(NETDEV_UP): eth2: link is not ready Dec 14 14:51:24 conto kernel: [ 114.748115] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready Dec 14 14:51:24 conto ifup: eth2 Dec 14 14:51:24 conto ifup: IP address: 192.168.143.203/24 Dec 14 14:51:24 conto network[1056]: eth2 IP address: 192.168.143.203/24 Dec 14 14:51:24 conto ifup:
This might help as a workaround... IF the NFS server is reachable with the network interface above (eth2) and it has a fixed ip address, try: mkinitrd -I eth2 and then reboot. -- 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 2011-12-14 16:14, Christoph Bartoschek wrote:
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now.
I use the option "_netdev", documented in man mount (idea of Dave Howort on the forums). This way the line is not attempted when the filesystem are mounted, but later, I think, when the service "nfs" runs. It works for me. Server:/source/where /here nfs defaults,_netdev 0 0 Still, network startup stalls for about half a minute on boot. Don't know why, there is a bugzilla. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk7pFCwACgkQtTMYHG2NR9X7dwCdGgEsVBMl3l4gJDcEVfpAhxm6 FOwAoJibDGfhym/9P+xv/hHu2Y+EDnOQ =XbjV -----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 12/14/2011 04:25 PM:
On 2011-12-14 16:14, Christoph Bartoschek wrote:
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now.
I use the option "_netdev", documented in man mount (idea of Dave Howort on the forums). This way the line is not attempted when the filesystem are mounted, but later, I think, when the service "nfs" runs. It works for me.
Server:/source/where /here nfs defaults,_netdev 0 0
Still, network startup stalls for about half a minute on boot. Don't know why, there is a bugzilla.
Hmm. Try putting "noauto," in there before the "comment=systemd.automount" And check what the default settings are in /etc/sysconfig/nfs -- "I don't mind a parasite, I object to a cut-rate one" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 14.12.2011 22:42, schrieb Anton Aylward:
Carlos E. R. said the following on 12/14/2011 04:25 PM:
On 2011-12-14 16:14, Christoph Bartoschek wrote:
Thanks for the hint. However after adding the two lines the boot hangs. I assume that systemd somehow tries to access the network too early and is hanging now.
I use the option "_netdev", documented in man mount (idea of Dave Howort on the forums). This way the line is not attempted when the filesystem are mounted, but later, I think, when the service "nfs" runs. It works for me.
Server:/source/where /here nfs defaults,_netdev 0 0
Still, network startup stalls for about half a minute on boot. Don't know why, there is a bugzilla.
Hmm.
Try putting "noauto," in there before the "comment=systemd.automount"
And check what the default settings are in /etc/sysconfig/nfs
I tried noauto but it still hangs. /etc/sysconfig/nfs looks innocent for me. I have to enable more informations from systemd. Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek wrote:
Hi,
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
I see the following strange thing:
The network method is set to traditional. However systemctl tells me:
NetworkManager.service loaded failed failed Network Manager
I wonder why NetworkManger is mentioned here.
Yes, that does not make much sense. Have you checked if it is in fact enabled? (I think: systemctl status NetworkManager.service). -- Per Jessen, Zürich (6.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 14.12.2011 21:43, schrieb Per Jessen:
Christoph Bartoschek wrote:
Hi,
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
I see the following strange thing:
The network method is set to traditional. However systemctl tells me:
NetworkManager.service loaded failed failed Network Manager
I wonder why NetworkManger is mentioned here.
Yes, that does not make much sense. Have you checked if it is in fact enabled? (I think: systemctl status NetworkManager.service).
I can check this. But how can it be enabled? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek wrote:
Am 14.12.2011 21:43, schrieb Per Jessen:
Christoph Bartoschek wrote:
Hi,
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
I see the following strange thing:
The network method is set to traditional. However systemctl tells me:
NetworkManager.service loaded failed failed Network Manager
I wonder why NetworkManger is mentioned here.
Yes, that does not make much sense. Have you checked if it is in fact enabled? (I think: systemctl status NetworkManager.service).
I can check this. But how can it be enabled?
Something went wrong during installation or upgrade, I don't know. -- Per Jessen, Zürich (5.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 14.12.2011 23:24, schrieb Per Jessen:
Christoph Bartoschek wrote:
Am 14.12.2011 21:43, schrieb Per Jessen:
Christoph Bartoschek wrote:
Hi,
I have the problem that NFS mounts are not mounted during boot. I have to add them manually afterwards.
What could be the problem?
I see the following strange thing:
The network method is set to traditional. However systemctl tells me:
NetworkManager.service loaded failed failed Network Manager
I wonder why NetworkManger is mentioned here.
Yes, that does not make much sense. Have you checked if it is in fact enabled? (I think: systemctl status NetworkManager.service).
I can check this. But how can it be enabled?
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd? cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 15.12.2011 11:53, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd?
Shouldn't this also work with systemd? The earlier one gets rid of its bugs one the better. Or will systemd never replace sysvinit for serious work? Christoph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/15/2011 11:58 AM, Christoph Bartoschek wrote:
Am 15.12.2011 11:53, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd?
Shouldn't this also work with systemd? The earlier one gets rid of its bugs one the better.
It should work - the question will just help in figuring out the reasons.
Or will systemd never replace sysvinit for serious work?
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-( Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger wrote:
On 12/15/2011 11:58 AM, Christoph Bartoschek wrote:
Or will systemd never replace sysvinit for serious work?
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
Somebody ought to write a bug report on that. -- Per Jessen, Zürich (8.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger said the following on 12/15/2011 06:05 AM:
't this also work with systemd? The earlier one gets rid of its
bugs one the better. It should work - the question will just help in figuring out the reasons.
Or will systemd never replace sysvinit for serious work?
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
Really, there's a lot more we don't know. If Christoph is trying to get the system to work 'like it did before' then what was he doing to automount the NFS? Why all the network interfaces? Where do they lead? Which one leads to the NFS server? The man page on systemd.mount does say that
When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points from /etc/fstab.
If comment=systemd.mount is specified as mount option, then systemd will create a dependency of type Wants from either local-fs.target or remote-fs.target, depending whether the file system is local or remote. If comment=systemd.automount is set, an automount unit will be created for the file system. See systemd.automount(5) for details.
If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.
Are there some unit files created by the installation process? Perhaps that would be a better approach since they could be made dependent on the specific Ethernet port that leads to the NFS server being active. -- We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. -- T.S. Eliot -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Anton Aylward wrote:
If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.
Are there some unit files created by the installation process? Perhaps that would be a better approach since they could be made dependent on the specific Ethernet port that leads to the NFS server being active.
The ethernet port which a specific nfs mount depend on cannot be set always staically. Dependencies are like this: server FQDN -> server IP -> route to server/client IP -> client ethernet port The mount command itself invokes the DNS query to resolve the server name thus you can't know before what route and finally which port will be used. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier said the following on 12/15/2011 07:44 AM:
On Thursday 15 December 2011, Anton Aylward wrote:
If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.
Are there some unit files created by the installation process? Perhaps that would be a better approach since they could be made dependent on the specific Ethernet port that leads to the NFS server being active.
The ethernet port which a specific nfs mount depend on cannot be set always staically. Dependencies are like this: server FQDN -> server IP -> route to server/client IP -> client ethernet port
The mount command itself invokes the DNS query to resolve the server name thus you can't know before what route and finally which port will be used.
Are you describing the dependency relationships that are explicitly made clear in the SystemD units and target or are you describing what is "hidden in the code" of the way pre-SystemD mount works? Or maybe the problem Christoph has arises because this hidden code hasn't been purged in 12.1 and has in Fedora-15 and is in conflict with the SystemD way of doing things? -- Almost all quality improvement comes via simplification of design,manufacturing, layout, processes, and procedures. -- Tom Peters -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Anton Aylward wrote:
Ruediger Meier said the following on 12/15/2011 07:44 AM:
On Thursday 15 December 2011, Anton Aylward wrote:
Are there some unit files created by the installation process? Perhaps that would be a better approach since they could be made dependent on the specific Ethernet port that leads to the NFS server being active.
The ethernet port which a specific nfs mount depend on cannot be set always staically. Dependencies are like this: server FQDN -> server IP -> route to server/client IP -> client ethernet port
The mount command itself invokes the DNS query to resolve the server name thus you can't know before what route and finally which port will be used.
Are you describing the dependency relationships that are explicitly made clear in the SystemD units and target or are you describing what is "hidden in the code" of the way pre-SystemD mount works?
No, just wanted to mention that in general nobody (including systemd) can't find out for sure which network device is needed to mount a specific NFS directory before actually trying to mount it. So your above idea "...they could be made dependent on the specific Ethernet port that leads to the NFS server ..." is IMO not possible. It has to be generic like "waiting for complete network setup" and then try nfs mount (hoping that there is a device to reach the server). Of course if admin knows what he is doing then he could replace the generic deps by more specific ones but no way to do this in systemd's default config. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ruediger Meier said the following on 12/15/2011 08:45 AM:
No, just wanted to mention that in general nobody (including systemd) can't find out for sure which network device is needed to mount a specific NFS directory before actually trying to mount it.
So your above idea "...they could be made dependent on the specific Ethernet port that leads to the NFS server ..." is IMO not possible. It has to be generic like "waiting for complete network setup" and then try nfs mount (hoping that there is a device to reach the server).
Of course if admin knows what he is doing then he could replace the generic deps by more specific ones but no way to do this in systemd's default config.
Lets make sure we agree. The system by itself can't tell which port a NFS mount needs until it happens. OK The sysadmin, the guy who configured the system, knows which network segment the NFS server is on and which Ethernet port connects to that network segment, so he (or she) can configure the specific mount unit files for SystemD. This knowledge is "external to the system" and part of the human-level design. OK? -- Of all things, good sense is the most fairly distributed: everyone thinks he is so well supplied with it that even those who are the hardest to satisfy in every other respect never desire more of it than they already have. - Rene Descartes (1596-1650), Discours de la Methode (1637) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Anton Aylward wrote:
Lets make sure we agree.
The system by itself can't tell which port a NFS mount needs until it happens.
OK
The sysadmin, the guy who configured the system, knows which network segment the NFS server is on and which Ethernet port connects to that network segment, so he (or she) can configure the specific mount unit files for SystemD. This knowledge is "external to the system" and part of the human-level design.
OK?
Yes. Allthough I still would not really recommend to optimize the deps too much by hardcoding such "external knowledge" because you will have a lot more work in case hardware or network changes. IMO the highest aim is to have completely identical config on all clients regardless different hardware or dynamic config stuff (dns, network, users, etc). cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/15/2011 10:16 AM, Anton Aylward wrote:
Ruediger Meier said the following on 12/15/2011 08:45 AM:
No, just wanted to mention that in general nobody (including systemd) can't find out for sure which network device is needed to mount a specific NFS directory before actually trying to mount it.
So your above idea "...they could be made dependent on the specific Ethernet port that leads to the NFS server ..." is IMO not possible. It has to be generic like "waiting for complete network setup" and then try nfs mount (hoping that there is a device to reach the server).
Of course if admin knows what he is doing then he could replace the generic deps by more specific ones but no way to do this in systemd's default config.
Lets make sure we agree.
The system by itself can't tell which port a NFS mount needs until it happens.
OK
The sysadmin, the guy who configured the system, knows which network segment the NFS server is on and which Ethernet port connects to that network segment, so he (or she) can configure the specific mount unit files for SystemD. This knowledge is "external to the system" and part of the human-level design.
No he does not at all except in the most simple and static situations. Not any more than you should have to know at boot time, or any other time, what nic will be needed to reach an ftp or ntp or http or smtp or any other kind of service.
OK?
No not at all. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2011-12-15 at 20:06 -0500, Brian K. White wrote:
No he does not at all except in the most simple and static situations. Not any more than you should have to know at boot time, or any other time, what nic will be needed to reach an ftp or ntp or http or smtp or any other kind of service.
You do if you are writing routing tables. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qmq8ACgkQtTMYHG2NR9XPjgCeJKa3a9Bgr2+Wc9QzSDLQPJLH CjoAn0xTdUyzXEW7KDbVQavSWs053weS =iT2I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/15/2011 8:11 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2011-12-15 at 20:06 -0500, Brian K. White wrote:
No he does not at all except in the most simple and static situations. Not any more than you should have to know at boot time, or any other time, what nic will be needed to reach an ftp or ntp or http or smtp or any other kind of service.
You do if you are writing routing tables.
Not even slightly! Routing tables describe how to reach IP's not how to reach services or hostnames. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/15/2011 08:40 PM:
You do if you are writing routing tables. Not even slightly! Routing tables describe how to reach IP's not how to reach services or hostnames.
I think you are just so missing the point Carlos and I am trying to make. Its about EXTERNAL KNOWLEDGE as in the knowledge that the sysadmin has. He KNOWS the wiring, the IP address of the server that has the NFS services. That's why he's 'hard wiring' things. -- Hackers: Self-righteous crackers -- CSO Magazine's "The Devil's Infosec Dictionary" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/15/2011 08:06 PM:
The sysadmin, the guy who configured the system, knows which network segment the NFS server is on and which Ethernet port connects to that network segment, so he (or she) can configure the specific mount unit files for SystemD. This knowledge is "external to the system" and part of the human-level design.
No he does not at all except in the most simple and static situations. Not any more than you should have to know at boot time, or any other time, what nic will be needed to reach an ftp or ntp or http or smtp or any other kind of service.
What I'm saying is that the nfs server is on a network segment and that network segment is connected to one ethernet port. I'm saying that about the situation Christoph is in, not about every possible case that could exist. I'm saying that Christoph has the knowledge of what the wiring of his network is. I'm not saying that he knows of every possible configuration that it could be, only that he knows what it *IS*. And I'm asking 'why are there those other, apparently dead, ethernet ports?' I'm saying this because I'm trying to solve Christoph's problem, not do a general solution for an abstract situation. -- Entropy isn't what it used to be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/15/2011 8:23 PM, Anton Aylward wrote:
Brian K. White said the following on 12/15/2011 08:06 PM:
The sysadmin, the guy who configured the system, knows which network segment the NFS server is on and which Ethernet port connects to that network segment, so he (or she) can configure the specific mount unit files for SystemD. This knowledge is "external to the system" and part of the human-level design.
No he does not at all except in the most simple and static situations. Not any more than you should have to know at boot time, or any other time, what nic will be needed to reach an ftp or ntp or http or smtp or any other kind of service.
What I'm saying is that the nfs server is on a network segment and that network segment is connected to one ethernet port.
I'm saying that about the situation Christoph is in, not about every possible case that could exist.
I'm saying that Christoph has the knowledge of what the wiring of his network is. I'm not saying that he knows of every possible configuration that it could be, only that he knows what it *IS*.
And I'm asking 'why are there those other, apparently dead, ethernet ports?'
I'm saying this because I'm trying to solve Christoph's problem, not do a general solution for an abstract situation.
If you are only trying to debug the immediate situation then ok. As in, if you're just trying to nail down what the automatic process actually did when it came time to do it. I thought you were suggesting that it's acceptable to expect that config files have nics defined in them for a client to reach a service. That would be unreasonable. For offering services that's different. But a client should not have to know what nic is required to reach a service other than maybe a dhcp client. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White said the following on 12/15/2011 08:48 PM:
If you are only trying to debug the immediate situation then ok. As in, if you're just trying to nail down what the automatic process actually did when it came time to do it.
Yes; and much of that is now off-list.
I thought you were suggesting that it's acceptable to expect that config files have nics defined in them for a client to reach a service. That would be unreasonable. For offering services that's different. But a client should not have to know what nic is required to reach a service other than maybe a dhcp client.
In the general, I agree, but not - NEVER - where specifics define it. Many v-for-verySMB and home networks are pretty trivial and strapping them down can avoid other hassles. Such trivial systems don't need their own DHCP or their own DNS server. I imagine most single-machine home system are like that. They simply don't warrant the complexity. Having a defined chain where things absolutely HAVE to be in the set ordering makes phone debugging a lot easier when you're dealing with people who can't tell the difference between a d CD drive and a coffee cup holder. -- "With more success, comes greater problems along with greater ability to solve them." -- Mark Victor Hansen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/15/2011 9:00 PM, Anton Aylward wrote:
Brian K. White said the following on 12/15/2011 08:48 PM:
If you are only trying to debug the immediate situation then ok. As in, if you're just trying to nail down what the automatic process actually did when it came time to do it.
Yes; and much of that is now off-list.
I thought you were suggesting that it's acceptable to expect that config files have nics defined in them for a client to reach a service. That would be unreasonable. For offering services that's different. But a client should not have to know what nic is required to reach a service other than maybe a dhcp client.
In the general, I agree, but not - NEVER - where specifics define it. Many v-for-verySMB and home networks are pretty trivial and strapping them down can avoid other hassles. Such trivial systems don't need their own DHCP or their own DNS server. I imagine most single-machine home system are like that. They simply don't warrant the complexity. Having a defined chain where things absolutely HAVE to be in the set ordering makes phone debugging a lot easier when you're dealing with people who can't tell the difference between a d CD drive and a coffee cup holder.
I would say the opposite. Small customer networks (1 to 50 devices, no dedicated IT staff or even anyone halfway conversant) got 50 thousand times easier to maintain after commodity routers and dhcp became the norm. Making something automatic and dynamic involves more complex code somewhere, but makes the install, use, and administration simpler far more often than it makes it more complex. Only when the automatic protocol is garbage and unreliable does it make things harder. I still configure printers with static IP's because allowing them to dhcp and relying on netbios to resolve their names fails more often than the static config breaks due to the customer changing things. Hard coding things is simply a guaranteed way for them to break sooner or later, and when it does, the unusualness of hard coding something will waste the time of the guy who gets called in to fix it, or simply be beyond them utterly since so many local IT guys are so bad. True a hard coded thing will not ever break all by itself because it itself never changes. Then again it will never fix itself either. And automatic/dynamic things may break sometimes because the extra complexity means more opportunities to break. But they will often fix themselves. Everything is always changing. Very small business owners routinely break everything I ever set up hard coded because they replace printers and workstations, their whole cable/dsl/fios connections, routers, firewalls, everything, willy nilly. And then, after they do it and have sent the grocery bagger slash cable modem installer home, and they finally discover that everyone can get on the internet but no one can get on the local server, then, though I didn't cause this emergency and was not even warned it was going to happen, I still have to drop whatever else I was doing and fix them immediately because they can't work until I do... Only the automatic stuff has any chance to keep working. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, It is quite embarassing but I have found my problem. Starting with 11.4 the nfs service is not starting automatically. One has to enable it for runlevels 3,5 to get automatically mounted remote filesystems. I wonder why I thought that this problem started with 12.1. I think the few 11.4 machines we have were not rebooted after initial setup so the problem did not appear. To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service. Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment. Thanks to anyone who looked into this issue. Christoph Am 15.12.2011 13:14, schrieb Anton Aylward:
Andreas Jaeger said the following on 12/15/2011 06:05 AM:
't this also work with systemd? The earlier one gets rid of its
bugs one the better. It should work - the question will just help in figuring out the reasons.
Or will systemd never replace sysvinit for serious work?
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
Really, there's a lot more we don't know. If Christoph is trying to get the system to work 'like it did before' then what was he doing to automount the NFS?
Why all the network interfaces? Where do they lead? Which one leads to the NFS server?
The man page on systemd.mount does say that
When reading /etc/fstab a few special mount options are understood by systemd which influence how dependencies are created for mount points from /etc/fstab.
If comment=systemd.mount is specified as mount option, then systemd will create a dependency of type Wants from either local-fs.target or remote-fs.target, depending whether the file system is local or remote. If comment=systemd.automount is set, an automount unit will be created for the file system. See systemd.automount(5) for details.
If a mount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.
Are there some unit files created by the installation process? Perhaps that would be a better approach since they could be made dependent on the specific Ethernet port that leads to the NFS server being active.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/15/2011 07:51 AM:
t is quite embarassing but I have found my problem. Starting with 11.4 the nfs service is not starting automatically. One has to enable it for runlevels 3,5 to get automatically mounted remote filesystems.
I wonder why I thought that this problem started with 12.1. I think the few 11.4 machines we have were not rebooted after initial setup so the problem did not appear.
To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service.
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
I'm sorry, this makes no sense to me. NFS doesn't mount the file systems. You mount them in the automounter or the fstab with 11.4 or with explicit units or the fstab with SystemD In both pre- and post- SystemD the NFS server is in the kernel. Go grep.
ps -ef | grep nfs root 12354 2 0 08:30 ? 00:00:00 [nfsiod] root 12365 8299 0 08:30 pts/0 00:00:00 grep nfs
I've quoted the lines from the systemd.mount man page. It clearly states that the systemd functions take care of the mounting. My complaint here is that there isn't enough logging form systemD appearing in the system logs that Christoph supplied. As I've said, I be happy to take this off list with Christoph and do a detailed gap analysis against a system where this automount works. -- It is against the grain of modern education to teach children to program. What fun is there in making plans, acquiring discipline in organizing thoughts, devoting attention to detail, and learning to be self-critical? -- Alan Perlis -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Anton Aylward wrote:
Christoph Bartoschek said the following on 12/15/2011 07:51 AM:
t is quite embarassing but I have found my problem. Starting with 11.4 the nfs service is not starting automatically. One has to enable it for runlevels 3,5 to get automatically mounted remote filesystems.
I wonder why I thought that this problem started with 12.1. I think the few 11.4 machines we have were not rebooted after initial setup so the problem did not appear.
To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service.
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
I'm sorry, this makes no sense to me.
NFS doesn't mount the file systems.
You mount them in the automounter or the fstab with 11.4 or with explicit units or the fstab with SystemD
There should be no need to use automounter to mount NFS dirs. After knowing Christoph's real problem we see that this is still true even using systemd. So everything is fine. Even the flame about possible bugs and missing docu on the other part of this thread was useless: - there is nothing wrong with 12.1 ReleaseNotes about nfs - man fstab is still valid - no need to read random blogs just to know how to mount very common file systems cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-12-15 at 15:09 +0100, Ruediger Meier wrote:
On Thursday 15 December 2011, Anton Aylward wrote:
Christoph Bartoschek said the following on 12/15/2011 07:51 AM:
t is quite embarassing but I have found my problem. Starting with 11.4 the nfs service is not starting automatically. One has to enable it for runlevels 3,5 to get automatically mounted remote filesystems.
I wonder why I thought that this problem started with 12.1. I think the few 11.4 machines we have were not rebooted after initial setup so the problem did not appear.
To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service.
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
I'm sorry, this makes no sense to me.
NFS doesn't mount the file systems.
You mount them in the automounter or the fstab with 11.4 or with explicit units or the fstab with SystemD
There should be no need to use automounter to mount NFS dirs. After knowing Christoph's real problem we see that this is still true even using systemd.
My only need for automounter is when the client and server boot at the same time. If NFS is set to not block when mounting (via an entry in /etc/fstab), when the server is not ready when the client tries, the non-blocking mount will, as expected, not block - or mount. And the mount will never happen again. If it is an automount, there is the added delay in the client of the user needing to log in (assuming the mount is a user-related mount). -- Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST 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
Am 15.12.2011 14:39, schrieb Anton Aylward:
Christoph Bartoschek said the following on 12/15/2011 07:51 AM:
t is quite embarassing but I have found my problem. Starting with 11.4 the nfs service is not starting automatically. One has to enable it for runlevels 3,5 to get automatically mounted remote filesystems.
I wonder why I thought that this problem started with 12.1. I think the few 11.4 machines we have were not rebooted after initial setup so the problem did not appear.
To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service.
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
I'm sorry, this makes no sense to me.
NFS doesn't mount the file systems.
You mount them in the automounter or the fstab with 11.4 or with explicit units or the fstab with SystemD
In both pre- and post- SystemD the NFS server is in the kernel. Go grep.
ps -ef | grep nfs root 12354 2 0 08:30 ? 00:00:00 [nfsiod] root 12365 8299 0 08:30 pts/0 00:00:00 grep nfs
I've quoted the lines from the systemd.mount man page. It clearly states that the systemd functions take care of the mounting.
My complaint here is that there isn't enough logging form systemD appearing in the system logs that Christoph supplied.
As I've said, I be happy to take this off list with Christoph and do a detailed gap analysis against a system where this automount works.
Hi, for me it seems as if in opensuse 12.1 systemd is not directly responsible for mounting NFS filesystems. Instead there is still the /etc/init.d/nfs script that is started after the network has been brought up. Systemd correctly starts the scripts and I am fine. Obviously systemd has the feature to manage NFS mounts directly. This is indicated by the comment=systemd.automount option. However using this option alone leads to a hang on my system. Maybe this is related to the fact that the network cable is attached to eth2 and not eth0. I do not know. I also do not know whether systemd tried to bring up the network before it tried to mount the filesystems. I even do not know whether it tried to mount the filesystems at all. If you want to dig further into the issue I can run some tests. But you have to give me specific instructions on what you would like to see and how to generate this. Christoph -- 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 Thursday, 2011-12-15 at 08:39 -0500, Anton Aylward wrote:
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
I'm sorry, this makes no sense to me.
NFS doesn't mount the file systems.
You mount them in the automounter or the fstab with 11.4 or with explicit units or the fstab with SystemD
Wrong. The nfs service does mount and umount fstab nfs entries. See: Elanor:~ # mount | grep zyp Telcontar.valinor:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.131,minorversion=0,local_lock=none,addr=192.168.1.14,_netdev) Elanor:~ # rcnfs stop redirecting to systemctl Elanor:~ # mount | grep zyp Elanor:~ # rcnfs start redirecting to systemctl Elanor:~ # mount | grep zyp Telcontar.valinor:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.131,minorversion=0,local_lock=none,addr=192.168.1.14,_netdev) Elanor:~ # - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qU8EACgkQtTMYHG2NR9Ud0gCfUKo6Qh75QkbY+QJmZZ8+u09Z M4kAnAxISdm0UzMW7J+CChrkoNKnsYGJ =29+R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2011-12-15 at 13:51 +0100, Christoph Bartoschek wrote:
To sum up: for opensuse systemd is not responsible for mounting remote filesystems. It is the nfs service.
Yes, of course, but systemd runs the nfs service.
Enabling the service solves the problem. However it does not solve the hang with comment=systemd.automount. So I had to remove the comment.
You can try instead the _netdev option I told you about several messages ago. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qU5gACgkQtTMYHG2NR9WGawCgglMU2iErYYEnuJ8Eyuk4h+Mu 0bgAmwf7paWLDoKa7xQNuNCYf4Vix4I5 =gihZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users. Failing that, make it easy to switch back to the old method. Two problems I have with systemd is networking (ifup) fails to start reliably on two separtate computers. Also, fetchmail flat out doesn't work with systemd, but works fine with system v. And many of us were surprised to find postfix needs to be separately enabled outside of System Services. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Dec 15, 2011 at 10:04:01AM -0500, James Knott wrote:
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users.
Yes, you as the community have to test more and better. It's a shame how bad you performed as part of the openSUSE 12.1 release process. ;) *scnr* For the other issues please ensure to keep things focused in one bug report per issue. Thanks. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Thursday 15 December 2011, Lars Müller wrote:
On Thu, Dec 15, 2011 at 10:04:01AM -0500, James Knott wrote:
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users.
Yes, you as the community have to test more and better. It's a shame how bad you performed as part of the openSUSE 12.1 release process. ;)
On the other hand this shows that not enough users were "pulling on the systemd end" (to use coolo's phrase). But we've got it nevertheless. IMO there is nothing wrong with not testing a thing (systemd) which I'm not interested in. But if I will be "forced" to use that thing then I expect that the ones who are forcing me have seen enough tests. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Dec 15, 2011 at 07:10:18PM +0100, Ruediger Meier wrote:
On Thursday 15 December 2011, Lars Müller wrote:
On Thu, Dec 15, 2011 at 10:04:01AM -0500, James Knott wrote:
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users.
Yes, you as the community have to test more and better. It's a shame how bad you performed as part of the openSUSE 12.1 release process. ;)
On the other hand this shows that not enough users were "pulling on the systemd end" (to use coolo's phrase). But we've got it nevertheless.
See my other mail, the majority doesn't care till a release is available. Yes, there had not been enough people at the other end. And at the end I'm happy about this. Even if it had also caused some pain to myself. Fortunately or unfortunately. Here at openSUSE it is as it is with most Open Source Software projects. Those doing the work are deciding how things are going forward.
IMO there is nothing wrong with not testing a thing (systemd) which I'm not interested in. But if I will be "forced" to use that thing then I expect that the ones who are forcing me have seen enough tests.
I'm sure Frederic and Coolo tested this quite well on their own development systems. I've tested it too on my workstation. At the end based on this I guess we had 2 working to one maybe failing systems out of three. Not an optimal result but enough to release it. ;) Thanks. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Lars Müller wrote:
On Thu, Dec 15, 2011 at 10:04:01AM -0500, James Knott wrote:
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users.
Yes, you as the community have to test more and better. It's a shame how bad you performed as part of the openSUSE 12.1 release process. ;)
How about we delay a release until it's been properly tested? -- Per Jessen, Zürich (6.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Dec 15, 2011 at 07:24:08PM +0100, Per Jessen wrote:
Lars Müller wrote:
On Thu, Dec 15, 2011 at 10:04:01AM -0500, James Knott wrote:
Andreas Jaeger wrote:
It will, the issues that came up now are getting fixed. Seems not enough people tested it before the release in earnest ;-(
When you make a significant change, such as this, you'd better do a *LOT* of testing before inflicting it on innocent users.
Yes, you as the community have to test more and better. It's a shame how bad you performed as part of the openSUSE 12.1 release process. ;)
How about we delay a release until it's been properly tested?
Then we'll not see any further release. The much I complained about this unconditional - not depending on if this is an initial install or upgrade case - switch the much I have to stress that we have to keep the matrix of possible install combinations small. Therefore I hope sysvinit will get dropped as soon as possible. The openSUSE 12.1 release demonstrated again quite well how the release process works. Quite a few people test pre, rc, and release cnadidates. Not to speak about the snapshots before. And as soon as the final version is available the majority is surprised what going on and wrong. Surprise, surprise. :/ What would be the benefit of additional three months? Three further months the same people would test it while the same other gang waits for the final release. Having a defined schedule and clear dates communicated I consider very important. If I look from this view to the release of 12.1 I have to stress Coolo did quite a good job. If you see real steps beyond a general delay of some weeks or months how to drive this better I'm sure all are happy to enhance the process. Cheers Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 15/12/11 15:50, Lars Müller wrote:
Therefore I hope sysvinit will get dropped as soon as possible.
I have the same desire, having two init systems in supported state is madness, the number of use cases, scenarios and bugs make that unsustainable in the short term. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 15/12/11 15:50, Lars Müller wrote:
Therefore I hope sysvinit will get dropped as soon as possible.
I have the same desire, having two init systems in supported state is madness, the number of use cases, scenarios and bugs make that unsustainable in the short term.
I completely agree, but I also recognise that as the everyday situation for any professional sysadmin venturing on to 12.1 now. -- Per Jessen, Zürich (5.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-12-15 at 20:11 +0100, Per Jessen wrote:
Cristian Rodríguez wrote:
On 15/12/11 15:50, Lars Müller wrote:
Therefore I hope sysvinit will get dropped as soon as possible.
I have the same desire, having two init systems in supported state is madness, the number of use cases, scenarios and bugs make that unsustainable in the short term.
I completely agree, but I also recognise that as the everyday situation for any professional sysadmin venturing on to 12.1 now.
I think for 12.1 having the two systems is a good idea. People can properly test their new scripts. At least this is what I will be doing. When I know they work in the new system, I will remove the old ones from our code. In addition, having only the new system means either you cannot install software that uses the old system, or you have to modify all those packages as well. Just because the distros have changed things does not mean all packages have also made the transition. I guess the down side is that a hell of a lot of work went in to allowing both to work, with the full knowledge that the work is intended to be used for a limited time. -- Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST 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 Thu, 2011-12-15 at 20:11 +0100, Per Jessen wrote:
Cristian Rodríguez wrote:
On 15/12/11 15:50, Lars Müller wrote:
Therefore I hope sysvinit will get dropped as soon as possible.
I have the same desire, having two init systems in supported state is madness, the number of use cases, scenarios and bugs make that unsustainable in the short term.
I completely agree, but I also recognise that as the everyday situation for any professional sysadmin venturing on to 12.1 now.
I think for 12.1 having the two systems is a good idea.
I think for 12.1 remaining on 11.4 for production is a much better idea :-)
In addition, having only the new system means either you cannot install software that uses the old system, or you have to modify all those packages as well. Just because the distros have changed things does not mean all packages have also made the transition.
systemd was promised to be 100% backwards compatible, so that should not be a problem. OTOH, I have just tried installing an init-script on a new 12.1 system: "# insserv firewall insserv: Service network is missed in the runlevels 2 to use service xxx -- Per Jessen, Zürich (5.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 16:59, Per Jessen wrote:
systemd was promised to be 100% backwards compatible,
It is.. now that we should use those backward compatibility features in future releases is another story (hint, it does not make any sense)
"# insserv firewall insserv: Service network is missed in the runlevels 2 to use service xxx
Which is a bug in the init script you are using and has nothing to do with systemd, insserv is just telling you that it is broken ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 15/12/11 16:59, Per Jessen wrote:
systemd was promised to be 100% backwards compatible,
It is.. now that we should use those backward compatibility features in future releases is another story (hint, it does not make any sense)
+1
"# insserv firewall insserv: Service network is missed in the runlevels 2 to use service xxx
Which is a bug in the init script you are using and has nothing to do with systemd, insserv is just telling you that it is broken ;-)
Funny, it has been working for 5+ years, right up until I upgraded to 12.1 today. It's quite possible that it is broken, but being backwards compatible includes being compatible with the same bugs :-) -- Per Jessen, Zürich (5.9°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Cristian Rodríguez wrote:
On 15/12/11 16:59, Per Jessen wrote:
systemd was promised to be 100% backwards compatible,
It is.. now that we should use those backward compatibility features in future releases is another story (hint, it does not make any sense)
+1
"# insserv firewall insserv: Service network is missed in the runlevels 2 to use service xxx
Which is a bug in the init script you are using and has nothing to do with systemd, insserv is just telling you that it is broken ;-)
Funny, it has been working for 5+ years, right up until I upgraded to 12.1 today.
Actually, I think this was a 10.2 server I was upgrading, might be a little too much to ask wrt backwards compatibility. :-) -- Per Jessen, Zürich (6.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 17:14, Per Jessen wrote:
Funny, it has been working for 5+ years,
No, it has been permissive and silent for that period of time .. see rpm -qf --changelog /sbin/insserv| less
It's quite possible that it is broken, but being backwards compatible includes being compatible with the same bugs :-)
That message is again not emitted by systemd but by the venerable insserv. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 16:59, Per Jessen wrote:
systemd was promised to be 100% backwards compatible,
It is.. now that we should use those backward compatibility features in future releases is another story (hint, it does not make any sense)
"# insserv firewall insserv: Service network is missed in the runlevels 2 to use service xxx
Which is a bug in the init script you are using and has nothing to do with systemd, insserv is just telling you that it is broken ;-)
I guess it's not even a bug within the init script. Looks like "network" is not enabled in runlevel 2 anymore but xxx depends on network and wants to be enabled in runlevel 2. So either enable network for runlevel 2 again or remove 2 from xxx's "Default-Start:" BTW I think inserv's complaint is just a warning and not an error. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 16:52, Roger Oberholtzer wrote:
I think for 12.1 having the two systems is a good idea.
No, not really, but as we cannot migrate everything at time, it saves the day as a workaround.
People can properly test their new scripts.
This is what I hoped it would happend, reality is that instead of testing and filling bug reports they come here to whine about it, making all sort of BS arguments, such as appeals to tradition, ad hominems against the people who work in systemd without providing any proof whatsoever.
At least this is what I will be doing.
Great, that's constructive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 15/12/11 16:52, Roger Oberholtzer wrote:
I think for 12.1 having the two systems is a good idea.
No, not really, but as we cannot migrate everything at time, it saves the day as a workaround.
People can properly test their new scripts.
This is what I hoped it would happend, reality is that instead of testing and filling bug reports they come here to whine about it,
Wow, how constructive you are too. -- Per Jessen, Zürich (5.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
This is what I hoped it would happend, reality is that instead of testing and filling bug reports they come here to whine about it, making all sort of BS arguments, such as appeals to tradition, ad hominems against the people who work in systemd without providing any proof whatsoever.
Actually, I was part of the testing process with both RC1 & RC2. I found some problems, but not the ones I'm experiencing with other systems, where I do more. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lars Müller wrote:
If you see real steps beyond a general delay of some weeks or months how to drive this better I'm sure all are happy to enhance the process.
I am continuing this thread on opensuse-testing, it's not really appropriate here. Maybe it belongs on opensuse-project, I'm not sure. -- Per Jessen, Zürich (6.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 2011-12-15 at 19:50 +0100, Lars Müller wrote:
The openSUSE 12.1 release demonstrated again quite well how the release process works. Quite a few people test pre, rc, and release cnadidates. Not to speak about the snapshots before. And as soon as the final version is available the majority is surprised what going on and wrong. Surprise, surprise. :/
What would be the benefit of additional three months? Three further months the same people would test it while the same other gang waits for the final release.
+1 -- Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST 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
Lars Müller said the following on 12/15/2011 01:50 PM:
Therefore I hope sysvinit will get dropped as soon as possible.
+1 -- Asking if computers can think is like asking if submarines can swim. -- 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 Thursday, 2011-12-15 at 19:24 +0100, Per Jessen wrote:
How about we delay a release until it's been properly tested?
It would not work. Most people will not try the distro until it is released, and expect it to work. Why no more volunteers to do testing? Well, it is difficult, you need expertise, you need space in the disk, or an extra computer, etc. You have to entice testers somehow. The advantages a user gets out of testing early are not clear. Instead, you have to consider the first month of a release life as an added test period, and live with it. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qVWEACgkQtTMYHG2NR9UdWQCgi1LYCKs9feXGoeYvAfrMX3Qw Lp8An2aqBQQHWUo9LGvCx183cefPoPc8 =gxuL -----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 Thursday, 2011-12-15 at 19:24 +0100, Per Jessen wrote:
How about we delay a release until it's been properly tested?
It would not work. Most people will not try the distro until it is released, and expect it to work.
Agree, that is how most regular users work.
Why no more volunteers to do testing? Well, it is difficult, you need expertise, you need space in the disk, or an extra computer, etc.
I don't believe "more testers" => "more areas tested" - at best, it might mean "same areas tested more".
You have to entice testers somehow. The advantages a user gets out of testing early are not clear.
Exactly my point, see my recent posting to opensuse-testing. -- Per Jessen, Zürich (6.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Why no more volunteers to do testing? Well, it is difficult, you need expertise, you need space in the disk, or an extra computer, etc. I don't believe "more testers" => "more areas tested" - at best, it might mean "same areas tested more".
I guess it depends on areas of interest. Back when I was at IBM, the team members had specific areas. For example my areas were the base OS/2 system, Personal Communications, antivirus and some utilities. Others did Lotus Notes, Smart Suite etc. With 12.1, my testing was just general use on a notebook computer, so stuff like WiFi was checked, but not fetchmail. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Per Jessen wrote:
Why no more volunteers to do testing? Well, it is difficult, you need expertise, you need space in the disk, or an extra computer, etc. I don't believe "more testers" => "more areas tested" - at best, it might mean "same areas tested more".
I guess it depends on areas of interest. Back when I was at IBM, the team members had specific areas. For example my areas were the base OS/2 system, Personal Communications, antivirus and some utilities. Others did Lotus Notes, Smart Suite etc. With 12.1, my testing was just general use on a notebook computer, so stuff like WiFi was checked, but not fetchmail.
Hypothetically, if you had seen that 12.1 was being delayed due to insufficient testing of fetchmail (without defining what "insufficient" means in this context), might you have been inclined to run some of defined fetchmail tests? (defined = previously documented tests). -- Per Jessen, Zürich (6.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Hypothetically, if you had seen that 12.1 was being delayed due to insufficient testing of fetchmail (without defining what "insufficient" means in this context), might you have been inclined to run some of defined fetchmail tests? (defined = previously documented tests).
In the case of systemd replacing system v, there's a list of services started. Perhaps someone who was responsible for systemd should have done some testing to make sure everything that worked with system v also worked with systemd. The first I was aware of systemd is when postfix didn't start. That's a fairly basic package that's required on many systems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/12/11 15:58, James Knott wrote:
The first I was aware of systemd is when postfix didn't start. That's a fairly basic package that's required on many systems.
A postfix update was released today and that should solve the problem some people are having. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 16/12/11 15:58, James Knott wrote:
The first I was aware of systemd is when postfix didn't start. That's a fairly basic package that's required on many systems.
A postfix update was released today and that should solve the problem some people are having.
When I was at IBM, this sort of thing would have been part of integration testing. As I mentioned earlier, when you make a significant change, you'd better test it fully. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/12/11 16:09, James Knott wrote:
When I was at IBM, this sort of thing would have been part of integration testing. As I mentioned earlier, when you make a significant change, you'd better test it fully.
That's a nice thing you can step up to do by yourself. see http://news.opensuse.org/2011/10/11/opensuse-announces-first-public-release-... We can't test everything, and even less all sorts of scenarios that having two init systems bring up. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 11:15 AM, Cristian Rodríguez wrote:
On 16/12/11 16:09, James Knott wrote:
When I was at IBM, this sort of thing would have been part of integration testing. As I mentioned earlier, when you make a significant change, you'd better test it fully.
That's a nice thing you can step up to do by yourself. see
http://news.opensuse.org/2011/10/11/opensuse-announces-first-public-release-...
We can't test everything, and even less all sorts of scenarios that having two init systems bring up.
Not testing everything is not the same as not testing the basics. Postfix is hardly a corner case. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 08:44 PM, John Andersen wrote:
On 12/16/2011 11:15 AM, Cristian Rodríguez wrote:
On 16/12/11 16:09, James Knott wrote:
When I was at IBM, this sort of thing would have been part of integration testing. As I mentioned earlier, when you make a significant change, you'd better test it fully.
That's a nice thing you can step up to do by yourself. see
http://news.opensuse.org/2011/10/11/opensuse-announces-first-public-release-...
We can't test everything, and even less all sorts of scenarios that having two init systems bring up.
Not testing everything is not the same as not testing the basics. Postfix is hardly a corner case.
Postfix is installed on nearly every system. The question should better be: Why was it not reported earlier? It should have been noticed earlier and somebody - including myself - should have noticed earlier. I just wonder, why nobody did - or was the bug filed in time and not taken care off? On the other hand a detailed test plan with test cases would be great to have - I'm sure the opensuse-testing team would welcome any actual help to make 12.2 better. The testcases which were run, e.g. the openqa tests, showed success once 12.1 was declared golden. so, it's not that we don't have tests - we don't have enough and then you need ways (automatic testing or volunteers) to run and report them, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/12/11 17:30, Andreas Jaeger wrote:
Postfix is installed on nearly every system. The question should better be: Why was it not reported earlier? It should have been noticed earlier and somebody - including myself - should have noticed earlier. I just wonder, why nobody did - or was the bug filed in time and not taken care off?
It is my belief that the problem is upgrade related only, and one more reason to get rid of sysvinit ASAP. let's see if we can come up with a plan to do so in the next release. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 16/12/11 17:30, Andreas Jaeger wrote:
Postfix is installed on nearly every system. The question should better be: Why was it not reported earlier? It should have been noticed earlier and somebody - including myself - should have noticed earlier. I just wonder, why nobody did - or was the bug filed in time and not taken care off?
It is my belief that the problem is upgrade related only, and one more reason to get rid of sysvinit ASAP. let's see if we can come up with a plan to do so in the next release.
I have never upgraded a system. Always a fresh install. I had that postfix problem on systems running systemd, but not system v. BTW, I have just converted one computer back to system v, as I want a reliable system that just works. Systemd is clearly not ready for prime time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/12/11 18:16, James Knott wrote:
Systemd is clearly not ready for prime time.
The bug was not in systemd but in the postfix package, which update has been released today, blaming the wrong component here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 1:48 PM, Cristian Rodríguez wrote:
On 16/12/11 18:16, James Knott wrote:
Systemd is clearly not ready for prime time.
The bug was not in systemd but in the postfix package, which update has been released today, blaming the wrong component here.
You keep posting that, and people keep pointing out it worked under sysv. Net effect is that the failure was induced by or only appeared under systemd. You are making a distinction without a difference. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez wrote:
On 16/12/11 18:16, James Knott wrote:
Systemd is clearly not ready for prime time.
The bug was not in systemd but in the postfix package, which update has been released today, blaming the wrong component here.
I have had 3 separate problems with systemd. Only postfix has been resolved. The others are fetchmail flat out does not work with systemd. The other, networking usually does not start. It sometimes takes 3 or 4 reboots to get networking going. This problem occurs on 2 different computers. We also lose a useful feature with after.local. Whether the faults are within systemd or some other package, they all appeared with systemd and disappear when I boot system v. Either way, things broke with the introduction of systemd. -- 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 Friday, 2011-12-16 at 18:48 -0300, Cristian Rodríguez wrote:
On 16/12/11 18:16, James Knott wrote:
Systemd is clearly not ready for prime time.
The bug was not in systemd but in the postfix package, which update has been released today, blaming the wrong component here.
Postfix has worked for years, and only fails when a new ingredient is added to the recipe: systemd. Ergo, the culprit is systemd, even if the solution involves changing another component. Even more when several independent components fail, and the common ingredient in all cases is systemd. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7r0yoACgkQtTMYHG2NR9UtPgCePuA9JU+nMlllA5uFrc7JESo1 2CkAn2RARkoJAlD/yC0oaUMWN1fGl7Wn =TTFG -----END PGP SIGNATURE-----
On 16/12/11 20:24, Carlos E. R. wrote:
Postfix has worked for years, and only fails when a new ingredient is added to the recipe: systemd.
Except that it has nothing to do with it, systemd or postfix are not at fault of *packaging* bugs. as X is not in fault of bugs in KDE. Ergo, the culprit is systemd, even if the
solution involves changing another component.
Even more when several independent components fail, and the common ingredient in all cases is systemd.
Effectively you are shooting the messenger, and yes there are other problems, systemd is too fast and old code has race conditions or other bugs that systemd makes appear to the surface, and that is a good thing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Cristian Rodríguez said the following on 12/16/2011 06:38 PM:
Effectively you are shooting the messenger, and yes there are other problems, systemd is too fast and old code has race conditions or other bugs that systemd makes appear to the surface, and that is a good thing.
Ah, and what else would Postfix be dependinet on that isn't clearly stated? Its "required" by multi-user and needs networking, but what else? Does networking guarantee DNS? I know on one of my machines I have a adblock file from Peter Lowe (pgl@yoyo.org) at http://pgl.yoyo.org/ and that can take maybe 15 seconds to process and initialize the 3000+ zone entries. So networking being up doesn't guarantee DNS being up. And then there's syslog; postfix needs syslog too. What else? -- Most people are not really free. They are confined by the niche in the world that they carve out for themselves. They limit themselves to fewer possibilities by the narrowness of their vision. --V. S. Naipaul -- 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 12/16/2011 06:24 PM:
On Friday, 2011-12-16 at 18:48 -0300, Cristian Rodríguez wrote:
On 16/12/11 18:16, James Knott wrote:
Systemd is clearly not ready for prime time.
The bug was not in systemd but in the postfix package, which update has been released today, blaming the wrong component here.
Postfix has worked for years, and only fails when a new ingredient is added to the recipe: systemd. Ergo, the culprit is systemd, even if the solution involves changing another component.
Even more when several independent components fail, and the common ingredient in all cases is systemd.
Yes/no/maybe. I recall reading somewhere that the interface between SystemD and the old Nit scripts was limited. Some of those script had more that stop, start, status, and that tended to mess things up. I'll see if I can find the page in my browser history; it was something about writing or converting scripts to use with SystemD ... Well there's http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities which says
Additional verbs for init scripts are not supported. If your init script traditionally supported additional verbs for your init script simply move them to an auxiliary script. Additional parameters to the standard verbs (i.e. to "start", "stop" and "status") are not supported. This was an extension of SysV that never was standardized officially, and is not supported in systemd.
but that wasn't what I recall ... maybe something more. I recall reading that systemd takes some of the stuff that's in the script headers very literally even if its wrong. The stuff like
# Provides: postfix # Required-Start: $network # Required-Stop: $network # Should-Start: $named mysqld postgresql ldap saslauthd # Should-Stop: $named mysqld postgresql ldap saslauthd
Personally I think all that sysinit compatibility is a kludge and you should write a proper Unit file (target & service) for Postfix. Something simple like http://en.gentoo-wiki.com/wiki/Systemd#Postfix -- This is a general discussion intended for use only by qualified professionals. It should not be taken or used as a recommendation for any specific business, application, or environment. Said recommendations can be made only in a specific context and will be made only for a professional fee. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, December 16, 2011 07:02:54 PM Anton Aylward wrote:
Personally I think all that sysinit compatibility is a kludge and you should write a proper Unit file (target & service) for Postfix. Something simple like http://en.gentoo-wiki.com/wiki/Systemd#Postfix
Missing support for extension of, extension of sysinitv, may or may not be bad, but in any case our wiki is not rich in content that deals with our new toy, systemd. What we are missing is acticles like the one you pointed out, that will help do-it-yourself type of users to fix own problems and help others. I really like a Gentoo wiki and their style as educational tool that helped me not once to fix unfixable :) -- Regards, Rajko -- 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 Friday, 2011-12-16 at 17:34 -0300, Cristian Rodríguez wrote:
It is my belief that the problem is upgrade related only, and one more reason to get rid of sysvinit ASAP. let's see if we can come up with a plan to do so in the next release.
It is not upgrade related. I have 12.1 installed fresh with defaults in vmware player, and postfix does not start on boot. And thanks to systemV still been available it is not a disaster for many people, that would have to downgrade. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7rzQoACgkQtTMYHG2NR9VMfwCeMwM6MqExDvAPxi+A0hMNpCXL 3ZwAn03UZkjV5HPJwv1hZIBIzJmFC/4V =1xAC -----END PGP SIGNATURE-----
Cristian Rodríguez wrote:
On 16/12/11 17:30, Andreas Jaeger wrote:
Postfix is installed on nearly every system. The question should better be: Why was it not reported earlier? It should have been noticed earlier and somebody - including myself - should have noticed earlier. I just wonder, why nobody did - or was the bug filed in time and not taken care off?
It is my belief that the problem is upgrade related only,
You're wrong, it is not. In a vanilla 12.1 install, postfix does not start without manual intervention. May have been fixed through updates now, I don't know. -- Per Jessen, Zürich (3.2°C) -- 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 Saturday, 2011-12-17 at 20:06 +0100, Per Jessen wrote:
You're wrong, it is not. In a vanilla 12.1 install, postfix does not start without manual intervention. May have been fixed through updates now, I don't know.
No, the last update did not solve it. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7ueRsACgkQtTMYHG2NR9X8QgCfemcHpXd/8pWRmc4VpPFoNmE9 O40An0odUQgP6sqfXwdel9xSijUy2eiM =MF5K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 12:30 PM, Andreas Jaeger wrote:
On the other hand a detailed test plan with test cases would be great to have - I'm sure the opensuse-testing team would welcome any actual help to make 12.2 better. The testcases which were run, e.g. the openqa tests, showed success once 12.1 was declared golden. so, it's not that we don't have tests - we don't have enough and then you need ways (automatic testing or volunteers) to run and report them,
This sounds like an interesting opportunity for some better method of community involvement. Each of us has our areas of interest, and expertise, (well, in my case perhaps just interest). The concept of testing an entire distro is rather daunting. To the point where, depending on the press of business, simply finding the time to wade thru a beta or an RC and reporting every bug one encounters is a huge task. Further, there is a tendency to get hung up on the first bug you find, and never get beyond that, in spite of the fact that 3000 other testers found the same bug. If folks could signup/check-in on some webpage to test those packages they use so that there is a clear list and perhaps a participation log or indicator of the number of eyeballs on a given package or area we could avoid the situation where everybody tests the same stuff, and other things get totally overlooked. If I know a ton of people are looking at the KNetworkManager, I don't have to spend time there, and can test those other packages that I use and rely on, and largely ignore flaws I find in KNM. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andreas Jaeger wrote:
On 12/16/2011 08:44 PM, John Andersen wrote:
On 12/16/2011 11:15 AM, Cristian Rodríguez wrote:
On 16/12/11 16:09, James Knott wrote:
When I was at IBM, this sort of thing would have been part of integration testing. As I mentioned earlier, when you make a significant change, you'd better test it fully.
That's a nice thing you can step up to do by yourself. see
http://news.opensuse.org/2011/10/11/opensuse-announces-first-public-release-...
We can't test everything, and even less all sorts of scenarios that having two init systems bring up.
Not testing everything is not the same as not testing the basics. Postfix is hardly a corner case.
Postfix is installed on nearly every system. The question should better be: Why was it not reported earlier?
Andreas, the obvious answer to your question is - because of insufficient and arbitrary testing. By everyone involved, including myself. My personal "excuse" is that I consider a running postfix such a basic element that I just can't imagine needing to test it. Mea culpa.
On the other hand a detailed test plan with test cases would be great to have - I'm sure the opensuse-testing team would welcome any actual help to make 12.2 better.
A fully fledged test plan is a lot of work, not including writing the test cases - to get commitment from a) people to write and maintain a plan and b) people to write and maintain test-cases, I submit we would have to create a hard link between the release and the status of testing. If a release goes ahead despite test-status being "negative", I think anyone testing or maintaining the test plan will feel ignored and be unlikely to participate again. -- Per Jessen, Zürich (3.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 12:12 PM, Per Jessen wrote:
James Knott wrote:
Per Jessen wrote:
Why no more volunteers to do testing? Well, it is difficult, you need expertise, you need space in the disk, or an extra computer, etc. I don't believe "more testers" => "more areas tested" - at best, it might mean "same areas tested more".
I guess it depends on areas of interest. Back when I was at IBM, the team members had specific areas. For example my areas were the base OS/2 system, Personal Communications, antivirus and some utilities. Others did Lotus Notes, Smart Suite etc. With 12.1, my testing was just general use on a notebook computer, so stuff like WiFi was checked, but not fetchmail.
Hypothetically, if you had seen that 12.1 was being delayed due to insufficient testing of fetchmail (without defining what "insufficient" means in this context), might you have been inclined to run some of defined fetchmail tests? (defined = previously documented tests).
Maybe the status of pending releases and the current todo list can be made more visible? Something right on the main home page and on every download page? Like the countdown thingie but more informative than a simple date, and more prominent or somehow enticing. A phrase that applies here is "Make it easy for them to get it right." If you want more people to put in effort testing things, you have to smooth the way to get to the actual testing and reporting as much as possible, starting with making it harder to ignore or avoid that testing is even needed and that the product will suffer unless "you" help, and make sure even the casual glancer can tell that there are things even lowly they can help with. Also a roster of involved people with stats, number of involved projects or bugs etc, where people can see their name up in lights. Some kind of simple single graphic that expresses the overall state, like how much % green vs yellow & red, or how high the thermometer like fund raisers always use. In this case I think something that grows toward 100% complete is less compelling than something that gets smaller to show the remaining problems going away. That should better inspire people to decide to bother to help get rid of that last little thing if that's all that's left. Then when you click on it you get a more expanded view of the current state, but still not the overwhelming full everything details, still somewhat of a summary of categories of problems. Maybe tag different problems or todo items by estimated difficulty or required skill level too. So someone could discover easily that some apps just need a man page written up, or others that need actual testing, but could be tested purely in a vm using a suse studio iso and virtualbox on any pc even windows with not all that many clicks. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/16/2011 12:57 PM, Brian K. White wrote:
Maybe the status of pending releases and the current todo list can be made more visible? Something right on the main home page and on every download page? Like the countdown thingie but more informative than a simple date, and more prominent or somehow enticing.
Exactly. More ambitious than what I posted up-thread, but right on the mark. People could port their use of some package an report with simple check boxes that it worked, failed, need fixes, etc. As it is, we have only bug reports. No bug reports suggests it is working perfectly. The fallacy is that maybe it just hasn't been looked at by very many people. A "Works for Me" button could be as useful as a bug report in some cases. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Brian K. White wrote:
On 12/16/2011 12:12 PM, Per Jessen wrote:
Hypothetically, if you had seen that 12.1 was being delayed due to insufficient testing of fetchmail (without defining what "insufficient" means in this context), might you have been inclined to run some of defined fetchmail tests? (defined = previously documented tests).
Maybe the status of pending releases and the current todo list can be made more visible? Something right on the main home page and on every download page? Like the countdown thingie but more informative than a simple date, and more prominent or somehow enticing.
I think that would a be great step forward, but to start with, we need a way of measuring <something> to have <something> to display.
A phrase that applies here is "Make it easy for them to get it right."
Right.
If you want more people to put in effort testing things, you have to smooth the way to get to the actual testing and reporting as much as possible, starting with making it harder to ignore or avoid that testing is even needed and that the product will suffer unless "you" help, and make sure even the casual glancer can tell that there are things even lowly they can help with. Also a roster of involved people with stats, number of involved projects or bugs etc, where people can see their name up in lights.
Thanks for reading between my lines, that is exactly what I was hinting at.
Some kind of simple single graphic that expresses the overall state, like how much % green vs yellow & red, or how high the thermometer like fund raisers always use. In this case I think something that grows toward 100% complete is less compelling than something that gets smaller to show the remaining problems going away. That should better inspire people to decide to bother to help get rid of that last little thing if that's all that's left. Then when you click on it you get a more expanded view of the current state, but still not the overwhelming full everything details, still somewhat of a summary of categories of problems. Maybe tag different problems or todo items by estimated difficulty or required skill level too.
Project members could even indicate their skills/experience/interest in their respective profiles, and have suggestions of work/testing to be done made based on those. -- Per Jessen, Zürich (3.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek wrote:
Am 15.12.2011 11:53, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd?
Shouldn't this also work with systemd?
Yes, it certainly should. It sounds like you've got some mix-up wrt NetworkManager, I can easily imagine that causing further network problems. Maybe that's where you need to focus for the moment.
Or will systemd never replace sysvinit for serious work?
I'm sure it will, but it's not quite ready yet. -- Per Jessen, Zürich (9.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Am 15.12.2011 11:53, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd?
Shouldn't this also work with systemd?
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
The earlier one gets rid of its bugs one the better.
Yup, if you want to help debugging then try to solve this particular problem. If you just need a working system then switch back to sysvinit. I've missed the point. Is your system a fresh installation or upgraded? In case of upgrade the switch to systemd is considered one of the most annoying bugs: http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1 cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 15.12.2011 12:15, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Am 15.12.2011 11:53, schrieb Ruediger Meier:
On Thursday 15 December 2011, Christoph Bartoschek wrote:
Something went wrong during installation or upgrade, I don't know.
I've disabled the NetworkManager.service but it still hangs during boot.
Have you tried using sysvinit instead of systemd?
Shouldn't this also work with systemd?
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
The earlier one gets rid of its bugs one the better.
Yup, if you want to help debugging then try to solve this particular problem. If you just need a working system then switch back to sysvinit.
I've missed the point. Is your system a fresh installation or upgraded? In case of upgrade the switch to systemd is considered one of the most annoying bugs: http://en.opensuse.org/openSUSE:Most_annoying_bugs_12.1
It is a new installation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 08:15, Ruediger Meier wrote:
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
Like what bugs and inconsistences that haven't been fixed for example ? (note that NFS, networkmanager etc have nothing to do with systemd, neither bugs in systemd units shipped with other packages ) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 08:15, Ruediger Meier wrote:
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
Like what bugs and inconsistences that haven't been fixed for example ?
I guess you know bugzilla's search button? There are even more bugs discussed on the lists only.
(note that NFS, networkmanager etc have nothing to do with systemd, neither bugs in systemd units shipped with other packages )
I don't care what package a bug belong's to. Moving to systemd includes shipping working packages and should be done without breaking running systems. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 16:31, Ruediger Meier wrote:
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 08:15, Ruediger Meier wrote:
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
Like what bugs and inconsistences that haven't been fixed for example ?
I guess you know bugzilla's search button? There are even more bugs discussed on the lists only.
Just did, even took a quick look, bugs that are critical in systemd itself have been fixed, the others are : - Cosmetic issues - Bugs in networking scripts/ifup - Bugs in KDE Which have absolutely _nothing_ to do with systemd itself, kinda like blaming KDE when it is the X server that fails. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 16:31, Ruediger Meier wrote:
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 08:15, Ruediger Meier wrote:
It should work but in practice there are so many bugs and inconsistencies that I wouldn't use it.
Like what bugs and inconsistences that haven't been fixed for example ?
I guess you know bugzilla's search button? There are even more bugs discussed on the lists only.
Just did, even took a quick look, bugs that are critical in systemd itself have been fixed, the others are :
- Cosmetic issues - Bugs in networking scripts/ifup - Bugs in KDE
You may think that things like "systemd does not start postfix" or "domainname not set - NIS failing with systemd" or "shuts down network for no reason" are just cosmetic. For me they are reason enough to not use it. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/12/11 19:32, Rüdiger Meier wrote:
You may think that things like "systemd does not start postfix"
which is again, not a bug in systemd, but in postfix package and has been fixed
or "domainname not set - NIS failing with systemd"
That one was also fixed already.
or "shuts down network for no reason" are just cosmetic.
which was already fixed , bug in the "sysconfig" package. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 15 December 2011, Cristian Rodríguez wrote:
On 15/12/11 19:32, Rüdiger Meier wrote:
You may think that things like "systemd does not start postfix"
which is again, not a bug in systemd, but in postfix package and has been fixed
or "domainname not set - NIS failing with systemd"
That one was also fixed already.
or "shuts down network for no reason" are just cosmetic.
which was already fixed , bug in the "sysconfig" package.
Again, I don't care whether these bugs belong to the systemd package itself or not. They were introduced because of switching to systemd. If I would have upgraded ANY of my systems to 12.1 when it came out then almost NONE of these systems were usable after first reboot. BTW one of the "most annoying" bugs that zypper dup switches to systemd is still not fixed. cu, Rudi -- 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 Friday, 2011-12-16 at 00:16 +0100, Rüdiger Meier wrote:
On Thursday 15 December 2011, Cristian Rodríguez wrote:
which was already fixed , bug in the "sysconfig" package.
Again, I don't care whether these bugs belong to the systemd package itself or not. They were introduced because of switching to systemd.
You are right. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qhVMACgkQtTMYHG2NR9U/SgCgkpkYmT7BEAUbjcG8LE5gcTsw ezAAn1toLsCh4Y9TsK1dULTsAO7ZqIfv =XqBk -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2011-12-15 at 19:49 -0300, Cristian Rodríguez wrote:
You may think that things like "systemd does not start postfix"
which is again, not a bug in systemd, but in postfix package and has been fixed
It has? My test system is experiencing that problem. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk7qhRwACgkQtTMYHG2NR9VasgCfXFB+NbVwMGiSJxl1qIYZzKB7 7KkAn3LTduj98fbWkVu15hu5W0GU6udQ =Y18u -----END PGP SIGNATURE-----
On 15/12/11 20:39, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2011-12-15 at 19:49 -0300, Cristian Rodríguez wrote:
You may think that things like "systemd does not start postfix"
which is again, not a bug in systemd, but in postfix package and has been fixed
It has? My test system is experiencing that problem.
Yes, but may not have been released yet. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/15/2011 05:58 AM:
Shouldn't this also work with systemd? The earlier one gets rid of its bugs one the better.
I've mentioned here before that I put Fedora-15 on a crappy old machine one of my neighbours threw out with a crapped out old drive etc etc etc. Well SystemD and the mount I described works on that. Works for boot. Yes it was 'new install'. I'd be happy to go off list with Christoph and do a gap analysis. -- The great successful men of the world have used their imagination ... think ahead and create their mental picture in all it details, filling in here, adding a little there, altering this a bit and that a bit, but steadily building - steadily building. -- Robert Collier -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dear Anton, Greeting from my side I would like to be in touch with your company to learn about open source, possible to help me now. Best wishes Nematullah Atef | Information System & Technology Manager | Afghanaid | Cell +93 (0) 787575159 - 0797299803 | E-mail natef@afghanaid.org.uk | Skype nematullah.atef | Website www.afghanaid.org.uk Head Office House 94, Hesa-e-Do, Main Road, Karta-e-Parwan, Kabul, Afghanistan | Registered Office Development House 56-64, Leonard Street, EC2A 4LT, London, United Kingdom Think and Act Green - don't print this e-mail unless you really need it "The middle path is the way to wisdom", Mawlana Jalal-ad-Din Muhammad Rumi, (a 13th-century Persian poet, Islamic jurist and theologian from Balkh, Afghanistan) Email disclaimer: Afghanaid is a company limited by guarantee and registered in England. Company registration No. is 3034888. Charity registration No. 105348. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This information may also be legally privileged. If you have received this message in error, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this message. If you have received this message in error, please delete it immediately and advise us by return e-mail to the above address. -----Original Message----- From: Anton Aylward [mailto:opensuse@antonaylward.com] Sent: Thursday, December 15, 2011 5:04 PM To: opensuse@opensuse.org Subject: Re: [opensuse] Systemd and fstab Christoph Bartoschek said the following on 12/15/2011 05:58 AM:
Shouldn't this also work with systemd? The earlier one gets rid of its bugs one the better.
I've mentioned here before that I put Fedora-15 on a crappy old machine one of my neighbours threw out with a crapped out old drive etc etc etc. Well SystemD and the mount I described works on that. Works for boot. Yes it was 'new install'. I'd be happy to go off list with Christoph and do a gap analysis. -- The great successful men of the world have used their imagination ... think ahead and create their mental picture in all it details, filling in here, adding a little there, altering this a bit and that a bit, but steadily building - steadily building. -- Robert Collier -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Christoph Bartoschek said the following on 12/15/2011 05:40 AM:
I've disabled the NetworkManager.service but it still hangs during boot.
I don't see what that is supposed to acheive? -- Don't think you are going to conceal thoughts by concealing evidence that they ever existed. Dwight D. Eisenhower, speech at Dartmouth College, June 14, 1953 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (16)
-
Andreas Jaeger -
Anton Aylward -
Brian K. White -
Carlos E. R. -
Carlos E. R. -
Christoph Bartoschek -
Cristian Rodríguez -
James Knott -
John Andersen -
Lars Müller -
Nematullah Atef -
Per Jessen -
Rajko M. -
Roger Oberholtzer -
Ruediger Meier -
Rüdiger Meier