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. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
