From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D9B76138CD8 for ; Wed, 27 May 2015 13:21:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02535E08DD; Wed, 27 May 2015 13:21:39 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 D84CFE08C2 for ; Wed, 27 May 2015 13:21:37 +0000 (UTC) Received: by iebgx4 with SMTP id gx4so13140183ieb.0 for ; Wed, 27 May 2015 06:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=O6N/UM8zZlb0+e/xqVKbyOr/zEDjTZcSrjbspWDwi0g=; b=vAnY2csz4de0K59nND1cVfw/ZG4kSOm0QnY1J0dxzAB//FUxjk7kGOJPX8gAGfU6zW 7CXU+Cpf7zmzH6x4XTk5kc1NYyiqk75g1zvsWoz1g+Ybs4Sgqtxu0PuCfGlKOIqHP+wI tFmvskx/xTUt1Gi6/sHd7etDxK7thwadlIddus4Q7k7QFqcDutrTE6nmm0v2qwB3qd/Z ha+9tLWco0RnR+5zbp/sDJxgPpLTJaEjNsmL8nom2NITtjWAYb9PL0ggw1whMQqRscEB EqJVEuAsahNoTYGTcZPsnDPCir4iXigBNAC1R4V5tRGIf6J1H25sb+gvk86uNFlTcXyc Dfig== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.107.128.30 with SMTP id b30mr41119887iod.84.1432732897301; Wed, 27 May 2015 06:21:37 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.107.6.34 with HTTP; Wed, 27 May 2015 06:21:37 -0700 (PDT) In-Reply-To: <2988031.1MpZN5Nf01@wstn> References: <2988031.1MpZN5Nf01@wstn> Date: Wed, 27 May 2015 09:21:37 -0400 X-Google-Sender-Auth: h08Zv9iU2ndbRN_Y0JWPPn8WOKs Message-ID: Subject: Re: [gentoo-user] General weirdness - a tale of woe. From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: ead62527-cee8-46cc-8454-db0493b1ef27 X-Archives-Hash: fb8bc65d38878ea6cd5355d5fecaaf8b On Wed, May 27, 2015 at 7:59 AM, Peter Humphrey wrote: > This is a KDE amd64 system with /usr under / and no initrd. 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. > ... bunch of KDE stuff 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. > 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. I've sometimes seen this sort of thing with kernel raid autodetection, especially with metadata <1. 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. I do recommend just using an initramfs if you're using RAID for early-boot filesystems. While it is an extra step I find it is much more robust than kernel autodetection (and if something goes wrong you usually get an emergency shell where you can just manually get the RAID up and type exit and watch the system boot). It also lets you use metadata >1 and I find that to be a lot more robust in general. With an initramfs you can basically boot anything you can mount from a booted system, but without one your options are more limited. -- Rich