From owner-freebsd-questions@freebsd.org Sun Aug 21 16:05:37 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 F3BD6BC161F for ; Sun, 21 Aug 2016 16:05:36 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA9BC1F74 for ; Sun, 21 Aug 2016 16:05:36 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: by mail-it0-f44.google.com with SMTP id f6so63612767ith.0 for ; Sun, 21 Aug 2016 09:05:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=Fl1YMAcrNoO/Ae4PGty2ty8qZjaBHuhQl1s8apLTjcE=; b=UUOQmdMggg+5RTcOgIx5gD/IhQCmwIQbR3VEguHzvjEy7GieCsgRpQqf66CNvMH9SV +dk1NXQ4JQ3URYViXMz6RhG0VkX1WIY+xwC7GrYNkwBDyj3nNcYeacSKAnC3YfQ702zE JjN40hh66HO3DAay0RaWAsz3mRfHRM1wBcrGt7ipiriX0UN+fd7NoDm4BllBqk1UfvWv l4udzgDBBnYmgtTIYA66nYA34KasEKmCT10YN8g22qXc3xOG86Vuwn5LbxpsxebXRhcu 0MtGWia3/bY0R+q0iTk7s5lOqXBm2nVBwD8hszRoubkwLosX7q3xp+DFH7B9L5tIe+4J NwwA== X-Gm-Message-State: AEkoouvh4V4tG4Kx/3XoWwrLxzsFf8bTBIa4IsIcgpNsX0asc7PcjQljQZvxqSelE/Uvow== X-Received: by 10.36.120.197 with SMTP id p188mr11726509itc.44.1471795530076; Sun, 21 Aug 2016 09:05:30 -0700 (PDT) Received: from WorkBox.Home.gmail.com (63-231-167-45.mpls.qwest.net. [63.231.167.45]) by smtp.gmail.com with ESMTPSA id c40sm7433280iod.6.2016.08.21.09.05.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 21 Aug 2016 09:05:29 -0700 (PDT) References: <20160815145419.GA3619@admin.sibptus.transneft.ru> <20160815231414.GA84125@neutralgood.org> <20160820105438.GA59960@admin.sibptus.transneft.ru> User-agent: mu4e 0.9.16; emacs 24.5.1 From: Brandon J. Wandersee To: Victor Sudakov Cc: "Kevin P. Neal" , freebsd-questions@freebsd.org Subject: Re: Root on ZFS, LiveCD and BE In-reply-to: <20160820105438.GA59960@admin.sibptus.transneft.ru> Date: Sun, 21 Aug 2016 11:05:31 -0500 Message-ID: <86lgzq1510.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain 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 16:05:37 -0000 Victor Sudakov writes: > Kevin P. Neal wrote: >> > >> > Which is the appropriate maillist to ask questions about Root-on-ZFS >> > systems? Like the ones below: >> >> It's a reasonable place to start. Folks around here will point you in the >> right direction if the answer requires more expertise. > > Folks, please do :-) > >> > 2. Sometimes it's necessary to mount a system's root from another > >> > system (LiveCD, mfsBSD or similar). To do that, you have to import a > >> > ystem's zroot pool on another system. Is it safe? Is it not going to > >> > render the *original* system unbootable? >> >> You can use the altroot property to be certain that anything automatically >> mounted gets mounted underneath the directory specified by that property. >> Give the zpool import command the "-o altroot=/some/path" option, and make >> sure that /some/path already exists. >> >> You can also import with the "-N" option to prevent automatic mounting of >> datasets in the imported pool. >> >> But, really, take a look at the mountpoint property for the root filesystem > > 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. ;) The 'altroot=' property Kevin mentioned takes care of concern (a). The command `zpool import -R ` mounts the pool at the alternate mountpoint; so `zpool import -R /mnt` temporarily sets '/mnt' as the root of the imported pool, as though you had mounted the root partition of a traditional filesystem there. 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. 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. 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. -- :: Brandon J. Wandersee :: brandon.wandersee@gmail.com :: -------------------------------------------------- :: 'The best design is as little design as possible.' :: --- Dieter Rams ----------------------------------