From owner-freebsd-current@freebsd.org Sun Apr 24 18:14:50 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 2333CB1BDEE for ; Sun, 24 Apr 2016 18:14:50 +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 C48E61777 for ; Sun, 24 Apr 2016 18:14:49 +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 u3OIEgWi039099; Sun, 24 Apr 2016 14:14:42 -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 14:14:42 -0400 (EDT) Date: Sun, 24 Apr 2016 14:14:42 -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 18:14:50 -0000 On Sun, 24 Apr 2016, Warner Losh wrote: > On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen > wrote: > >> 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? > > > dump 0f - _.disk.image > ~/foo.dump > > worked for me just now. Is there some reason that it wouldn't work for > you in last orders if you tossed a NANO_DISKIMGDIR in front of it > and last orders would work for you. You could even pipe it into some > compression program... Huh, I didn't know you could do that on the image file. I feel dumb, now ;-) -- DE