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-02-...
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/arm/o...
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
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
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
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
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
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/arm/o...
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
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.
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.
-
Chris Tyler -
Dan Horák -
Gordan Bobic -
Jon Masters -
Jon Masters -
Paul Whalen