January 2016 - openSUSE Users - openSUSE Mailing Lists

[opensuse] NetworkManager in multi-user target
by Patrick Shanahan 03 Jan '16

03 Jan '16

Just installed Tw on a new Toshiba Intel laptop. Having previous bad experiences with NetworkManager, I only have dealt with wicked on all my other wireless boxes. Found NetworkManager easy to set up and use in graphical.target but switching to multi-user.target, runlevel 3, I have no network connection and don't seem to be able to achieve it. Restarting NM and/or network does no good. What is the magic incantation? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 4

[opensuse] automatically identifying and handling apple iphones in firewall ?
by Per Jessen 03 Jan '16

03 Jan '16

We had a couple of friends over for New Years' and discovered that their fairly new or upgraded iphones and ipads somehow didn't work on the wifi. That is, ipv6 websites worked fine, but ipv4 did not. I've finally tracked it down to be due to iOS8 and newer not accepting icmp redirects. (the icmp redirect is caused by my transparent squid cache). Other systems with this fault are e.g. Windows8 and Nintendo, and generally I have just added a bypass rule in the firewall for those specific devices. However, we have too many people with iphones traipsing around, so it would be nice for the firewall to automagically identify iphones and add them to a separate chain for bypassing/dealing with this issue. Obviously those devices are on dhcp, I could possibly detect it there and amend the firewall, but it would be a bit kludgy. Basically, I need a rule such as the below added to the firewall whenever a new iphone device appears: iptables -A PREROUTING -t mangle -j ACCEPT -p tcp --dport http -s <ip> I guess looking at the mac address might work, but I have at least 6 different ones of those too: 44:00:10, 4c:7c:5f, d0:4f:7e, 64:b9:e8, 84:b1:53. (seems like there is at least 451 OUIs registered to "Apple, Inc". Any better ideas? -- Per Jessen, Zürich (5.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 2

[opensuse] VirtualBox on LEAP
by George Olson 03 Jan '16

03 Jan '16

