Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Hedayat Vatankhah]

/*Adam Williamson*/ wrote on Fri, 23 Jun 2017 12:45:07 -0700:

On Fri, 2017-06-23 at 09:06 -0400, Neal Gompa wrote:

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. ;)

Did you actually check yet whether virt-builder is sufficient for your
purposes?
I'd say the difference is comparable to the difference of containers vs 
VMs: sometimes you need user-land of another arch, but do not want to 
run a full VM. For example, it can be used to compile for another arch. 
So, you might want to build a rootfs with compiler &  libraries (but not 
a complete system image with kernel & ...).
As an example, you might refer to rootfs tarballs used for scratchbox to 
compile for different architectures.


Actually, as Fedora does NOT provide cross compilers (e.g. to build user 
land ARM applications under x86_64), it can be used to provide 'The 
Fedora Approach to Cross Compiling'. To create a minimal rootfs with ARM 
compilers & libraries which can be used using qemu to run ARM GCC in the 
rootfs to build your packages.


This is actually how I do cross-compiling in Fedora: I grab a Fedora ARM 
image, install qmeu-user binaries on the host, copy qemu ARM binary into 
the rootfs (even bind-mounting /lib64 before I know we have qemu static 
binaries in Fedora!), patch its DNF to work fine under qemu, install 
required software using 'chroot dnf install ...', bind mounting the 
source directory, chrooting to the rootfs and build the software.


I've always preferred using scratchbox or the above method to compile 
ARM binaries rather than using a full VM, which plays much nicer on my 
pretty-old laptop! :)


Regards,
Hedayat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Adam Williamson]

On Fri, 2017-06-23 at 09:06 -0400, Neal Gompa wrote:
> 
> > 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. ;)

Did you actually check yet whether virt-builder is sufficient for your
purposes?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

On Fri, Jun 23, 2017 at 8:58 AM, Josh Boyer  wrote:
> On Fri, Jun 23, 2017 at 8:22 AM, Neal Gompa  wrote:
>> On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones  
>> 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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Josh Boyer]

On Fri, Jun 23, 2017 at 8:22 AM, Neal Gompa  wrote:
> On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones  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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Richard W.M. Jones]

On Fri, Jun 23, 2017 at 08:22:59AM -0400, Neal Gompa wrote:
> 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).

Fair enough, this must have changed since I last looked at this
(which was a really long time ago).  This does sound like a better
approach too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

On Fri, Jun 23, 2017 at 8:08 AM, Richard W.M. Jones  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  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).

More info on OBS prjconf directives:
http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.build_config.html

The same basic approach is probably doable for a debootstrap-like tool
for Fedora.

[1]: https://build.opensuse.org/project/prjconf/Fedora:26


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Richard W.M. Jones]

On Thu, Jun 22, 2017 at 09:55:31AM -0400, Josh Boyer wrote:
> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa  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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Richard W.M. Jones]

On Thu, Jun 22, 2017 at 06:29:38AM -0700, John Reiser wrote:
> febootstrap takes a list of .rpms and builds a root filesystem that contains 
> them.

febootstrap [if you're talking about the tool I wrote 8 years ago] is
obsolete.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Peter Robinson]

On Thu, Jun 22, 2017 at 3:03 PM, Neal Gompa  wrote:
> On Thu, Jun 22, 2017 at 9:55 AM, Josh Boyer  wrote:
>> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa  wrote:
>>> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser  wrote:
 On 06/22/2017 0013Z, Neal Gompa wrote:
>
> Yes, we do have debootstrap, but it can only build Debian-based systems.
> :)
>
> I want to be able to build a Fedora based one.


 Please be specific, and give a concrete example of what should change.

 debootstrap takes a list of .debs and builds a root filesystem that 
 contains
 them.
 febootstrap takes a list of .rpms and builds a root filesystem that 
 contains
 them.
 In both cases the result contains some distro-specific metadata as files:
 the packaging data for maintenance of the system, which is implicit
 (are not files that are contained in some input .debs or .rpms.)
 In the case of Debian, the "extra" info is the apt metadata.
 In the case of Fedora, the "extra" info is the dnf/yum metadata.

 Anything else?

>>>
>>> debootstrap has the capability to utilize qemu-user-static to support
>>> constructing foreign arch rootfses. That means I can build an arm64,
>>> armhf, or ppc64el rootfs from an x86_64 host. As far as I know,
>>> febootstrap can't do this.
>>>
>>> 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?
>
> Well, it's part of a workflow to construct custom AArch64 images from
> an x86_64 PC. It's not generally feasible to do all the work on an
> SBC, and all the approaches I've found so far assume native arch for
> Fedora.
>
> In addition, it's a good gateway for being able to set up emulated
> build environments for foreign architectures in things like mock, so
> that the limitation of having real hardware can go away for people to
> test builds locally.
>
> It's a pretty huge deficiency to not have *something* for this purpose.

