From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-164535-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 46665138CD8
for <garchives@archives.gentoo.org>; Wed, 27 May 2015 20:40:58 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 4E27FE0881;
Wed, 27 May 2015 20:40:47 +0000 (UTC)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id E30D9E0863
for <gentoo-user@lists.gentoo.org>; Wed, 27 May 2015 20:40:45 +0000 (UTC)
Received: by wgv5 with SMTP id 5so19750401wgv.1
for <gentoo-user@lists.gentoo.org>; Wed, 27 May 2015 13:40:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=from:reply-to:to:subject:date:user-agent:references:in-reply-to
:mime-version:content-type:content-transfer-encoding:message-id;
bh=Lr3vXNHU6QqBjOj35cbmlVtCE/+EluU0ZK5BCU+VVWk=;
b=tgXZCNRHIr5hoviYfcrDyU+TFQOpNO3U/5+LelPiO68+o9NDhzha2dK51N3GkegTXW
vXoY1gZi0l88NeWcQSix8/LOOEl9fDIQGpggn7qN0Dg1Pw4M2qJsXjiCz5XsZyCkLSij
M/XbjwLORB5T8uPV7c+lY/yKNzB6eTgaEYTyQLV1UJ27U1vJONTv4jApiie1DgjGIYCT
8g5ms6BHXjkKDOv8z5Q6G/IHwyocVQNNX5nFmzQNNXAXhxiBLaWuDRxBuNMOQXhbwzS5
N+3pDk1fy4j46SyHT6Jx45GPDCzEusZv1EU05vAmvQ5EfYndLYogltUTRtfqz6GdG5zl
nMwQ==
X-Received: by 10.194.93.163 with SMTP id cv3mr21335074wjb.15.1432759244694;
Wed, 27 May 2015 13:40:44 -0700 (PDT)
Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230])
by mx.google.com with ESMTPSA id u6sm118237wja.40.2015.05.27.13.40.43
for <gentoo-user@lists.gentoo.org>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 27 May 2015 13:40:43 -0700 (PDT)
From: Mick <michaelkintzios@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] General weirdness - a tale of woe.
Date: Wed, 27 May 2015 21:40:37 +0100
User-Agent: KMail/1.13.7 (Linux/3.18.12-gentoo; KDE/4.14.3; x86_64; ; )
References: <2988031.1MpZN5Nf01@wstn> <CAGfcS_=OmzdVqLc6MYeK+XZ0D7jcwEma8j4qqweQAkgPd4RMvw@mail.gmail.com> <8190245.y8rOlDDBFo@wstn>
In-Reply-To: <8190245.y8rOlDDBFo@wstn>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary="nextPart2419747.MFp0xqVtKv";
protocol="application/pgp-signature";
micalg=pgp-sha256
Content-Transfer-Encoding: 7bit
Message-Id: <201505272140.38862.michaelkintzios@gmail.com>
X-Archives-Salt: 8246a07e-e931-4746-a889-f6d3be00cf77
X-Archives-Hash: 04998a437e64915d9f723be8aa2ab1a2
--nextPart2419747.MFp0xqVtKv
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
On Wednesday 27 May 2015 15:16:35 Peter Humphrey wrote:
> On Wednesday 27 May 2015 09:21:37 Rich Freeman wrote:
> > On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey <peter@prh.myzen.co.uk>
>=20
> wrote:
> > > This is a KDE amd64 system with /usr under / and no initrd.
> >=20
> > Just to clarify, is /usr on a separate filesystem, or the same as /?
> > I don't think that is your problem in any case, but it might be
> > relevant.
>=20
> I didn't realise I wasn't clear, sorry. It might have been better if I'd
> said usr/ is under /. Anyway, it's not a separate partition.
It was clear to me. It did a double take after Canek's email and still=20
arrived at the same conclusion, but I accept that others read it differentl=
y.
> > > ... bunch of KDE stuff
> >=20
> > I've had the odd KDE issue along the way, like having extra panels
> > spawning off-screen with notifications showing up in wierd places as a
> > result. That doesn't sound like your specific problem, but assuming a
> > KDE expert doesn't chime in here you might consider pursuing those
> > questions in a KDE forum/list, or maybe even in the Gentoo forums
> > where there is a section for desktop environments. Again, assuming
> > somebody doesn't recognize your problem here.
>=20
> Since writing, I've found that my fonts have all changed as well. It's
> almost as though something were cruising my home directories and flipping
> bits. And KMail insists on using American English in the composer, despite
> my telling it UK. That may not be new though.
>=20
> I'm signed up to the KDE-Linux list already but I see hardly any traffic,
> and I suspect dark things about what happens to posts of mine on it.
Disclaimer: I am not using the full KDE desktop, but use a few KDE apps wi=
th=20
an enlightenment desktop.
In the last week or two I noticed an oddity with kdeinit4, which I haven't =
yet=20
been able to explain. I share it here in case it is related to your proble=
m,=20
but even so my setup is different to yours and I have no explanation for it:
When away from base using insecure WiFi I run 'proxychains kdeinit4' to tun=
nel=20
back to a local machine at home and bounce off to the Internet from there.
Suddenly, my (old) Kmail-1.13.7 stopped using the tunnel. My (new)=20
Knode-4.4.11 is also not using the tunnel. They both just hang not=20
establishing a connection whatsoever. Konsole-2.14.2 is not using the tunn=
el=20
either.
Strangely, Konqueror-4.14.3 *is* using the tunnel as before. Launching=20
konsole directly with 'proxychains konsole' is using the tunnel. Kmail jus=
t=20
fails to get anywhere even when invoked directly with proxychains, rather t=
han=20
via kdeinit4.
Proxychains was updated a couple of weeks ago and this problem may be relat=
ed=20
to it (I've raised a bug just in case), or it may be that something changed=
in=20
KDE and this is the cause of both of our problems? =20
> > > The last thing is that at reboot the RAID-1 volume manager often fails
> > > to start. It says afterwards that it's running, but all the /dev/vg7/*
> > > are absent (that's where the logical volumes live). The file system
> > > root lives on /dev/md5 with metadata < 1.0, while /dev/vg7 has
> > > metadata >1.0. The fact that it happens often but not always suggests
> > > a timing problem to me.
> >=20
> > I've sometimes seen this sort of thing with kernel raid autodetection,
> > especially with metadata <1.
>=20
> More clarity needed on my part. The file-system root is /dev/md5 which has
> metadata < 1.0. It's found reliably by kernel autodetection. Subsidiary
> partitions are in /dev/md7 which has metadata > 1.0 and lvm2 volumes.
> Here's a bit of fstab:
>=20
> /dev/vg7/portage /usr/portage ext4 relatime,discard 1 3
> /dev/vg7/packages /usr/portage/packages ext4 relatime,discard 1 2
> /dev/vg7/distfiles /usr/portage/distfiles ext4 relatime,discard 1 2
> /dev/vg7/local /usr/local ext4 relatime,discard 1 2
>=20
> It's the detection of md7 that often fails; I've had no trouble with md5.
>=20
> Several other directories are in lvm2 volumes in /dev/vg7, but nothing
> that's part of system.
>=20
> > I suspect that an initramfs might help
> > you out, assuming the filesystems on that RAID are useful in early
> > boot. However, openrc and the raid init scripts should do a good job
> > of configuring your raid if your mdadm.conf and such is correct, so if
> > you don't need those filesystems until late in boot I don't think an
> > initramfs will make much of a difference, since it would likely use
> > the exact same userspace tools as openrc already does. Make sure your
> > mdadm.conf is set up to search all devices that could contain RAID
> > (drive device names can get re-ordered), and it doesn't hurt to put
> > ARRAY lines in mdadm.conf to give it hints.
>=20
> Like this?
> ARRAY /dev/md1 devices=3D/dev/sda1,/dev/sdb1
> ARRAY /dev/md5 devices=3D/dev/sda5,/dev/sdb5
> ARRAY /dev/md7 devices=3D/dev/sda7,/dev/sdb7
No, I have always used something like:
ARRAY /dev/md7 metadata=3D1.2 UUID=3Df9516418:7ef43875:4e922ca1:43796eb1 \=
=20
name=3Ddata_server:0
It may be that the /dev/sdaX takes longer to settle and this causes your=20
problem, but I can't tell for sure.
> I've just switched on a few more sensors in gkrellm, and I see Vcor2 at
> 3.00 and +3.3v at 3.34. Is it worth fiddling with those and related
> settings in the BIOS? I've always hesitated to do that, preferring to let
> it sort itself out.
If you haven't O/C'ed it, I'd leave it alone. However, if the voltage used=
to=20
be something different in the past and is now registering a lower value usi=
ng=20
the same version BIOS firmware, then you could have a failing PSU. We all=
=20
know that this will inevitably lead to behavioural problems (inc. waving yo=
ur=20
arms around and making noises ... :-))
=2D-=20
Regards,
Mick
--nextPart2419747.MFp0xqVtKv
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABCAAGBQJVZivGAAoJELAdA+zwE4YeB9oH/iZGbTnqKGNDec+bWtCWpCE/
RTr/uyrMOXRWIWZNRii4Zf7EeP00SqlNbb/tO/YSip07o9KUABJsFQYHUrifnCFh
cDkXbaeKzpoj7dYRnO47zgM+XXe7IuLzaazT++b+C813N9ZMwbRzUmKKtfT03EVC
Pga1xV/N4523Ek6DVx0RN+ZEzwVcjschYQzBZDM4f5fkKiRt8UAnijp+KiYsN8Ww
sfOJqrsyYpKvZsthOonxW7jT+TJ/TXIhT8Z3z660fiGM3zkDWkO7C4tbdhalmeiB
0V/BD2ETnlQwHb+sr+ZM0j8XLaTDUjKYe26JnmlJIF0Mn0imoi3AVZ7dwgH9Loo=
=N8hK
-----END PGP SIGNATURE-----
--nextPart2419747.MFp0xqVtKv--