Is it possible to run gpart and newfs on file without root access (without mdconfig)?

[Paul Schenkeveld]

On Mon, Jan 21, 2013 at 10:48:50AM +0400, Lev Serebryakov wrote:
> Hello, Xin.
> You wrote 20 ÿíâàðÿ 2013 ã., 12:32:06:
> 
> XL> makefs?
>  It is second step. Here are several problems:
> 
>   (1) makefs doesn't create any partition tables / labels.
>   (2) makefs could not "inject" its image into file with partition
>   tables / labels.
> 
> makefs is good to create FS and make permission fixups (by mtree
> file,generated with root-less install) in one step, but it doesn't
> solve whole problem of full disk image creation, as far as I
> understand.

I solved the FS and GEOM part (kind-of) for a customer a couple of years
ago (sorry, could not take the patches with me :-) ) but this is roughly
what I did.  I re-wrote the create_i386_diskimage function:

 - Instead of creating a memory disk and applying the partitioning to
   that, create_i386_diskimage now creates a shell script that contains
   the necessary fdisk and bsdlabel commands (could easily be changed
   to using gpart if you like) and newfs for cfg and data slices which
   could be run on the target machine to do the initial setup.  The
   script was called something like ${NANO_NAME}_setup.sh

 - It uses newfs to create a UFS filesystem in a file which the script
   would write into ${NANO_DRIVE}s1a, not the a in the end, it's not
   the whole slice as with the original create_i386_diskimage function.

I also rewrote the updatep1 and updatep2 scripts (called it nanoupd) to
write the image into the 'a' partition instead of the whole slice.  This
script automatically determined which slice was the inactive slice to
write the image into.

With the makefs command I created a filesystem that was as small as
possible to hold all the files in ${NANO_WORLDDIR}.  This had the nice
side-effect of saving a lot of space on the build server where I created
images for many target hosts.  I contemplated adding a growfs command
to the ${NANO_NAME}_setup.sh and nanoupd scripts but did not find a
compelling reason to do so.

Because I could still run nanobsd.sh as root I never needed to solve the
ownership and permission problem because the reason for this rewrite was
performance, image size and the ability to build inside a jail where
using md devices and mounting them is not possible.  I believe that the
NetBSD folks create a mtree file on the fly during installworld, even
when not running as root.  This mtree file could be used by makefs to
set permissions in the image it creates.

The resulting create_i386_diskimage took seconds instead of minutes
and produced much compacter images at the expense of needing the setup
script.

It's still on my TODO list to write this new create_i386_diskimage
again and submit it here for evaluation but haven't found the time for
it yet.

I agree with the OP that it would be even nicer if gpart could operate
on a plain file instead of a geom provider but that appears not so
trivial because it relies on calls in the geom kernel modules to do the
real work.  It's perhaps possible and easier to adapt fdisk and bsdlabel
to work on plain files.

HTH

Paul Schenkeveld