On Sun, 24 Apr 2016, Warner Losh wrote: > On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen <deischen_at_freebsd.org> > wrote: > >> On Sat, 23 Apr 2016, Warner Losh wrote: >> >> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen <deischen_at_freebsd.org> >>> 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 ;-) -- DEReceived on Sun Apr 24 2016 - 16:14:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:04 UTC