Am Sonntag, 29. März 2015, 22:57:47 schrieb Emil Stephan:
Am Sonntag, 29. März 2015, 17:33:32 schrieb Cristian Rodríguez:
On Sun, Mar 29, 2015 at 5:27 PM, Emil Stephan <Emil.Stephan@t-online.de>
...
Hard to say. I got the update from 210 to 219 today at 13:27. I have used runlevel resp. target changes to install the nvidia drivers to create a mmio trace. And this i have done yesterday too, since i tried several versions of the nvidia drivers. And i think, i had these behaviour yesterday too, but this was not my first level concern in that case. I have just checked, whether i can go back to 210. I have it on the DVD from the eleventh of march. I'll give it a try, and report later. Regards Emil
... Hello, i've done the tests now. In preparation of the tests it turned aout, that there are two groups of packages have to be considered. Group1: systemd systemd-sysvinit Group2: libudev1 udev libgudev-1_0-0 These packages in both groups changed in version from 210 to 219, but can be up-(or down-)graded separately. So i considered three conditions 1: default target for systemd (multi-user and graphical) 2: systemd version (210 or 219) 3: udev version (210 or 219) and four actions 1: runlevel number as kernel parameter 2: changing target by 'init <runlevel number>' 3: changing target by 'systemctl isolate <target name>' 4: changing target by setting the default target and entering it by 'systemctl default' It turned out that the fourth action always worked. This was a mean to change into the target state, if it was necessary for the next test step. I will omit it from the table. Some words about the notation: (x) this is the actual runlevel, when giving the comand x->y x is the requested runlevel rsp. target y is the reached runlevel rsp. target Here the table using some shortcuts: condition action deftg sdvers udvers kparm init sysctl multi 210 210 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 210 219 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 219 210 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 219 219 3 -> 3 (5)3->3 (5)3->3 (3)5->5 (3)5->5 5 -> 5 (5)3->3 (5)3->3 (3)5->5 (3)5->5 graph 210 210 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 210 219 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 219 210 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 219 219 3 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 5 -> 5 (5)3->5 (5)3->5 (3)5->5 (3)5->5 The conclusion, i found, is: I couldn't go below the default target. If my default target was multi-user, i could change between multi-user and graphical. If my default target was graphical, i could only change between graphical and graphical. The behaviour does not depend on the two considered versions. I think, Jan Engelhardt already noticed this in another post to this thread. In some cases i had to use action #4 to reach the runlevel, that was a preliminary for the next test, and then had to change the default target back to meet condition #1. In some of these cases, i noticed delays of the reaction to the command entered. It turned out, that probably there was no reaction. After changing the default target, it took about 20 to 25 seconds that the system automatically entered the new default target. I checked this with just waiting with the command at the next test. Is this a wishful behaviour? By the way, this was a mount count burner, forcing a file system check during the tests. Regards, Emil -- Registered Linux User since 19940320 ---------------------------------------------------------- Emil Stephan, Albersloher Weg 571A, 48167 Münster, Germany Accelerate Windows: 9.80665 m/sec^2 would be adequate -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org