From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 22 14:19:06 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9470410656D7 for ; Mon, 22 Nov 2010 14:19:06 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6BF8FC1B for ; Mon, 22 Nov 2010 14:19:05 +0000 (UTC) Received: by wwb39 with SMTP id 39so73663wwb.1 for ; Mon, 22 Nov 2010 06:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:x-mailer; bh=1DzJ1FXHNN/WuwGXVUxfCKWp5pb2xwt0BHiH8B0Df8M=; b=Sy0kX1qZnTN29W8lFrfBLVhgd7MWgNIlwCqTq8SJTsQm4BM/2a3xF5/vRbY9+EqeIa PjUc8oySt4AUmwubHLT5jEvSDJ3ADgveQTgVQQPyg5qdzdNDm270r456r9gKtB7D42IJ 94/T52MaFqg2rkCaR8VfcTLHcFJy21H8WsQ9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:x-mailer; b=N8/40zrGmvKGXPny7GQ3ltqU3gW2mBGNDLKvvZWyL4r/i6H8PJ2fEykZV4eqjMY4Ms 20XLpwouGOTAwSldEhnjsMgQ6cw4ThvdcvUTrU3tLDAhHgbHO8T1rpD/Id02XB9YHSnC 4RZbkdXchaEzMvXyKYYIoHv9grzJNgKxOhIzs= Received: by 10.216.50.11 with SMTP id y11mr5168027web.57.1290435531495; Mon, 22 Nov 2010 06:18:51 -0800 (PST) Received: from DEV ([82.193.208.173]) by mx.google.com with ESMTPS id e12sm2294419wer.36.2010.11.22.06.18.48 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Nov 2010 06:18:50 -0800 (PST) Message-ID: <20101122.141848.015.1@DEV> From: rank1seeker@gmail.com To: freebsd-hackers@freebsd.org Date: Mon, 22 Nov 2010 15:18:48 +0100 X-Mailer: POP Peeper (3.7.0.0) Subject: Unhappy with loader and ZFS's obeyence of zpool.cache's path X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 14:19:06 -0000 As I decided to use GELI, I've split / into 2 UFS partitions /boot is an empty dir (mount point), at encrypted root partition(ada0s3d) The only unencrypted partition is ada0s3a, which contains CONTEST of /boot and is mounted under /boot So, once everything is mounted at boot, FreeBSD's layout is a STANDARD ONE, which is critical, so 'make ... install(kernel|world)' and similar would work. STAGE 2 hits 'a', so there I had to throw a file boot.conf, to override default 0:ad(4,3,a)/boot/loader 0:ad(4,3,a)/loader As that partition contains only CONTEST of a /boot dir I had to rewrite path in this files: loader.rc loader.4th beastie.4th Unfortunately, this one must be touched, or user's loader.conf will NEVER get parsed defaults/loader.conf But it didn't worked! :P Simply because loader is hardcoded, to hit 'loader.rc' in '/boot', and as /boot's contest was in '/' of separate unencrypted partition, so was 'loader.rc', too. Well, this was my first time, to venture into editing sys code # vi /usr/src/sys/boot/common/interp.c Change MIDDLE line: if(include("/boot/loader.rc")!=CMD_OK) include("/boot/boot.conf"); printf("\n"); Into: if(include("/boot/loader.rc")!=CMD_OK) include("/loader.rc"); printf("\n"); I was tempted to replace first line '/boot/loader.rc' with '/loader.rc '(and did so, at first run, which also worked). But after looking at loader's man, I've decided to get rid of '/boot/boot.conf', because: - "Historical" reasons - MY '/boot/boot.conf' is already in use with/for STAGE 2 and STAGE 3 (loader), mustn't have to anything with it. - Preserved (and still maintaining priority of) '/boot/loader.rc', so DESTDIR to another plugged /NEW_HDD or /memstick and 'make ... install(kernel|world)' would work, for those upon boot. ZFS: (I've thought of separate 'Subject', but as they are binded to the same INTRO ...) ---- My laptop now boots correctly, but HELL, zfs wasn't pleased with this (doesn't auto-import pools), so I always needed to do it manually. So back to loader again ... ZFS's modules are properly loaded, now looking at zpool.cache relevant entries, for loader.conf, the only one we need to use is: zpool_cache_name (to target 'zpool.cache' file) But I'll also use 'zpool_cache_type' entry, just for fun and to show how it is an irrelevent entry. In non-default loader.conf add: -- # '/zfs/zpool.cache' would also be loaded zpool_cache_name="zfs/zpool.cache" zpool_cache_type="WEEEEEHO_LOOK_AT_ME_HERE" -- Procedure: - Hit 6 at loader's menu - In loader prompt type: "lsmod" (lists all loaded kernel modules and files) - Look at line containing: "WEEEEEHO_LOOK_AT_ME_HERE" (Yes, I've used it to faster catch your eye, on relevant line) Fact: - 'zpool.cache' file IS LOADED! Now comment out or delete line: 'zpool_cache_name="zfs/zpool.cache"' It'll use an default: 'zpool_cache_name="/boot/zfs/zpool.cache"' Dirty stuff: (Inside /boot) # mv boot boot.BKU # mkdir boot # cd boot # ln -s ../zfs This ... WORKS! :P Once again do a 'Procedure:', from above and look at line containing: "WEEEEEHO_LOOK_AT_ME_HERE" '/boot/zfs/zpool.cache' IS ALSO loaded, BUT only one from THAT path is enforced. I am VERY assured that this is ZFS's internal problem! Unbalivabely but 'zpool_cache_name' entry has NO effect, as it acts like hardcoded. In this form, it shouldn't exists at all, as it just waste mental energy as potential OPTION, which it is NOT! Can anyone point me to part of ZFS's code to edit? Or patch perhaps? (Tested one ...) :) Domagoj