October 2014 - openSUSE Users - openSUSE Mailing Lists

[opensuse] Toshiba ACPI
by Paul Groves 05 Oct '14

05 Oct '14

Hi, I have a Toshiba Satellite L300-29x which I have just upgraded to opensuse 13.1 from Windows 7. I am experiencing a few issues which as far as I can tell may possibly be ACPI related but I am no expert. The first issue is with the Fn + F1 etc hotkeys and the lid close action. They do not work most of the time. The buttons are not even detected by opensuse. Although 1 in 10 boots (roughly) they decide to work perfectly fine (including the lid close). My brightness settings etc work fine by changing them manually in the OS so this is just the keyboard hotkeys and lid close button. These have always worked fine in Windows. The second issue is that unless the buttons are working the fan can sometimes be really loud. When the buttons and lid are working then the fan is fine and runs just as it always has done in windows. Apart from these issues opensuse 13.1 runs perfectly on this laptop. Can anyone help me with these issues? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 3

[opensuse] XFS filesystem total failure on return from hibernation.
by Carlos E. R. 05 Oct '14

05 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Since yesterday (after an update), I have experimented twice the same problem, on return from hibernation. XFS fails completely, lots of kernel messages. System has to be restarted, recovery is impossible otherwise. It seems to affect one partition only (?), the one that has my home, on xfs. I booted the 13.1 XFCE rescue image, tried to xfs-repair that one. It complained that there was a log, that I should attempt to mount it first. Mount hung. It is unkillable. Reboot of system hung. smartctl -a gives no hint of problem. The hard disk is new (190 hours). I run "xfs_repair -L" on that disk, which succeeds with no error report. I'm at the moment running the long SMART test on that disk. It will take 226 minutes. This is the first report of error in the log: I will put a more complete version of the log in another post. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMk14AACgkQja8UbcUWM1wgoQD/Ssm98MXd5XSXqi6AkdjhgHmR z+PSYYCkgbupkpnLJAgA/0WO9+HQ9Wgn7XzkVLQkv3RreJT/nZQfJRLx39TqWMar =cU8T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

5 13

[opensuse] Loosing tabs in firefox
by Anton Aylward 05 Oct '14

05 Oct '14

I'm running FF 32.0.2 on suse 13.1 under KDE. All up to date. Previously I've made great use of tab groups so that I can categorise and keep to work/subject areas and not drown in tabs. But this last update seems to have screwed all that. First, I found that while the tab groups existed they were all empty and all the tabs had been moved to the 'main' group. So I moved them back. But after restarts I've found that they first moved back to 'main' and are now disappearing. Starting this morning I find that not only all those tabs in tab groups aren't there in the tab groups any more but the groups don't exist any more. Yes I use the Tab Group Helper and Tab Mix Plus. I've been using the latter for years and the former since it came out, no problems until this last upgrade. Is this a 'roll back' problem or what? I see this https://support.mozilla.org/en-US/questions/1003915 and yes I've tried fiddling with sessionstore.* but it doesn't help, it keeps happening. More to the point, it wasn't doing this on Wednesday! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

6 12

Re: [opensuse] Loosing tabs in firefox
by John Perry 04 Oct '14

04 Oct '14

On 10/4/2014 16:33, Bob Williams wrote: > To make a vowel short, you follow it with a double consonant, eg > flossing, popping, hopping, loss. > > So super = to an extreme degree > supper = an evening meal. > > It's more difficult with lose and loose, as both have a long sounding > 'o'. Different roots. Wow! another old-timer who was taught English before the fools at UC Berkeley decreed that spelling and grammar were no longer relevant to the English language :-). Now I'll shut up, too. john perry (yes, I know...) -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] rsync for incremental/synchronization ... 2-way, three-way?
by Anton Aylward 04 Oct '14

04 Oct '14

Can I do a simple 2-way sync? I have PDFs and ebooks on various devices, tablets, phones and desktop. All 3 need to be kept in sync. And perhaps with a master copy backed up to the cloud? Has anyone done this? I've tried googling but while there's a lot of interesting stuff and I do know about 'diff' and kdiff3, but over the network? -- Most of what we call management consists of making it difficult for people to get their jobs done - Peter Drucker -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 4

[opensuse] a broad appeal to fix opensuse's package-management's repository/redirector failure & recovery mechasnism
by grantksupport＠operamail.com 04 Oct '14

04 Oct '14

In my experience, package management's routine failure to find/use a 'healthy' repository is a long-standing production problem. I'm requesting a fix. Here's a summary: I run Opensuse 13.1 on numerous machines lsb_release -rd Description: openSUSE 13.1 (Bottle) (x86_64) Release: 13.1 Current count is ~200. The machines are installed at multiple locations around the globe. They're connected to the 'net via a variety of different networks providers. Some of the machines are directly connected to the 'net, some are behind LAN routers, switches & firewalls. Package management for all of the machines is handled exclusively via zypper cli. Each machine has a common core of repositories defined in /etc/zypp/repos.d, and frequently has a number of additional @openSUSE dev (!'home') repos defined. In ALL cases, the default install of repos sets have been installed with the meta-director as baseurl, baseurl=http://download.opensuse.org/... Regular package maintenance consists of zypper clean --all zypper (d)up The maintenance frequency is nominally 1/wk, often 1/dy, and in devs' cases, often more frequent. In virtually ALL cases, the update process regularly fails @ retrieving/refreshing the repos' (meta)data. For example, a typical result is: ... Checking whether to refresh metadata for KDE4-Extra-Unstable Retrieving: repomd.xml .......................................................................................[error] File '/repodata/repomd.xml' not found on medium 'http://download.opensuse.org/repositories/KDE:/Unstable:/Extra/KDE_Current_…' Abort, retry, ignore? [a/r/i/? shows all options] (a): ... This occurs occassionally for any/all repos, whether the standard distribution repos (security, update, etc), core DM (e.g. KDE*) additional repos, or the more 'esoteric' !home OBS-hosted repos (e.g., security:netfilter). The failure rate for overall update/upgrade process attempts is, very roughly, ~15%. The error is NON-recoverable. 'Abort' & 'retry' *never* work. Chats @ IRC re: the issue typically result in the same '(non)responses' : "wait", "works for me", "prove it", etc. The ONLY solution(s) that work are: (1) wait some random amount of time -- typically hours, occassionally days -- until the system magically heals itself, (2) visit the download.opensuse.org link for the repo, click 'details' for a target page, identify a specific working/available repo for the package(s) of interest, and manually edit baseurl= for the problematic repo. Neither is tenable for a reliable operating environment. It is simply unmanageable in either a single, local or widely-distributed environment. (2) is further confounded by the fact that, at any given time, a previously-working, manually-selected repo may, itself, fail, requiring -- yet again -- another manual intervention. Within the scope of our environment, no other distro's package management system has anywhere near the failure rate demonstrated here. (We've ~600+ other machines running a mix of Centos, Fedora, Debian & Ubuntu). This has been occurring for literally years, across multiple openSUSE versions, and remains unaddressed. I know, without any doubt, that others experience similar/frequent failures -- it's been a frequent discussion with our partners, as well as in openSUSE* IRC channels. This needs a fix. As to what, specifically, that fix can/should be -- I'm unclear. If a solution already exists, I'm unaware. One idea -- a fallback mechanism *within* a repos' definition would be useful For example, allow in a given repo's def'n, having multiple, numbered baseurls baseurl1=http://direct/url/to/specific/site/1/... baseurl2=http://direct/url/to/specific/site/2/... baseurl3=http://download.opensuse.org/... ... baseurlN=http://direct/url/to/specific/site/3/... and add fuction to zypper so that for each repo, the baseurls would be tried in order for any given failure. By adding, e.g., a failcount2abort=X to either/both a given repo's defn, or /etc/zypp(er).conf, the overall process could be terminated if there were "X" # of subsequent fails, indicating a likely systemic problem requiring further intervention. I'd appreciate hearing from "those responsible for keeping the redirector & repos working" re: * acknowledgement, or refusal thereof, of the failure issue * clarification as to why it occurs in the first place * ideas/suggestions as to what can/should be done to fix it Thanks. Grant -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

6 12

[opensuse] test
by Hans Krueger 03 Oct '14

03 Oct '14

test -- Hans Krueger hanskrueger007(a)roadrunner.com registered Linux user 289023 -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0

[opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

As an experiment, I tried pinging 224.0.0.1, which is the all hosts multicast address, which all hosts are supposed to respond to. When I do that, I only get a response from my Yamaha A/V receiver. Other devices, including computers running Linux and Windows 7 do not respond. I get the same results if I ping the local network broadcast address, only the A/V receiver responds. Given that all devices are supposed to respond, does anyone know why Linux or other devices don't? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

4 7

Re: [opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

On 10/03/2014 11:24 AM, Hans Walter Finckh wrote: > they should respond the regular ping any ping You give with any > parameter coz ping is a TCP/IP based command. > if not, you can do it the other way or send a ping from a dhcp-server > if there is one Yes I know they should respond. My question is why only the one device responds to the mulitcast, local broadcast or broadcast addresses. In IPv4, 224.0.0.1 is an address all devices should respond to. Why are they not? -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

3 7

Re: [opensuse] Linux and multicast
by James Knott 03 Oct '14

03 Oct '14

On 10/03/2014 02:23 PM, Hans Walter Finckh wrote: > yes, broadcaste cause a lot of trafic overhead and so decrease the > overall bandwith, and the pace, we all are on the way:-D There is still a need to address various classes of devices. That's why IPv6 uses multicasts to groups such as all hosts, all routers etc., in addition to things like multimedia streams, which actually reduce bandwidth by not having to duplicate the stream to all listening devices. While multicasts are used on IPv4, they weren't used to their potential as multicasts were an afterthough, replacing the old class D address block. On the otherhand, multicasts are an integral part of IPv6 operation. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

1 0