6:52 p.m.
The Fedora 13 ARM Beta is now available for download. There are still a number of packages
that haven’t been built for ARM due to build failures or missing dependencies. We’re a
little behind the primary architectures so we have the ability to look at later releases
to see if these failures have been fixed – thankfully a large number include support for
ARM. Because of this we expect that with Fedora 14 and 15 we will be closer in line with
the primary architectures.
A new root file system is available for download -
http://scotland.proximity.on.ca/fedora-arm/beta/f13/rootfs-f13-beta-2011-...
The password for the root account is “fedoraarm”.
Instructions for using the root file system can be found at -
http://fedoraproject.org/wiki/Architectures/ARM/Using
The Fedora 13 ARM repository is temporarily located at –
http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-02-21/f13-arm/ar...
A comparision of the packages included in this beta release with the versions included in
the primary 32-bit architecture (i686) - http://hongkong.proximity.on.ca/f13-arm-beta1/
The Fedora 13 ARM Beta release notes -
http://fedoraproject.org/wiki/Architectures/ARM/F13-ARM-Beta1
We will now be working to get the remaining packages in Fedora 13 built, then move on to
updates and Fedora 14.
Enjoy,
Paul Whalen
http://paulfedora.wordpress.com
11:59 p.m.
On 02/23/2011 05:52 PM, Paul Whalen wrote:
The Fedora 13 ARM Beta is now available for download. There are still a
number of packages that haven’t been built for ARM due to build failures
or missing dependencies.
Presumably, for those of us that started with the Alpha (or yum updated
from F12), a simple yum update from the koji repository will get us up
to date?
Is the yum baseurl still the same? Or is there a more proper/permanent
baseurl to use?
We’re a little behind the primary architectures
so we have the ability to look at later releases to see if these
failures have been fixed – thankfully a large number include support for
ARM. Because of this we expect that with Fedora 14 and 15 we will be
closer in line with the primary architectures.
[...]
We will now be working to get the remaining packages in Fedora 13
built, then move on to updates and Fedora 14.
There are a number of things that have only started to build properly on
ARM with the latest rawhide (i.e. post F15 branch). dietlibc is one
example. LibreOffice may turn out to be another (3.3.0.4 from rawhide -
my build is at 57 hours and still going, on a SheevaPlug, which is a lot
further than it got before).
Until most things build out of the box on the baseline distro is there
really much point in following the main release versions (F14 and F15)?
Would it perhaps make more sense to just follow rawhide until we can
actually lock-step with the primary releases, or at least follow with a
sub-release-interval delay?
Gordan
10:52 a.m.
Gordan Bobic píše v St 23. 02. 2011 v 22:59 +0000:
On 02/23/2011 05:52 PM, Paul Whalen wrote:
>
> The Fedora 13 ARM Beta is now available for download. There are still a
> number of packages that haven’t been built for ARM due to build failures
> or missing dependencies.
Presumably, for those of us that started with the Alpha (or yum updated
from F12), a simple yum update from the koji repository will get us up
to date?
Not sure if F-12 will make a difference, but "yum update" from F-11
isn't possible due the xz compression used in the rpms and I didn't want
to spend much time on back-porting the right rpm. So I've replaced the
F-11 filesystem on my sheevaplug with the F-13 one, used the same 2.6.32
kernel + initramfs to boot and it works fine.
Is the yum baseurl still the same? Or is there a more
proper/permanent
baseurl to use?
I suppose the normal fedora mirrormanager will be used when the final
F-13 repo is moved to secondary.fp.o
Dan
10:55 a.m.
Dan Horák wrote:
Gordan Bobic píše v St 23. 02. 2011 v 22:59 +0000:
> On 02/23/2011 05:52 PM, Paul Whalen wrote:
>> The Fedora 13 ARM Beta is now available for download. There are still a
>> number of packages that haven’t been built for ARM due to build failures
>> or missing dependencies.
> Presumably, for those of us that started with the Alpha (or yum updated
> from F12), a simple yum update from the koji repository will get us up
> to date?
Not sure if F-12 will make a difference, but "yum update" from F-11
isn't possible due the xz compression used in the rpms and I didn't want
to spend much time on back-porting the right rpm. So I've replaced the
F-11 filesystem on my sheevaplug with the F-13 one, used the same 2.6.32
kernel + initramfs to boot and it works fine.
You misunderstood what I said - I'd already yum updated F12 to F13. :)
I was asking if yum updating to get to beta packages would be sufficient
to get in line with the beta release from the alpha.
Gordan
11 a.m.
Gordan Bobic píše v Po 28. 02. 2011 v 09:55 +0000:
Dan Horák wrote:
> Gordan Bobic píše v St 23. 02. 2011 v 22:59 +0000:
>> On 02/23/2011 05:52 PM, Paul Whalen wrote:
>>> The Fedora 13 ARM Beta is now available for download. There are still a
>>> number of packages that haven’t been built for ARM due to build failures
>>> or missing dependencies.
>> Presumably, for those of us that started with the Alpha (or yum updated
>> from F12), a simple yum update from the koji repository will get us up
>> to date?
>
> Not sure if F-12 will make a difference, but "yum update" from F-11
> isn't possible due the xz compression used in the rpms and I didn't want
> to spend much time on back-porting the right rpm. So I've replaced the
> F-11 filesystem on my sheevaplug with the F-13 one, used the same 2.6.32
> kernel + initramfs to boot and it works fine.
You misunderstood what I said - I'd already yum updated F12 to F13. :)
Ah, that happens to me occasionally :-)
Dan
10:06 p.m.
Paul Whalen píše v St 23. 02. 2011 v 12:52 -0500:
The Fedora 13 ARM repository is temporarily located at –
http://arm.koji.fedoraproject.org/mash/beta/f13-arm-2011-02-21/f13-arm/ar...
it would be nice if the fedora comps groups definitions could be
included in the repos. Haven't tried it personally, but mash should be
able to process them with the "-f" command line option. It would help a
lot when installing eg. desktops on top of the root fs.
Dan
10:54 a.m.
Hey Paul, Chris, everyone,
I'm really enjoying the Beta release. Congratulations! :)
So far, I have a local installation, and I have gotten dracut working
with a locally generated initramfs, on a 2.6.38 kernel (with updated
OMAP serial drivers, etc.). A few hacks have been required, and I will
begin to capture and share them...but it's great so far!
Jon.
11:40 p.m.
On Wed, 2011-03-16 at 05:54 -0400, Jon Masters wrote:
I'm really enjoying the Beta release. Congratulations! :)
So far, I have a local installation, and I have gotten dracut working
with a locally generated initramfs, on a 2.6.38 kernel (with updated
OMAP serial drivers, etc.). A few hacks have been required, and I will
begin to capture and share them...but it's great so far!
Some of the changes I made:
1). Switch to the new OMAP serial device naming (ttyO2). This breaks
various assumptions in Upstart that probably aren't worth fixing given
the move to systemd. Instead, I created /etc/init/serial-ttyO2.conf:
# Automatically start a console on the OMAP serial port (the second
port)
start on stopped rc RUNLEVEL=[2345]
stop on starting runlevel [016]
respawn
exec /sbin/agetty /dev/ttyO2 115200 vt100-nav
2). Force install the libdrm bits (by using yumdownloader) and other
dependencies with a requirement of the "kernel" package (I may either
create a dummy kernel package, or ask that the yum folks provide a means
to augment "exclude" with "pretend I have this package"). We do need
a
kernel in due course, but this is sufficient for now. Then one can
generate an initramfs (dracut) via "mkinitrd".
3). Force disable Plymouth on the command line:
rd_NO_PLYMOUTH
This is required because Plymouth does not handle serial consoles it
doesn't understand very well, and one ends up with no useful boot. This
requires a bug being filed if it is going to continue in F15, etc. but
I'm not sure it's worth filing at the moment due to a number of changes
being made to that package since.
4). Here is my local partition map:
Disk /dev/mmcblk0: 3959 MB, 3959422976 bytes
255 heads, 63 sectors/track, 481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xadb2c7c7
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1 65 522081 e W95 FAT16
(LBA)
/dev/mmcblk0p2 66 131 530145 83 Linux
/dev/mmcblk0p3 132 197 530145 82 Linux
swap / Solaris
/dev/mmcblk0p4 198 481 2281230 83 Linux
Command (m for help): x
Expert command (m for help): p
Disk /dev/mmcblk0: 255 heads, 63 sectors, 481 cylinders
Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 80 1 1 0 254 63 64 63 1044162 0e
2 00 0 1 65 254 63 130 1044225 1060290 83
3 00 0 1 131 254 63 196 2104515 1060290 82
4 00 0 1 197 254 63 480 3164805 4562460 83
Expert command (m for help): r
Note that it is required that the first partition be of even size, and
marked active in order for it to correctly operate (I sent details of
this to Chris and Paul and will update the docs). The first partition is
being used for U-Boot and supporting images, while the second one is
mounted on /boot (the first is on /boot/uboot). The intention here is to
cleanup the bootloader situation and have standard /boot use eventually.
I am using a "swap" partition for testing, but it will be used as an LVM
physical volume shortly to get LVM setup. Once that is done, LVM will
replace the final / partition and the PV will be moved across.
5). I have a working 2.6.38 kernel setup. In due course, I will build an
RPM based kernel and publish it. I would like to discuss maintaining
such an ARM kernel for Fedora - we will need to consider whether to do
pure upstream (which is almost sufficient for BB-xM now) or pull from
specific trees, or just cherry pick stuff. I'll start a thread.
I have some test images that I am playing with. If it would be of value,
I can post them for a "dd out of the box" BB-xM experience.
Jon.
4783
days inactive
4804
days old
8 comments
6 participants
participants (6)
-
Chris Tyler -
Dan Horák -
Gordan Bobic -
Jon Masters -
Jon Masters -
Paul Whalen