From owner-freebsd-current@freebsd.org Sun Apr 24 16:16:38 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 456D4B1B1A4 for ; Sun, 24 Apr 2016 16:16:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 07C47147F for ; Sun, 24 Apr 2016 16:16:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id u185so162987466iod.3 for ; Sun, 24 Apr 2016 09:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=xRY/d2WAly76CuNUdD7snH2R0yWlsQO9IOxkSIHifRw=; b=LChk2rC1ZHizRs4Ru9XrMtCTPr7WD2zSOgAuwb9xLW/h46WNL7i2kIf7b4Ec+kZ2JE FXutd3WZ64NvDhHH5kRCucDn7Ltj1WRnUGL6CmSXJzCkgXo1mhnbTfW50eCkSkU4sYP6 pJSy3YxoqWsJ4Cx8Kkc5Npwt7JyUkYjJ7xuPnOhaWEXd8lDWfvUc/aRuMJ/8FBdz1LkZ 0DIgGhh2dcpaMbCnSvxk6cEqXsqKL9YRi8bIw2wbbL+zeD5f6iuSevUjjLj3kswaw1xS mmbr+HiKIDZYKd8KIzwJevZfBgVJyif7e9W6F7bZeNNLahBo1UJwjlo7akMlMkx2ir1m zW9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xRY/d2WAly76CuNUdD7snH2R0yWlsQO9IOxkSIHifRw=; b=QW6uVcttVTze1PWifIzXsMpXagqkuG6ve9yfbN6ctwv9WTbIhyjz/hgZeOePfhwbwT X0Q4CM8VmHR92yRQSLZG03f7KTfpX0CXawDLzj9EJNsIkTPNBnG8DQUzDPXvttC2w/bN KklgawL2ATe68xbAy9tH+XJfeQR8eD1DO+eayfhjVJwydqHfZfej/AcNz9z0UU/2zZyY 2uJPGC9Hwc2EzPdJQTgGp64F36gJCJT9TSEwr23a+zy0DPCKz75vgFQ+ZLq6vSroMcfA deeL7JWE/9iWHu/hP9eHfLX5O4jZW9Ovq/nBGQ9QZuVFctQr2eR12NKhY+Qdmbbhe0Og 2a9w== X-Gm-Message-State: AOPr4FXLn3jjWWEy9NQvPq+1f/tMBWWzUWe5GcCd5dyAXpQMNXcYZpxEIk6O5hbBQsdj2ZevJOrMji3vcKLmNw== MIME-Version: 1.0 X-Received: by 10.107.133.229 with SMTP id p98mr5432765ioi.16.1461514597288; Sun, 24 Apr 2016 09:16:37 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Sun, 24 Apr 2016 09:16:37 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> Date: Sun, 24 Apr 2016 10:16:37 -0600 X-Google-Sender-Auth: ZyF8ziH8jaYcOU2EaGpkZpFWrDY Message-ID: Subject: Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8)) From: Warner Losh To: Daniel Eischen Cc: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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 16:16:38 -0000 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... Warner