11:05 a.m.
Hi there!
I'm looking into getting an ARM system as small home-server. Of course
I'd like to run Fedora on it, but unfortunately it seems that current
Fedora releases are not completely ready for this yet.
I'd like to help with this, and as a start I am trying to get a fully
functioning VM up and running. Obviously there are issues to overcome
with this too. Many thanks for documenting the issues in the wiki!
Before I decide to buy myself a Pandaboard or similar, I'd like to get
some more experience with Fedora on ARM. My first personal project
will be getting libvirt work with ARM out of the box. I hope that this
attracts some more interested parties and lowers the barrier for
contributions.
While I am checking the details of qemu and libvirt, I am wondering if
there is a kernel available that has virtio support. If not, I will
need to compile my own kernel, which feels a little silly.
https://arm.koji.fedoraproject.org does only seem to have one kernel
package available, and that is kernel-headers which I hardly can use
for booting. I am wondering if there are any scratch-builds available
that have a functioning vmlinz.
Furthermore I'd like to know what the best way is to follow the status
of the current ARM builds, and where to find out where help is most
needed?
Many thanks,
Niels
2:17 p.m.
On 29/01/2011 17:05, Niels de Vos wrote:
Hi there!
I'm looking into getting an ARM system as small home-server. Of course
I'd like to run Fedora on it, but unfortunately it seems that current
Fedora releases are not completely ready for this yet.
It's probably ready enough. F12 is the stable one, and F13 alpha rootfs
is available. A few things are missing (a few important KDE parts, but
they do build OK on F12), and a few things are broken and unstable
(Firefox of the F12 vintage isn't of generically good enough quality to
handle bug-free running on ARM), but overall it's more than usable
enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from
the koji repository where packages update cleanly) on my Sheevaplug
(Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work
quite well - certainly well enough for any common server tasks.
You may want to check the archives and sign up to the redhat bugzilla
where bugs are tracked. I submitted a patch recently to add a feature to
rc.sysinit that changes the default kernel behaviour about alignment
errors. I suggest you apply it and set the default to fix+warn and file
bugzilla reports for all the apps that cause these warnings.
Here's a direct link to the bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=673691
I'd like to help with this, and as a start I am trying to get a
fully
functioning VM up and running. Obviously there are issues to overcome
with this too. Many thanks for documenting the issues in the wiki!
Before I decide to buy myself a Pandaboard or similar, I'd like to get
some more experience with Fedora on ARM. My first personal project
will be getting libvirt work with ARM out of the box. I hope that this
attracts some more interested parties and lowers the barrier for
contributions.
I'd suggest starting with something self-contained and well supported,
such as the Sheevaplug. It's quite speedy (not as fast as the
Pandaboard, but fast enough and better for development because it's
ARMv5, which means you'll get to see the alignment errors when they
occur rather than them being silently fixed up. Better for testing, IMO.
I have a Mk1 Sheevaplug and it's quite well supported by the community.
While I am checking the details of qemu and libvirt, I am wondering
if
there is a kernel available that has virtio support. If not, I will
need to compile my own kernel, which feels a little silly.
https://arm.koji.fedoraproject.org does only seem to have one kernel
package available, and that is kernel-headers which I hardly can use
for booting. I am wondering if there are any scratch-builds available
that have a functioning vmlinz.
You will almost certainly need to build your own kernel anyway, because
kernels on ARM are pretty CPU specific. While it has recently been
mentioned that there is a project underway to provide a small-ish set of
kernels to try to cover a majority of popular ARM devices, right now you
will almost certainly want to build your own kernel.
ARM emulation using qemu on x86 is OK for minor things to begin with,
but performance is quite crippling.
As for development on ARM and virtualization - I suggest you look at
Linux vserver. I have it pretty much working, but there are a couple of
bugs in the tools stemming from the fact that dietlibc isn't quite bug
free on ARM yet, but it's getting close (see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=667852 )
That means that you'll have to create your /etc/vserver entries for the
VMs manually, but it's not that hard, and I can provide you with some
working examples if you decide to go that way. libvirt/qemu on ARM may
be too slow for any sensible work - I am not sure what the status with
KVM is on ARM, but I wouldn't bet on it working on most (if any) ARM
hardware. Vserver, OTOH, comes with just about no overhead at all, if
you want a jail for testing and developing things. Of course, this
assumes you already have an ARM device already set up and working.
Furthermore I'd like to know what the best way is to follow the
status
of the current ARM builds, and where to find out where help is most
needed?
This list and the RedHat bugzilla are a good place to start. :)
Gordan
7:44 a.m.
Quoting Niels de Vos <devos(a)fedoraproject.org>:
While I am checking the details of qemu and libvirt, I am wondering
if
there is a kernel available that has virtio support.
I tried to get this working a couple of months ago, there are patches
related to it submitted and some of them have made it into the
mainline kernel. Im not sure if all of them have at this point or not.
(I didnt get it to work with the submitted patches so i was just going
to wait. :) ) I haven't tried recently. It is probably time to try
again.
Libvirt handles arm natively.. if you go through the whole machine
setup in libvirt, I think it is the last step, select qemu instead of
kvm, then arm will show up as an option for archtype now. :) However
it doesn't work with the rootfs-12 because of the options to qemu,
that showed up in the script.
If not, I will
need to compile my own kernel, which feels a little silly.
https://arm.koji.fedoraproject.org does only seem to have one kernel
package available, and that is kernel-headers which I hardly can use
for booting. I am wondering if there are any scratch-builds available
that have a functioning vmlinz.
There are directions on how to rebuild the kernel for qemu.. :)
They work.
If you want to try the alpha 13 release, you probably have to copy the
/dev dir out of the old root-fs and move it to the new one.
3:03 p.m.
Hi Gordan,
On Sat, Jan 29, 2011 at 8:17 PM, Gordan Bobic <gordan(a)bobich.net> wrote:
On 29/01/2011 17:05, Niels de Vos wrote:
> Hi there!
>
> I'm looking into getting an ARM system as small home-server. Of course
> I'd like to run Fedora on it, but unfortunately it seems that current
> Fedora releases are not completely ready for this yet.
It's probably ready enough. F12 is the stable one, and F13 alpha rootfs
is available. A few things are missing (a few important KDE parts, but
they do build OK on F12), and a few things are broken and unstable
(Firefox of the F12 vintage isn't of generically good enough quality to
handle bug-free running on ARM), but overall it's more than usable
enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from
the koji repository where packages update cleanly) on my Sheevaplug
(Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work
quite well - certainly well enough for any common server tasks.
You may want to check the archives and sign up to the redhat bugzilla
where bugs are tracked. I submitted a patch recently to add a feature to
rc.sysinit that changes the default kernel behaviour about alignment
errors. I suggest you apply it and set the default to fix+warn and file
bugzilla reports for all the apps that cause these warnings.
Here's a direct link to the bugzilla report:
https://bugzilla.redhat.com/show_bug.cgi?id=673691
Cool! I'm complete unaware what makes ARM a special architecture, so
this is quite interesting. I've added some notes/thoughts to the bug,
maybe it helps to get it included ;)
> I'd like to help with this, and as a start I am trying to get
a fully
> functioning VM up and running. Obviously there are issues to overcome
> with this too. Many thanks for documenting the issues in the wiki!
> Before I decide to buy myself a Pandaboard or similar, I'd like to get
> some more experience with Fedora on ARM. My first personal project
> will be getting libvirt work with ARM out of the box. I hope that this
> attracts some more interested parties and lowers the barrier for
> contributions.
I'd suggest starting with something self-contained and well supported,
such as the Sheevaplug. It's quite speedy (not as fast as the
Pandaboard, but fast enough and better for development because it's
ARMv5, which means you'll get to see the alignment errors when they
occur rather than them being silently fixed up. Better for testing, IMO.
I have a Mk1 Sheevaplug and it's quite well supported by the community.
Good suggestion! And obviously the Sheevaplugs come in a nice box too.
Today I received a Beagleboard on loan, so I think I'll start there
for now. (It doesn't have any network, so I might switch soon...)
> While I am checking the details of qemu and libvirt, I am
wondering if
> there is a kernel available that has virtio support. If not, I will
> need to compile my own kernel, which feels a little silly.
> https://arm.koji.fedoraproject.org does only seem to have one kernel
> package available, and that is kernel-headers which I hardly can use
> for booting. I am wondering if there are any scratch-builds available
> that have a functioning vmlinz.
You will almost certainly need to build your own kernel anyway, because
kernels on ARM are pretty CPU specific. While it has recently been
mentioned that there is a project underway to provide a small-ish set of
kernels to try to cover a majority of popular ARM devices, right now you
will almost certainly want to build your own kernel.
Hmm, thats good to know. I was just hoping that there is something
like a general basic arm kernel with all the modules, which boots on
most boards, but would run sub-optimal.
ARM emulation using qemu on x86 is OK for minor things to begin
with,
but performance is quite crippling.
As for development on ARM and virtualization - I suggest you look at
Linux vserver. I have it pretty much working, but there are a couple of
bugs in the tools stemming from the fact that dietlibc isn't quite bug
free on ARM yet, but it's getting close (see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=667852 )
Well, my laptop runs libvirt and I m quite happy with that. I'll stick
with libvirt/qemu as that does not interfere with my 'production' VMs.
Maybe you understood my question wrong... Gol i to do some
development/tests on my x86_64 laptop, and then run the resulting
packages on the hardware ARM.
That means that you'll have to create your /etc/vserver entries
for the
VMs manually, but it's not that hard, and I can provide you with some
working examples if you decide to go that way. libvirt/qemu on ARM may
be too slow for any sensible work - I am not sure what the status with
KVM is on ARM, but I wouldn't bet on it working on most (if any) ARM
hardware. Vserver, OTOH, comes with just about no overhead at all, if
you want a jail for testing and developing things. Of course, this
assumes you already have an ARM device already set up and working.
> Furthermore I'd like to know what the best way is to follow the status
> of the current ARM builds, and where to find out where help is most
> needed?
This list and the RedHat bugzilla are a good place to start. :)
Great! I'll get all sorted and hope to be able to provide some help soon :)
Cheers,
Niels
Gordan
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
3:39 p.m.
On 31/01/2011 21:03, Niels de Vos wrote:
>> I'm looking into getting an ARM system as small
home-server. Of course
>> I'd like to run Fedora on it, but unfortunately it seems that current
>> Fedora releases are not completely ready for this yet.
>
> It's probably ready enough. F12 is the stable one, and F13 alpha rootfs
> is available. A few things are missing (a few important KDE parts, but
> they do build OK on F12), and a few things are broken and unstable
> (Firefox of the F12 vintage isn't of generically good enough quality to
> handle bug-free running on ARM), but overall it's more than usable
> enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from
> the koji repository where packages update cleanly) on my Sheevaplug
> (Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work
> quite well - certainly well enough for any common server tasks.
>
> You may want to check the archives and sign up to the redhat bugzilla
> where bugs are tracked. I submitted a patch recently to add a feature to
> rc.sysinit that changes the default kernel behaviour about alignment
> errors. I suggest you apply it and set the default to fix+warn and file
> bugzilla reports for all the apps that cause these warnings.
>
> Here's a direct link to the bugzilla report:
> https://bugzilla.redhat.com/show_bug.cgi?id=673691
Cool! I'm complete unaware what makes ARM a special architecture, so
this is quite interesting. I've added some notes/thoughts to the bug,
maybe it helps to get it included ;)
Thanks. I won't hold my breath for it, though. :)
>> While I am checking the details of qemu and libvirt, I am
wondering if
>> there is a kernel available that has virtio support. If not, I will
>> need to compile my own kernel, which feels a little silly.
>> https://arm.koji.fedoraproject.org does only seem to have one kernel
>> package available, and that is kernel-headers which I hardly can use
>> for booting. I am wondering if there are any scratch-builds available
>> that have a functioning vmlinz.
>
> You will almost certainly need to build your own kernel anyway, because
> kernels on ARM are pretty CPU specific. While it has recently been
> mentioned that there is a project underway to provide a small-ish set of
> kernels to try to cover a majority of popular ARM devices, right now you
> will almost certainly want to build your own kernel.
Hmm, thats good to know. I was just hoping that there is something
like a general basic arm kernel with all the modules, which boots on
most boards, but would run sub-optimal.
No such thing at the moment. If you look through the kernel
configuration options, there is no "generic" option - you have to select
pretty specifically what you want it to run on, and there's no
multi-choice on CPU selection.
> ARM emulation using qemu on x86 is OK for minor things to begin
with,
> but performance is quite crippling.
>
> As for development on ARM and virtualization - I suggest you look at
> Linux vserver. I have it pretty much working, but there are a couple of
> bugs in the tools stemming from the fact that dietlibc isn't quite bug
> free on ARM yet, but it's getting close (see this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=667852 )
Well, my laptop runs libvirt and I m quite happy with that. I'll stick
with libvirt/qemu as that does not interfere with my 'production' VMs.
Maybe you understood my question wrong... Gol i to do some
development/tests on my x86_64 laptop, and then run the resulting
packages on the hardware ARM.
I get it, but ARM emulated on x86 will run at a tiny fraction of native
speed. You may well find it completely unusable.
Gordan
3:41 p.m.
On Mon, Jan 31, 2011 at 1:44 PM, <omalleys(a)msu.edu> wrote:
Quoting Niels de Vos <devos(a)fedoraproject.org>:
> While I am checking the details of qemu and libvirt, I am wondering if
> there is a kernel available that has virtio support.
I tried to get this working a couple of months ago, there are patches
related to it submitted and some of them have made it into the
mainline kernel. Im not sure if all of them have at this point or not.
(I didnt get it to work with the submitted patches so i was just going
to wait. :) ) I haven't tried recently. It is probably time to try
again.
Okay, good to know. Do you have any specific pointers? Depending on my
own needs/interest, I might understand the issue and propose updated
patches (if needed).
Libvirt handles arm natively.. if you go through the whole machine
setup in libvirt, I think it is the last step, select qemu instead of
kvm, then arm will show up as an option for archtype now. :) However
it doesn't work with the rootfs-12 because of the options to qemu,
that showed up in the script.
Yeah, I got that working now. A bug that the script fixes has been
logged as https://bugzilla.redhat.com/show_bug.cgi?id=667345. I
Provided a patch now, and I hope to be able to get that included soon.
> If not, I will
> need to compile my own kernel, which feels a little silly.
> https://arm.koji.fedoraproject.org does only seem to have one kernel
> package available, and that is kernel-headers which I hardly can use
> for booting. I am wondering if there are any scratch-builds available
> that have a functioning vmlinz.
There are directions on how to rebuild the kernel for qemu.. :)
They work.
:D You are the second one to mention that building my own kernel is
needed. I don't doubt that the instructions work, and obviously I need
to follow them.
If you want to try the alpha 13 release, you probably have to copy
the
/dev dir out of the old root-fs and move it to the new one.
I'll note it down and hope to find out if that is needed within a
couple of weeks.
Thanks,
Niels
3:45 p.m.
Quoting Gordan Bobic <gordan(a)bobich.net>:
On 31/01/2011 21:03, Niels de Vos wrote:
>>> I'm looking into getting an ARM system as small home-server. Of course
>>> I'd like to run Fedora on it, but unfortunately it seems that current
>>> Fedora releases are not completely ready for this yet.
>>
>> It's probably ready enough. F12 is the stable one, and F13 alpha rootfs
>> is available. A few things are missing (a few important KDE parts, but
>> they do build OK on F12), and a few things are broken and unstable
>> (Firefox of the F12 vintage isn't of generically good enough quality to
>> handle bug-free running on ARM), but overall it's more than usable
>> enough. I run a F12/F13 hybrid (F12 rootfs yum updated to F13 alpha from
>> the koji repository where packages update cleanly) on my Sheevaplug
>> (Kirkwood ARMv5) and on my Toshiba AC100 (Tegra 2 ARMv7), and they work
>> quite well - certainly well enough for any common server tasks.
>>
>> You may want to check the archives and sign up to the redhat bugzilla
>> where bugs are tracked. I submitted a patch recently to add a feature to
>> rc.sysinit that changes the default kernel behaviour about alignment
>> errors. I suggest you apply it and set the default to fix+warn and file
>> bugzilla reports for all the apps that cause these warnings.
>>
>> Here's a direct link to the bugzilla report:
>> https://bugzilla.redhat.com/show_bug.cgi?id=673691
>
> Cool! I'm complete unaware what makes ARM a special architecture, so
> this is quite interesting. I've added some notes/thoughts to the bug,
> maybe it helps to get it included ;)
Thanks. I won't hold my breath for it, though. :)
>>> While I am checking the details of qemu and libvirt, I am wondering if
>>> there is a kernel available that has virtio support. If not, I will
>>> need to compile my own kernel, which feels a little silly.
>>> https://arm.koji.fedoraproject.org does only seem to have one kernel
>>> package available, and that is kernel-headers which I hardly can use
>>> for booting. I am wondering if there are any scratch-builds available
>>> that have a functioning vmlinz.
>>
>> You will almost certainly need to build your own kernel anyway, because
>> kernels on ARM are pretty CPU specific. While it has recently been
>> mentioned that there is a project underway to provide a small-ish set of
>> kernels to try to cover a majority of popular ARM devices, right now you
>> will almost certainly want to build your own kernel.
>
> Hmm, thats good to know. I was just hoping that there is something
> like a general basic arm kernel with all the modules, which boots on
> most boards, but would run sub-optimal.
No such thing at the moment. If you look through the kernel
configuration options, there is no "generic" option - you have to select
pretty specifically what you want it to run on, and there's no
multi-choice on CPU selection.
Im actually kind of wondering if the qemu/arm/virtio kernel should be
the "default kernel".. Just to get people started who don't have the
hardware..
>> ARM emulation using qemu on x86 is OK for minor things to
begin with,
>> but performance is quite crippling.
>>
>> As for development on ARM and virtualization - I suggest you look at
>> Linux vserver. I have it pretty much working, but there are a couple of
>> bugs in the tools stemming from the fact that dietlibc isn't quite bug
>> free on ARM yet, but it's getting close (see this bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=667852 )
>
> Well, my laptop runs libvirt and I m quite happy with that. I'll stick
> with libvirt/qemu as that does not interfere with my 'production' VMs.
>
> Maybe you understood my question wrong... Gol i to do some
> development/tests on my x86_64 laptop, and then run the resulting
> packages on the hardware ARM.
I get it, but ARM emulated on x86 will run at a tiny fraction of native
speed. You may well find it completely unusable.
It is very slow compared to real hardware. However, some of the
performance issue is the fact the default kernel and the default board
only uses 128M of ram at least in F12.
Also, iirc we didn't find any alignment errors with the qemu-arm test.
3:56 p.m.
On 31/01/2011 21:45, omalleys(a)msu.edu wrote:
>>> ARM emulation using qemu on x86 is OK for minor things to
begin with,
>>> but performance is quite crippling.
>>>
>>> As for development on ARM and virtualization - I suggest you look at
>>> Linux vserver. I have it pretty much working, but there are a couple of
>>> bugs in the tools stemming from the fact that dietlibc isn't quite bug
>>> free on ARM yet, but it's getting close (see this bug:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=667852 )
>>
>> Well, my laptop runs libvirt and I m quite happy with that. I'll stick
>> with libvirt/qemu as that does not interfere with my 'production' VMs.
>>
>> Maybe you understood my question wrong... Gol i to do some
>> development/tests on my x86_64 laptop, and then run the resulting
>> packages on the hardware ARM.
>
> I get it, but ARM emulated on x86 will run at a tiny fraction of native
> speed. You may well find it completely unusable.
It is very slow compared to real hardware. However, some of the
performance issue is the fact the default kernel and the default board
only uses 128M of ram at least in F12.
Also, iirc we didn't find any alignment errors with the qemu-arm test.
The emulation probably transparently fixes them.
Gordan
4834
days inactive
4836
days old
7 comments
3 participants
participants (3)
-
Gordan Bobic -
Niels de Vos -
omalleys＠msu.edu