We have the ability to run full virtual emulated machines using
libvirt so there is *something* for this purpose and there has been
for *quite* some time and it's been documented in the wiki for as long
as it's been available:
https://fedoraproject.org/wiki/Architectures/AArch64/F25/Installation#Install_with_QEMU
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Peter Robinson]

On Wed, Jun 21, 2017 at 3:08 AM, Neal Gompa  wrote:
> Hey all,
>
> I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for
> aarch64 (similar to debootstrap with "debootstrap --arch arm64 
> "), but I can't seem to find any.
>
> I recall that we added qemu-user-static back in Fedora 24 for the
> purpose of being able to support this kind of thing, but do we have
> anything that leverages it to be able to enable this?

You can run a aarch64 emulated VM on x86_64, which won't be fast, but
you can then use anaconda install or a kickstart to install into a VM
raw disk.

We also produce (currently unsupported) raw disk images aimed at
aarch64 SBC images for F-26+ but we have some current bootloader
issues so they're very much currently aimed at people that understand
the low level bits of the bootloader/kernel for testing/fixing. IE if
you have issues or don't understand that you get to keep both pieces
(hoping to have those issues fixed RSN).

What are you trying to achieve?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

On Thu, Jun 22, 2017 at 9:55 AM, Josh Boyer  wrote:
> On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa  wrote:
>> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser  wrote:
>>> On 06/22/2017 0013Z, Neal Gompa wrote:

 Yes, we do have debootstrap, but it can only build Debian-based systems.
 :)

 I want to be able to build a Fedora based one.
>>>
>>>
>>> Please be specific, and give a concrete example of what should change.
>>>
>>> debootstrap takes a list of .debs and builds a root filesystem that contains
>>> them.
>>> febootstrap takes a list of .rpms and builds a root filesystem that contains
>>> them.
>>> In both cases the result contains some distro-specific metadata as files:
>>> the packaging data for maintenance of the system, which is implicit
>>> (are not files that are contained in some input .debs or .rpms.)
>>> In the case of Debian, the "extra" info is the apt metadata.
>>> In the case of Fedora, the "extra" info is the dnf/yum metadata.
>>>
>>> Anything else?
>>>
>>
>> debootstrap has the capability to utilize qemu-user-static to support
>> constructing foreign arch rootfses. That means I can build an arm64,
>> armhf, or ppc64el rootfs from an x86_64 host. As far as I know,
>> febootstrap can't do this.
>>
>> 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?

Well, it's part of a workflow to construct custom AArch64 images from
an x86_64 PC. It's not generally feasible to do all the work on an
SBC, and all the approaches I've found so far assume native arch for
Fedora.

In addition, it's a good gateway for being able to set up emulated
build environments for foreign architectures in things like mock, so
that the limitation of having real hardware can go away for people to
test builds locally.

It's a pretty huge deficiency to not have *something* for this purpose.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Josh Boyer]

On Thu, Jun 22, 2017 at 9:33 AM, Neal Gompa  wrote:
> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser  wrote:
>> On 06/22/2017 0013Z, Neal Gompa wrote:
>>>
>>> Yes, we do have debootstrap, but it can only build Debian-based systems.
>>> :)
>>>
>>> I want to be able to build a Fedora based one.
>>
>>
>> Please be specific, and give a concrete example of what should change.
>>
>> debootstrap takes a list of .debs and builds a root filesystem that contains
>> them.
>> febootstrap takes a list of .rpms and builds a root filesystem that contains
>> them.
>> In both cases the result contains some distro-specific metadata as files:
>> the packaging data for maintenance of the system, which is implicit
>> (are not files that are contained in some input .debs or .rpms.)
>> In the case of Debian, the "extra" info is the apt metadata.
>> In the case of Fedora, the "extra" info is the dnf/yum metadata.
>>
>> Anything else?
>>
>
> debootstrap has the capability to utilize qemu-user-static to support
> constructing foreign arch rootfses. That means I can build an arm64,
> armhf, or ppc64el rootfs from an x86_64 host. As far as I know,
> febootstrap can't do this.
>
> 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?

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Dan Horák]

On Thu, 22 Jun 2017 09:33:25 -0400
Neal Gompa  wrote:

> On Thu, Jun 22, 2017 at 9:29 AM, John Reiser 
> wrote:
> > On 06/22/2017 0013Z, Neal Gompa wrote:
> >>
> >> Yes, we do have debootstrap, but it can only build Debian-based
> >> systems. :)
> >>
> >> I want to be able to build a Fedora based one.
> >
> >
> > Please be specific, and give a concrete example of what should
> > change.
> >
> > debootstrap takes a list of .debs and builds a root filesystem that
> > contains them.
> > febootstrap takes a list of .rpms and builds a root filesystem that
> > contains them.
> > In both cases the result contains some distro-specific metadata as
> > files: the packaging data for maintenance of the system, which is
> > implicit (are not files that are contained in some input .debs
> > or .rpms.) In the case of Debian, the "extra" info is the apt
> > metadata. In the case of Fedora, the "extra" info is the dnf/yum
> > metadata.
> >
> > Anything else?
> >
> 
> debootstrap has the capability to utilize qemu-user-static to support
> constructing foreign arch rootfses. That means I can build an arm64,
> armhf, or ppc64el rootfs from an x86_64 host. As far as I know,
> febootstrap can't do this.
> 
> 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.

