From owner-freebsd-questions@freebsd.org Sun Aug 21 17:42:53 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EEE4BC0DEF for ; Sun, 21 Aug 2016 17:42:53 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id A5A5615C5 for ; Sun, 21 Aug 2016 17:42:51 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39324108; Sun, 21 Aug 2016 23:42:33 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id u7LHgnv9073345; Mon, 22 Aug 2016 00:42:49 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id u7LHgkfH073344; Mon, 22 Aug 2016 00:42:46 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Mon, 22 Aug 2016 00:42:46 +0700 From: Victor Sudakov To: "Brandon J. Wandersee" Cc: "Kevin P. Neal" , freebsd-questions@freebsd.org Subject: Re: Root on ZFS, LiveCD and BE Message-ID: <20160821174246.GA73293@admin.sibptus.transneft.ru> References: <20160815145419.GA3619@admin.sibptus.transneft.ru> <20160815231414.GA84125@neutralgood.org> <20160820105438.GA59960@admin.sibptus.transneft.ru> <86lgzq1510.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86lgzq1510.fsf@WorkBox.Home> Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 17:42:53 -0000 Brandon J. Wandersee wrote: [dd] > > Kevin, this is all good advice how not to screw up the second (fixit) system > > into which the zroot of the first (original) one is being temporarily imported. > > However, I am more concerned about not screwing up the first, > > *original* system whose zroot is temporarily mounted to another fixit > > system and then again used as a bootable root pool. > > I'll chime in here, as I think I understand Victor correctly: You have a > production system that presently will not boot, and want to mount it in > the LiveCD/Fixit environment for maintenance. However, you're concerned > about (a) the mount points for the imported pool being stacked atop > those of the running system, leaving it unresponsive; and (b) potential > harm that the imported pool might suffer from the import process. If I'm > mistaken about this, please let me know. ;) Yes, my concern is (b). [dd] > > Regarding concern (b), importing a pool should never cause any damage to > it, even if it is in a 'degraded' state. (If the pool is in a 'faulted' > state, such that it cannot be used at all, `zpool import` will simply > fail with an error message.) ZFS is designed so that everything that's > already on the disk is all but guaranteed to remain intact and > consistent in the event of an unclean dismount or shutdown, or failure > to boot. Note that this includes the mistake that leads to the scenario > in concern (a): you mount the ZFS pool over the LiveCD/Fixit > environment, leaving both unresponsive. You could just cut the power to > the machine, and the pool should be just fine (there is always the > possiblity that it won't be, but it's quite unlikely). > > Now, when you try to import a pool that was previously part of another > running system, `zpool` will tell you that "forcing" the import is the > only way to get the result you want. Doing so is safe; ZFS is just > concerned because its record shows that the pool was last seen attached > to a running system and it wasn't properly exported, and so wants to > make certain you aren't trying to use a pool on two different systems > simultaneously. So to sum up the past two paragraphs, importing the pool > should never have any effect at all beyond mounting the datasets, and > those datasets should always be in a clean state. This sounds reassuring. To make it more clear, do I need to export the production pool after the maintenance is finished? > > As for your question regarding boot environments, I'll limit myself to > the suggestion that if your pool isn't booting, I would guess the most > likely cause (given the use of beadm) is that the 'bootfs=' property is > not properly set. Well, it *is* booting, it only looks like /dev is not populated for some obscure reason. > I looked over the bug report you filed and noticed > that you're using the development version beadm. I'd recommend using the > stable release of beadm and seeing if that works. You could also > `chroot` into the system while it's mounted in the LiveCD environment > and use beadm to gather some information. I'll check with the stable version of beadm in bhyve tomorrow, but please note that BE selection made by beadm-devel itself (from a working system) works perfectly. It's only the loader BE selection menu that has this problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru