On Fri, Jun 23, 2017 at 8:58 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Fri, Jun 23, 2017 at 8:22 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >>> On Thu, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote: >>>> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >>>> > The missing piece here is that I want to be able to construct a rootfs >>>> > or an image for an architecture that *isn't* the same as my host >>>> > machine. >>>> >>>> For what purpose? >>> >>> I don't know what Neal is up to, but some uses for a debootstrap-like >>> tool include: >>> >>> * Creating chroots, eg. for confinement of daemons, or testing >>> your code under different distros/versions. >>> >>> * Installing the distribution. Mount a new disk on /tmp/sysroot and >>> run debootstrap /tmp/sysroot, then either unmount the disk and use >>> it to boot a new machine, or run a VM on this disk, or pivot-root >>> into the new distro. >>> >>> * Building containers. >>> >>> There are two subcases, the cross-architecture sub-case (host arch != >>> chroot arch) and the non-root sub-case (run debootstrap as non-root). >>> >>> The non-root sub-case is useful for testing, or any case where you >>> don't want to run stuff as root for security / integrity reasons. The >>> difficult part is setting the right owner/mode on new files. >>> >>> The cross-architecture sub-case is useful where you want to install >>> the distro as above, but for a different architecture. >>> >>> The presence of RPM scripts makes this really hard to do in general. >>> Debootstrap concatenates all the applicable scripts into "init" script >>> which you're supposed to run on first boot in the new environment >>> (where presumably your CPU is able to run them). I don't think this >>> is possible for RPM scripts which are more complex. >>> >>> My opinion is that all RPM scripts should go away, to be replaced by >>> declarative metadata about what users/groups/services/etc are required >>> by the RPM, and it would be up to RPM to execute the right set of >>> commands to bring the system into line with the requirements of the >>> installed packages. >>> >> >> Basically, I want to do *all* of these cases, where host arch != rootfs arch. >> >> I'm trying to set up foreign arch containers to do test and >> development, across multiple distributions/versions. In addition, I'd >> like to be able to set up package builders for foreign arches without >> having to have real hardware everywhere. For some architectures I'm >> working with, real hardware is not practical. >> >> I'd also like to be able to create highly custom image structures for >> foreign architectures from my host machine. This is important for >> making bootable images for weird SBCs and things like that. >> >> As for the scripts thing, I believe the way that debootstrap handles >> that is that the udebs (special debs for install environments) are >> unpacked to provide a minimal script run environment to execute >> apt+dpkg, and then qemu-user-static is configured for the environment, >> and debootstrap then uses the actual rootfs' apt to keep going. That >> allows for most of the basic stuff to actually work correctly. The >> same basic approach is also used by SUSE's OBS for setting up foreign >> arch builder environments[1] (Preinstall and VMinstall directives do >> not run scriptlets, just unpack things). > > You have run into the purest form of open source, the "scratch your > own itch" case. You want to be able to do things that cannot be done > today, and nobody else is working on it. It seems like you have a > really good foundation for what needs to be done, so perhaps you could > start a project to work towards what you need? If you publicize it, > you might even get some contributors to join you. > I'll be honest, I have been thinking about it... Maybe I'll have something soonish. ;) -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
