From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-148393-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 7DB301381F3
for <garchives@archives.gentoo.org>; Tue, 2 Jul 2013 14:23:49 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 71A7EE0A5B;
Tue, 2 Jul 2013 14:23:40 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 3A534E09CD
for <gentoo-user@lists.gentoo.org>; Tue, 2 Jul 2013 14:23:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 6B73A33E841
for <gentoo-user@lists.gentoo.org>; Tue, 2 Jul 2013 14:23:38 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Flag: NO
X-Spam-Score: -1.182
X-Spam-Level:
X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5.5
tests=[AWL=-2.373, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,
NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001,
RP_MATCHES_RCVD=-0.009, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=no
Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1])
by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 5--6YZVTtk_H for <gentoo-user@lists.gentoo.org>;
Tue, 2 Jul 2013 14:23:32 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPS id E10C733E838
for <gentoo-user@gentoo.org>; Tue, 2 Jul 2013 14:23:31 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-user@m.gmane.org>)
id 1Uu1UO-0003ZN-Si
for gentoo-user@gentoo.org; Tue, 02 Jul 2013 16:23:28 +0200
Received: from dsl.comtrol.com ([64.122.56.22])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-user@gentoo.org>; Tue, 02 Jul 2013 16:23:28 +0200
Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-user@gentoo.org>; Tue, 02 Jul 2013 16:23:28 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-user@lists.gentoo.org
From: Grant Edwards <grant.b.edwards@gmail.com>
Subject: [gentoo-user] Re: Can't find init due to inconsistent drive order
Date: Tue, 2 Jul 2013 14:23:11 +0000 (UTC)
Message-ID: <kqunoe$ubb$1@ger.gmane.org>
References: <kqstnb$n0l$1@ger.gmane.org>
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: dsl.comtrol.com
User-Agent: slrn/1.0.1 (Linux)
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
X-Archives-Salt: e4bbdc02-b042-489c-ab2e-bcd0f2a5af92
X-Archives-Hash: 55e02040329ea8f10fc98290c887cecb
On 2013-07-01, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> I've just recently run into a problem where sometimes when a machine
> boots, the kernel can't find init. This appears to be because my grub
> configuration line says "root=/dev/sda5" and _sometimes_ the drive
> that contains my root partition is sdb instead of sda. AFAICT, for the
> past 30 years the linux kernel was 100% consistent in the order that
> hard drives were labelled -- but recently that has seems to have
> changed.
I still haven't figured out why my drives suddenly started getting
discovered in varying orders. I think that the SATA drives are always
in the same order with respect to each other, but sometimes the
external firewire drive gets discovered before the SATA drives and
sometimes after the SATA drives.
It looks like my options are:
1) Keep hitting the reset button until it works.
2) Unplug or power down the firewire drive when booting.
3) Set up an initrd for the sole purpose of finding the actual root
parition via filesystem label. [I find this idea rather offensive.]
4) Build the firewire drive as a module instead of building it into
the kernel. That would delay the discovery of the firewire drive
until after root has been mounted.
5) For the drive with the root parition on it switch from a DOS
parition table to a GPT partition table and use the
root=PARTUUID=<whatever> kernel option.
6) Fix the kernel so it can find root by looking at filesystem
labels.
Number 6 (fixing the kernel) is The Right Thing To Do(tm), but it's a
bit out of scope for the momement. The "early code" in the kernel
obviously knows how to read partition tables and also knows about the
relevent file system, so I'm a bit baffled why it can't look at the
file system label.
Changing the firewire driver to be a module is probably the simplest
solution, but it's a kludgy work-around for what is, in my opinion, a
kernel bug: if you are going to require people to specify an absolute
disk drive index for the root partition, then you'd better index
drives in a consistent order from one boot to the next.
Switching to a GPT partition table sounds like the cleanest solution,
but I need to figure out if the grub (legacy) ebuild includes GPT
support or not. I know it's supported by grub2, but I don't really
feel like switching to grub2 ATM.
--
Grant Edwards grant.b.edwards Yow! But was he mature
at enough last night at the
gmail.com lesbian masquerade?