Hi Everyone, I just installed VirtualBox (Oracle's version) on my new installation of Leap, got it up and running, and it runs fine. Pretty happy so far with what I have seen in Leap. One thing that I am curious about. When I used to do my updates for VirtualBox, after every time I would do the update, I would have to run the following command: /etc/init.d/vboxdrv setup When I did that, it would stop the kernel module (I think), remove the old VirtualBox from it, add in the new kernel module. The message would also usually say something about recompiling the kernel module. Well, I noticed this time after installing VirtualBox (and it runs fine), that the file /etc/init.d/vboxdrv does not exist. Also, when I installed virtualbox, the following messages came through: ---------- Creating group 'vboxusers'. VM users must be member of that group! No precompiled module for this kernel found -- trying to build one. Messages emitted during module compilation will be logged to /var/log/vbox-install.log. Stopping VirtualBox kernel modules..done Uninstalling old VirtualBox DKMS kernel modules..done Trying to register the VirtualBox kernel modules using DKMS..done Starting VirtualBox kernel modules..done ----------- So I am curious, has something been changed, like with dracut or something, so that running vboxdrv setup is no longer necessary, and doing what is necessary with the kernel happens automatically now? -- George Box #1: 13.2 | KDE 4.14 | AMD Phenom IIX4 | 64 | 16GB Box #2: 13.1 | KDE 4.12 | AMD Athlon X3 | 64 | 4GB Laptop #1: 13.1 | KDE 4.12 | Core i7-2620M | 64 | 8GB Laptop #2: 42.1 | KDE Plasma 5 | Core i7-4710HQ | 64 | 16GB -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

2 1

RE: RE: [opensuse] slow desktop action and hangs after upgrade to 42.1
by stakanov＠freenet.de 02 Jan '16

02 Jan '16

> -----Ursprüngliche Nachricht----- > Von: Xen > Gesendet: Sa. 02.01.2016 12:33 > An: suse , > Betreff: RE: [opensuse] slow desktop action and hangs after upgrade to 421 > > stakanov(a)freenet.de schreef op 02-01-2016 1:49: > >> Your system is running baloo file indexing on the whole disk. The >> delays will be in the same moment as heavy disk activity I suppose. >> Once the indexing process has finished, the system will turn to be >> normally responsive. >> Log in your user and just let it run. Go to bed and when you wake up it >> should be O.K. >> This has normally nothing to do with conflicts. >> Try "top" from the command line to see that balloo indexer is running >> requiring a lot of CPU load. > > > Just saying... if an indexing service can cause up to 8 second delays in > system responsiveness, something is really really wrong. > -- > To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse+owner(a)opensuse.org > No, I would say this is a typical case of tradeoff. The niceness of baloo was set to be not noticeable for strong machines. Once done indexing you also do not "feel it" on less strong machines. But as the userbase of Linux is very widespread with young and nearly prehistoric machines, what is O.K. for most may not be O.K. for all. So either you set the niceness of the process to a lower level manually or you just wait after the first run that the indexing has finished. I do not see any "problem" there. If ever there is a problem it is as it always was: the QA process runs on virtualized machines that do check for hardware consistency but I do not think that these machines do also reproduce the slowness of real hardware. So if an indexing service can cause 8 seconds delays after the very first install, maybe that is acceptable provided(!) that the niceness is correct once the indexing has been run once. YMMV --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 3

[opensuse] YaST do not change the right line
by jdd 02 Jan '16

02 Jan '16

https://bugzilla.opensuse.org/show_bug.cgi?id=960488 I wanted to add an option in the kernel grub command line with YaST. For the test, I add the option "dummy" I already had problems changing the default options on this way, but didn't found why. Previously I edited the /etc/default/grub file. I did what I do most of the time: add # in front of the old option line then add a new line below. Here what was the file before using yast: (...) GRUB_TIMEOUT=8 #GRUB_CMDLINE_LINUX_DEFAULT=nomodeset GRUB_CMDLINE_LINUX_DEFAULT=nomodeset # kernel command line options for failsafe mode GRUB_CMDLINE_LINUX_RECOVERY=single (...) and after: #GRUB_CMDLINE_LINUX_DEFAULT="nomodeset dummy" GRUB_CMDLINE_LINUX_DEFAULT=nomodeset Yast changed the wrong line... I verified just now that YaST *read* the right line (the line without #), so if one launch again YaST, editing boot menu, do not change anything and validate, the menu is changed back to the initial one funny :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] slow desktop action and hangs after upgrade to 42.1
by George Olson (SUSE list) 02 Jan '16

02 Jan '16

Hi everyone, I just finished the installation of 42.1 in my laptop (#2 below). I am now tweaking it to make it work. My installation was a clean install of 42.1 into a separate root partition from my root partition of 13.2. I installed by means of the install dvd which I downloaded. My home partition I am using is the same as the home partition I used for 13.2. First problem - the graphics driver - fixed (I think). It is an intel i915 card with a discrete nVidia GM107M graphics card. I installed bumblebee with the proprietary nvidia driver according to this: https://en.opensuse.org/SDB:NVIDIA_Bumblebee After that my system was able to boot into opensuse and kde. The hwinfo --gfxcard indicates that both the i915 driver and the nvidia driver are the ones installed. Second problem - KDE had a significant delay whenever I tried to do anything. When I clicked on any icon, I had to wait between 10 and 30 seconds for the application to give any indication that it is opening up. It didn't matter if it was kwrite, konsole, the kicker button, yast, or firefox or chrome. Also if I hit alt-tab to switch between applications, sometimes I would have to wait for that to switch also, and watch the desktop hang. I tried disabling desktop effects and switching the display backend driver to openGL something, and that seemed to help for about 1 minute, but then the delays and hangs would come back at random. I finally resorted to the following, and this is where my question is. Since I was using the same home partition as I was using for 13.2, I thought maybe there was some conflict between old KDE 4 files and whatever KDE 5 wanted to do. So I went into the /home/george directory and deleted all the hidden directories (that have a . in front). This included the .kde4 directory, .config, and .local. (I kept the ones I needed for applications like thunderbird). After I did that, I logged back into KDE, knowing it would re-create from scratch what it needed to run KDE 5, and voila, now the system works quite speedily, no more hangs. Pretty nice so far. Haven't really tested it extensively, but it seems much better. I am wondering if this is sort of standard practice when going to a new version of KDE? It seems that this should be written down somewhere. I saw several posts in the forums where others were struggling with similar problems of their system hanging, and there were suggestions of turning off desktop effects and disabling device acceleration, and other ideas. Thoughts? Would there have been a better way to make things work? -- George Box #1: 13.2 | KDE 4.14 | AMD Phenom IIX4 | 64 | 16GB Box #2: 13.1 | KDE 4.12 | AMD Athlon X3 | 64 | 4GB Laptop #1: 13.1 | KDE 4.12 | Core i7-2620M | 64 | 8GB Laptop #2: 42.1 | KDE Plasma 5 | Core i7-4710HQ | 64 | 16GB -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 8

[opensuse] RE: slow desktop action and hangs after upgrade to 42.1
by André Verwijs 02 Jan '16

02 Jan '16

I have the same with Leap, sometimes i have to fore re-login.... press ctrl+alt+F2 <login as root> #run as root init 3 <login as root> init 5 && exit -- ______________________________________________________________________________________ La Ventura (heavy metal band) Tumblr page: http://laventurafan.tumblr.com My Twitter Page: http://twitter.com/OpenSimFan My Facebook page (be my friend, please ) http://www.facebook.com/andre.verwijs My Google+ page (follow me please ) André Verwijs - Google+ https://plus.google.com/111310545842863442992 -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

RE: [opensuse] slow desktop action and hangs after upgrade to 42.1
by stakanov＠freenet.de 02 Jan '16

02 Jan '16

> -----Ursprüngliche Nachricht----- > Von: George Olson (SUSE list) > Gesendet: Sa. 02.01.2016 01:02 > An: suse , > Betreff: [opensuse] slow desktop action and hangs after upgrade to 42.1 > > Hi everyone, > > I just finished the installation of 42.1 in my laptop (#2 below). I am > now tweaking it to make it work. My installation was a clean install of > 42.1 into a separate root partition from my root partition of 13.2. I > installed by means of the install dvd which I downloaded. > > My home partition I am using is the same as the home partition I used > for 13.2. > > First problem - the graphics driver - fixed (I think). It is an intel > i915 card with a discrete nVidia GM107M graphics card. I installed > bumblebee with the proprietary nvidia driver according to this: >https://en.opensuse.org/SDB:NVIDIA_Bumblebee > > After that my system was able to boot into opensuse and kde. The hwinfo > --gfxcard indicates that both the i915 driver and the nvidia driver are > the ones installed. > > Second problem - KDE had a significant delay whenever I tried to do > anything. When I clicked on any icon, I had to wait between 10 and 30 > seconds for the application to give any indication that it is opening > up. It didn't matter if it was kwrite, konsole, the kicker button, yast, > or firefox or chrome. Also if I hit alt-tab to switch between > applications, sometimes I would have to wait for that to switch also, > and watch the desktop hang. > > I tried disabling desktop effects and switching the display backend > driver to openGL something, and that seemed to help for about 1 minute, > but then the delays and hangs would come back at random. > Your system is running baloo file indexing on the whole disk. The delays will be in the same moment as heavy disk activity I suppose. Once the indexing process has finished, the system will turn to be normally responsive. Log in your user and just let it run. Go to bed and when you wake up it should be O.K. This has normally nothing to do with conflicts. Try "top" from the command line to see that balloo indexer is running requiring a lot of CPU load. --- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 5