From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-commits+bounces-598119-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 3DBF51381F3
	for <garchives@archives.gentoo.org>; Sun,  9 Jun 2013 13:15:29 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 9F9F8E0825;
	Sun,  9 Jun 2013 13:15:27 +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 259E6E0825
	for <gentoo-commits@lists.gentoo.org>; Sun,  9 Jun 2013 13:15:27 +0000 (UTC)
Received: from hornbill.gentoo.org (hornbill.gentoo.org [94.100.119.163])
	(using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.gentoo.org (Postfix) with ESMTPS id 3E4EA33E349
	for <gentoo-commits@lists.gentoo.org>; Sun,  9 Jun 2013 13:15:26 +0000 (UTC)
Received: from localhost.localdomain (localhost [127.0.0.1])
	by hornbill.gentoo.org (Postfix) with ESMTP id 0BECAE530A
	for <gentoo-commits@lists.gentoo.org>; Sun,  9 Jun 2013 13:15:24 +0000 (UTC)
From: "Richard Yao" <ryao@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Content-Transfer-Encoding: 8bit
Content-type: text/plain; charset=UTF-8
Reply-To: gentoo-dev@lists.gentoo.org, "Richard Yao" <ryao@gentoo.org>
Message-ID: <1370783660.28da47e3363631dfd1c97164a0efe767f2eb5371.ryao@gentoo>
Subject: [gentoo-commits] proj/genkernel:ryao commit in: defaults/
X-VCS-Repository: proj/genkernel
X-VCS-Files: defaults/initrd.scripts defaults/linuxrc
X-VCS-Directories: defaults/
X-VCS-Committer: ryao
X-VCS-Committer-Name: Richard Yao
X-VCS-Revision: 28da47e3363631dfd1c97164a0efe767f2eb5371
X-VCS-Branch: ryao
Date: Sun,  9 Jun 2013 13:15:24 +0000 (UTC)
Precedence: bulk
List-Post: <mailto:gentoo-commits@lists.gentoo.org>
List-Help: <mailto:gentoo-commits+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-commits+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-commits+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-commits.gentoo.org>
X-BeenThere: gentoo-commits@lists.gentoo.org
X-Archives-Salt: 498e8aac-665e-479f-ab76-4193399eb48f
X-Archives-Hash: 00ec7e4d9b34daf6b73b65442d745c83

commit:     28da47e3363631dfd1c97164a0efe767f2eb5371
Author:     Richard Yao <ryao <AT> gentoo <DOT> org>
AuthorDate: Sun Jun  9 13:13:58 2013 +0000
Commit:     Richard Yao <ryao <AT> gentoo <DOT> org>
CommitDate: Sun Jun  9 13:14:20 2013 +0000
URL:        http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commit;h=28da47e3

Workaround busybox modprobe's inability to load ZFS modules

Commit 3a054014e880e5b1ff28e3d87767c45a073da6b5 replaced our modprobe
with busybox's modprobe. Unfortunately, busybox's modprobe appears to be
unable to properly load modules with more than 1 level of dependencies.

The zfs and zpool commands will invoke modprobe if /dev/zvol is missing,
which concealed this problem. However, this caused problems because some
invocations would fail and under certain circumstances, init would be
killed, causing a kernel panic. This was discovered by commit
71d35173727dc968d7baa2107accb99ebbc5b188 because it changed things so
that the zpool and zfs commands were not run until the ZFS module was
loaded.

busybox modprobe's failure to load module dependencies correctly appears
to occur because busybox modprobe does not wait until until a module is
loaded before loading a module that depends on it, which is a race. It
would be best to correct this race by waiting until the module has
properly loaded, but it is not clear that the race is the only thing
going wrong and developer time is a premium.

We implement a workaround by modifying the busy loop added in the
previous commit to explicit call `modprobe zfs` on each iteration. While
the first few calls fail due to bugs in busybox modprobe, it will
eventually work, after which each call is a noop. This lets us keep
looping until either the loop exit condition that /dev/zvol exist is
reached or the 5 second timeout is reached.

Once the busybox modprobe issue is fixed, this workaround should be safe
to revert.

Signed-off-by: Richard Yao <ryao <AT> gentoo.org>

---
 defaults/initrd.scripts | 5 +++--
 defaults/linuxrc        | 2 --
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/defaults/initrd.scripts b/defaults/initrd.scripts
index f598402..73c0f0c 100644
--- a/defaults/initrd.scripts
+++ b/defaults/initrd.scripts
@@ -637,9 +637,10 @@ chooseKeymap() {
 }
 
 # This helper function is to be called using call_func_timeout.
-# It enables us to wait a reasonable amount of time until /dev/zfs appears.
+# This works around the inability of busybox modprobe to handle complex module dependencies.
+# This also enables us to wait a reasonable amount of time until /dev/zfs appears.
 waitForZFS() {
-	while [ ! -c /dev/zfs ]; do echo >/dev/null; done;
+	while [ ! -c /dev/zfs ]; do modprobe zfs 2> /dev/null; done;
 }
 
 startVolumes() {

diff --git a/defaults/linuxrc b/defaults/linuxrc
index 3784456..d6d0eaa 100644
--- a/defaults/linuxrc
+++ b/defaults/linuxrc
@@ -307,8 +307,6 @@ then
 			break
 		fi
 	done
-
-	[ "USE_ZFS" = "1" ] && MY_HWOPTS="${MY_HWOPTS} zfs"
 fi
 
 splash 'init'