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 8880B1381F3 for ; Tue, 2 Jul 2013 02:45:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E820BE0A92; Tue, 2 Jul 2013 02:45:11 +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 BC2E7E0A6B for ; Tue, 2 Jul 2013 02:45:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B5CB233DBC6 for ; Tue, 2 Jul 2013 02:45:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5.5 tests=[AWL=-0.899, 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.008, 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 VzIyS0-bCKIP for ; Tue, 2 Jul 2013 02:45:04 +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 0889C33E182 for ; Tue, 2 Jul 2013 02:45:01 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UtqaQ-00031V-Uo for gentoo-user@gentoo.org; Tue, 02 Jul 2013 04:44:58 +0200 Received: from c-24-118-110-103.hsd1.mn.comcast.net ([24.118.110.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jul 2013 04:44:58 +0200 Received: from grant.b.edwards by c-24-118-110-103.hsd1.mn.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 02 Jul 2013 04:44:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: Can't find init due to inconsistent drive order Date: Tue, 2 Jul 2013 02:44:42 +0000 (UTC) Message-ID: References: <51D2094C.7010209@gmail.com> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-24-118-110-103.hsd1.mn.comcast.net User-Agent: slrn/0.9.9p1 (Linux) X-Archives-Salt: 527232a1-c8fa-4620-8afb-0e82d760aa26 X-Archives-Hash: 47a7e0de572f91ee791fa7ad3e74e7b5 On 2013-07-01, Alan McKinnon wrote: > On 01/07/2013 23:52, Grant Edwards 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 use partition labels in my fstab, so that's not a problem, but after >> all these years, the kernel still doesn't know how to grok parition >> labels. >> >> Are we really expected now to set up an initrd just so that the kernel >> can find the root partition?? > > Where have you been for the past 6 months? > > Did you miss the entire clusterfuck debate about latest udev tricks? No. > Those names depend only on the order in which devices are discovered, > and that process has always been indeterminate. Really? I've been running Linux on a lot of machines for 30 years -- often on machines with a half-dozen hard drives -- and I never saw drive order change from one reboot to the next until today. That's quite a lucky streak. > udev used to get in the middle and rename things in an arbitrary but > defined order, it no longer does this. How did udev get in the middle? It somehow ran before the kernel mounted root and started 'init'? > We discussed this whole subject *to death* over the last many months I remember that discussion, but I don't see how it's relelvent to events that occur before init starts. -- Grant