From owner-freebsd-current@freebsd.org Sun Apr 24 12:35:00 2016 Return-Path: Delivered-To: freebsd-current@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 C2B57B10B3D for ; Sun, 24 Apr 2016 12:35:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 89FFF1CE5 for ; Sun, 24 Apr 2016 12:35:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u3OCYv4d010247; Sun, 24 Apr 2016 08:34:57 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Sun, 24 Apr 2016 08:34:57 -0400 (EDT) Date: Sun, 24 Apr 2016 08:34:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Warner Losh cc: FreeBSD Current Subject: Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8)) In-Reply-To: Message-ID: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 12:35:00 -0000 On Sat, 23 Apr 2016, Warner Losh wrote: > On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen > wrote: > >> [CC trimmed] >> >> On Fri, 22 Apr 2016, Warner Losh wrote: >> >>> >>> I personally will be refraining from engaging further. I plan on seeing >>> what gaps there are by adding support to NanoBSD for packages. I'll be >>> busy >>> with that. In talking to Glen and others, we've already identified a few >>> easy gaps to fill. Once they've done that, I'll get going on NanoBSD with >>> the goal to be able to use it to build a bootable system of any >>> architecture from packages with no root privs. I expect to find issues, >>> but >>> I don't expect to find any issue that's intractable. I expect after the >>> issues are resolved, the end product will be better for everybody. >>> >> >> Thank you for working on NanoBSD. Do you think it would be possible >> to add support for optionally building dump(8) images instead of dd? > > > What do you mean by that, exactly? It would be relatively easy to add > a step that runs dump on the _.disk.image file and squirrel that away. > Last orders the code currently calls it, I believe. Is it something as > simple > as this, or is there some more complexity that I'm failing to understand > or grasp? Perhaps I'm missing something, but when last_orders() is called, isn't the disk already unmounted and 'mdconfig -d -u' already run? -- DE