which is a non-trivial issue as rpm can have scriptlets ...


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

On Thu, Jun 22, 2017 at 9:29 AM, John Reiser  wrote:
> On 06/22/2017 0013Z, Neal Gompa wrote:
>>
>> Yes, we do have debootstrap, but it can only build Debian-based systems.
>> :)
>>
>> I want to be able to build a Fedora based one.
>
>
> Please be specific, and give a concrete example of what should change.
>
> debootstrap takes a list of .debs and builds a root filesystem that contains
> them.
> febootstrap takes a list of .rpms and builds a root filesystem that contains
> them.
> In both cases the result contains some distro-specific metadata as files:
> the packaging data for maintenance of the system, which is implicit
> (are not files that are contained in some input .debs or .rpms.)
> In the case of Debian, the "extra" info is the apt metadata.
> In the case of Fedora, the "extra" info is the dnf/yum metadata.
>
> Anything else?
>

debootstrap has the capability to utilize qemu-user-static to support
constructing foreign arch rootfses. That means I can build an arm64,
armhf, or ppc64el rootfs from an x86_64 host. As far as I know,
febootstrap can't do this.

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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[John Reiser]

On 06/22/2017 0013Z, Neal Gompa wrote:

Yes, we do have debootstrap, but it can only build Debian-based systems. :)

I want to be able to build a Fedora based one.


Please be specific, and give a concrete example of what should change.

debootstrap takes a list of .debs and builds a root filesystem that contains 
them.
febootstrap takes a list of .rpms and builds a root filesystem that contains 
them.
In both cases the result contains some distro-specific metadata as files:
the packaging data for maintenance of the system, which is implicit
(are not files that are contained in some input .debs or .rpms.)
In the case of Debian, the "extra" info is the apt metadata.
In the case of Fedora, the "extra" info is the dnf/yum metadata.

Anything else?

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

On Thu, Jun 22, 2017 at 7:37 AM, Sérgio Basto  wrote:
> On Tue, 2017-06-20 at 22:08 -0400, Neal Gompa wrote:
>> Hey all,
>>
>> I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for
>> aarch64 (similar to debootstrap with "debootstrap --arch arm64 
>> "), but I can't seem to find any.
>
> we got debootstrap in Fedora :) [1]
> may you test it ? and report it via bugzilla or directly to me ...
>

Yes, we do have debootstrap, but it can only build Debian-based systems. :)

I want to be able to build a Fedora based one.


真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Sérgio Basto]

On Tue, 2017-06-20 at 22:08 -0400, Neal Gompa wrote:
> Hey all,
> 
> I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for
> aarch64 (similar to debootstrap with "debootstrap --arch arm64 
> "), but I can't seem to find any.

we got debootstrap in Fedora :) [1] 
may you test it ? and report it via bugzilla or directly to me ... 

Best regards, 

[1] 
https://apps.fedoraproject.org/packages/debootstrap

> I recall that we added qemu-user-static back in Fedora 24 for the
> purpose of being able to support this kind of thing, but do we have
> anything that leverages it to be able to enable this?
> 
> Thanks in advance,
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Richard W.M. Jones]

On Tue, Jun 20, 2017 at 10:08:00PM -0400, Neal Gompa wrote:
> Hey all,
> 
> I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for
> aarch64 (similar to debootstrap with "debootstrap --arch arm64 
> "), but I can't seem to find any.
> 
> I recall that we added qemu-user-static back in Fedora 24 for the
> purpose of being able to support this kind of thing, but do we have
> anything that leverages it to be able to enable this?

This is not an official tool, but you could do eg:

  $ virt-builder --arch aarch64 fedora-25
  $ virt-tar-out -a fedora-25.img / fedora-25.tar

I agree that a debootstrap-like official tool would be really nice,
but I've been waiting for that for many years ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Tool for generating a rootfs for foreign arch (aarch64 on x86_64, for example)?

[Neal Gompa]

Hey all,

I'm trying to find a way to bootstrap a Fedora rootfs from x86_64 for
aarch64 (similar to debootstrap with "debootstrap --arch arm64 
"), but I can't seem to find any.

I recall that we added qemu-user-static back in Fedora 24 for the
purpose of being able to support this kind of thing, but do we have
anything that leverages it to be able to enable this?

Thanks in advance,

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org