Fedora 17 ARM has released a couple of snapshots, one of them for RaspberryPi http://blc.fedorapeople.org/fe.....a-arm/f17/
It's also bin released a couple of Alpha (1) images, wich one of them works on the rpi;
(rpi site censor this url for some reason – find it on the wiki)
If you're developer, I recomend using the snapshots.
If you just wanna test it, try both out
Follow the project on it's wiki page;
http://fedoraproject.org/wiki/.....ctures/ARM
or by IRC: #fedora-arm on Freenode
I'll post a video with the rpi running F17ARM as soon as UPS delivers it. It aint that cool on my virtual machine
-
- Posts: 19
- Joined: Thu Mar 08, 2012 3:33 pm
Re: Fedora 17 ARM
It seems to have the same 3.1.9 kernel as the current Fedora 14 and Debian releases (built March 4). Will there be a different kernel in the final release?
Re: Fedora 17 ARM
I'm not sure about the final release.
But I'm currently building a new kernel to fix atleast one bug; the mmc0 long write bug.
But I'm currently building a new kernel to fix atleast one bug; the mmc0 long write bug.
Re: Fedora 17 ARM
As of the 3.1.9 kernel.
That's the kernel which are supplied from the rpi community. Which can be found at https://github.com/raspberrypi/linux
The kernel is build on 3.1.9
When (if?) the drivers are being committed into the upstream version of the kernel. We can just download kernel to compile from kernel.org
My qualified guess is therefore that the r-pi supplied kernel will be staying on kernel 3.1.9 until it's patches are being committed into the upstream one.
That's the kernel which are supplied from the rpi community. Which can be found at https://github.com/raspberrypi/linux
The kernel is build on 3.1.9
When (if?) the drivers are being committed into the upstream version of the kernel. We can just download kernel to compile from kernel.org
My qualified guess is therefore that the r-pi supplied kernel will be staying on kernel 3.1.9 until it's patches are being committed into the upstream one.
Re: Fedora 17 ARM
New site with nightlies
http://scotland.proximity.on.ca/arm-nightlies/vault/
http://scotland.proximity.on.ca/arm-nightlies/vault/
Re: Fedora 17 ARM
It's the same base version number of the kernel, but it's not in fact the same kernelsleep lack wrote:It seems to have the same 3.1.9 kernel as the current Fedora 14 and Debian releases (built March 4). Will there be a different kernel in the final release?

The RPi Foundation have been making regular updates/patches/fixes and releasing new versions of the kernel (and firmware) on github https://github.com/raspberrypi/firmware
I don't have a Pi to check, but unfortunately I believe at this stage https://github.com/Hexxeh/rpi-update won't work correctly with Fedora.
Re: Fedora 17 ARM
Hi there,
seems that in the "nightlies" you'd find something for the Pi:
http://scotland.proximity.on.ca/arm-nig ... lk0.img.xz
[EDIT]
Downloaded it, put on the card and edited the commandline.txt to enable debugging.
It booted OK with ssh access enabled (that's nice).
It complains a lot about
mmc0: note - long write sync xxxxxxxns - xxxx its.
and
hc_xfer timeout
I started "yum update" and it fetched the kernel-3.3.6-3.fc17.armv5tel
Will reboot with it and wonder if this will work...
seems that in the "nightlies" you'd find something for the Pi:
http://scotland.proximity.on.ca/arm-nig ... lk0.img.xz
[EDIT]
Downloaded it, put on the card and edited the commandline.txt to enable debugging.
It booted OK with ssh access enabled (that's nice).
It complains a lot about
mmc0: note - long write sync xxxxxxxns - xxxx its.
and
hc_xfer timeout
I started "yum update" and it fetched the kernel-3.3.6-3.fc17.armv5tel
Will reboot with it and wonder if this will work...
Re: Fedora 17 ARM
Works just fine with the new kernel.

Pity that F17 image is not available from the main RPi Downloads page, and the status of F17 progress is not reflected there... I believe there might be a number of Fedora fans already having their RPi on the desk and willing to contribute some help (at least in testing).
cheers,
P

Pity that F17 image is not available from the main RPi Downloads page, and the status of F17 progress is not reflected there... I believe there might be a number of Fedora fans already having their RPi on the desk and willing to contribute some help (at least in testing).
cheers,
P
Re: Fedora 17 ARM
hi piters
I got a lot of
mmc0: note - long write sync xxxxxxxns - xxxx its.
and
hc_xfer timeout
on my pi, decided its was because my SD card was only a class 4. I bought a couple of 16GB class 10 cards online and they disappeared. I'm guessing that class 4 cards don't have a suitable read/ write speed or sustained read / write speed and the kernel gets a bit upset.
Dave
I got a lot of
mmc0: note - long write sync xxxxxxxns - xxxx its.
and
hc_xfer timeout
on my pi, decided its was because my SD card was only a class 4. I bought a couple of 16GB class 10 cards online and they disappeared. I'm guessing that class 4 cards don't have a suitable read/ write speed or sustained read / write speed and the kernel gets a bit upset.
Dave
--
Dave South, RHCE
dave@backboneconcepts.com
Dave South, RHCE
dave@backboneconcepts.com
Re: Fedora 17 ARM
Exactly how did you update the "fetched" kernel to boot off it?
What does "uname -a" now show?
Currently running with the latest "nightly snapshot" as of the date of this post.
Regards,
Z
What does "uname -a" now show?
Currently running with the latest "nightly snapshot" as of the date of this post.
Regards,
Z
Re: Fedora 17 ARM
OK, I have done the yum update as shown...
[/size]
As you can see, the kernel.img file is not replaced by a newer version. So, my question remains, "How do you get it to boot off the updated kernel?".
Code: Select all
[root@fedora-arm ~]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
[root@fedora-arm ~]# yum update
Loaded plugins: langpacks, presto, refresh-packagekit
fedora/metalink | 3.4 kB 00:00
fedora | 4.2 kB 00:00
fedora/primary_db | 11 MB 00:11
fedora/group_gz | 434 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package kernel.armv5tel 0:3.3.6-3.fc17 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================================================================================================================================================================
Package Arch Version Repository Size
=============================================================================================================================================================================================================================================
Installing:
kernel armv5tel 3.3.6-3.fc17 fedora 13 M
Transaction Summary
=============================================================================================================================================================================================================================================
Install 1 Package
Total download size: 13 M
Installed size: 58 M
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
fedora/prestodelta | 352 kB 00:00
Processing delta metadata
Package(s) data still to download: 13 M
kernel-3.3.6-3.fc17.armv5tel.rpm | 13 MB 00:13
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Installing : kernel-3.3.6-3.fc17.armv5tel 1/1
Verifying : kernel-3.3.6-3.fc17.armv5tel 1/1
Installed:
kernel.armv5tel 0:3.3.6-3.fc17
Complete!
[root@fedora-arm ~]# ls -lastr /boot
total 51356
4 drwxr-xr-x 18 root root 4096 Jan 1 1970 ..
1960 -rwxr-xr-x 1 root root 2001244 Feb 21 15:20 start.elf
312 -rwxr-xr-x 1 root root 314691 Feb 21 15:20 loader.bin
8 -rwxr-xr-x 1 root root 127 Feb 21 15:20 cmdline.txt
8 -rwxr-xr-x 1 root root 141 Feb 21 15:20 cmdline_testmode.txt
24 -rwxr-xr-x 1 root root 16528 Feb 21 15:20 bootcode.bin
1960 -rwxr-xr-x 1 root root 2001244 Feb 21 15:20 arm224_start.elf
1960 -rwxr-xr-x 1 root root 2001244 Feb 21 15:20 arm192_start.elf
1960 -rwxr-xr-x 1 root root 2001244 Feb 21 15:20 arm128_start.elf
6848 -rwxr-xr-x 1 root root 7011340 Mar 3 22:09 kernel.img
3176 -rwxr-xr-x 1 root root 3244400 May 17 07:01 vmlinuz-3.3.6-3.fc17.armv5tel.kirkwood
1392 -rwxr-xr-x 1 root root 1423838 May 17 07:01 System.map-3.3.6-3.fc17.armv5tel.kirkwood
104 -rwxr-xr-x 1 root root 105045 May 17 07:01 config-3.3.6-3.fc17.armv5tel.kirkwood
8 -rwxr-xr-x 1 root root 175 May 17 07:01 .vmlinuz-3.3.6-3.fc17.armv5tel.kirkwood.hmac
1328 -rwxr-xr-x 1 root root 1358499 May 17 09:11 System.map-3.3.6-3.fc17.armv5tel
88 -rwxr-xr-x 1 root root 86519 May 17 09:11 config-3.3.6-3.fc17.armv5tel
3168 -rwxr-xr-x 1 root root 3242528 May 17 09:11 vmlinuz-3.3.6-3.fc17.armv5tel
8 -rwxr-xr-x 1 root root 166 May 17 09:11 .vmlinuz-3.3.6-3.fc17.armv5tel.hmac
8 drwxr-xr-x 3 root root 8192 May 21 23:04 grub2
8 drwxr-xr-x 2 root root 8192 May 21 23:04 grub
14840 -rwxr-xr-x 1 root root 15188528 May 30 01:32 initramfs-3.3.6-3.fc17.armv5tel.kirkwood.img
8 drwxr-xr-x 2 root root 8192 Jun 6 03:09 uboot
16 drwxr-xr-x 5 root root 16384 Jun 7 10:34 .
12160 -rwxr-xr-x 1 root root 12449286 Jun 7 10:38 initramfs-3.3.6-3.fc17.armv5tel.img
[root@fedora-arm ~]#
As you can see, the kernel.img file is not replaced by a newer version. So, my question remains, "How do you get it to boot off the updated kernel?".
Re: Fedora 17 ARM
You don´tzardoz99 wrote:OK, I have done the yum update as shown...
As you can see, the kernel.img file is not replaced by a newer version. So, my question remains, "How do you get it to boot off the updated kernel?".

For now we have to use the kernel provided by raspberry pi.
I´ve made a xz image with the newest kernel.
You can download it from here (It´s without X):
https://www.dropbox.com/s/dgkblk56wjakj ... lk0.img.xz
(This one you can just do a xzcat > /dev/yourmemorycard)
The resize partition thingie will not start on the first boot.. It will start on the second! (and that´s why it´s really slow untill this is done).
If you want to use this kernel+modules on a version with X (This is not tested). Try to just copy whatever´s in the boot partition into your boot partition. + Copy /usr/lib/modules/3.1.9+ catalog to /usr/lib/modules/ on your root partition.
Re: Fedora 17 ARM
I too am receiving these messages. I am currently using this class 6 8GB SDHC card. Unfortunately, the next highest class I have is a class 10, so I won't be able to help in empirically determining what the minimum class of SD card is supported without having these messages display.hi piters
I got a lot of
mmc0: note - long write sync xxxxxxxns - xxxx its.
and
hc_xfer timeout
on my pi, decided its was because my SD card was only a class 4. I bought a couple of 16GB class 10 cards online and they disappeared. I'm guessing that class 4 cards don't have a suitable read/ write speed or sustained read / write speed and the kernel gets a bit upset.
Dave
Re: Fedora 17 ARM
Tried the nightly version with GUI, had lots of long write sync issues with a class 4 card, much better with a class 6 but.. I seem to be unable to log in, the gui offers a guest login or 'other user', the guest login simply loops back on itself (gui drops out and restarts at the login prompt). Is there a default root login I could try?
Re: Fedora 17 ARM
I was on #fedora-arm today and someone had mentioned that the last couple of builds have been giving people problems logging in due to a problem with SELINUX, so I don't think its due to your SD card.Tried the nightly version with GUI, had lots of long write sync issues with a class 4 card, much better with a class 6 but.. I seem to be unable to log in, the gui offers a guest login or 'other user', the guest login simply loops back on itself (gui drops out and restarts at the login prompt). Is there a default root login I could try?
Re: Fedora 17 ARM
I guess you must have missed my post at http://www.raspberrypi.org/phpBB3/viewt ... 854#p94939 that a) describes the problem and b) resolves it.
Here is the text from it.
================================================================
Beware of the "gotchas" of the nightly builds from http://scotland.proximity.on.ca/arm-nightlies/ especially todays one.
I have just been bitten by the activation by the builders of "SELINUX" in enforcing mode.
Not sure quite why but the selinux labelling of files has been lost and as a result, it would not allow login as root.
I had to take the SD card and mount it on another system to return the /etc/selinux/config file back to "permissive" mode.
Once booted on the Raspi and logged in successfully this time, I relabelled the whole card.
================================================================
Z.
Here is the text from it.
================================================================
Beware of the "gotchas" of the nightly builds from http://scotland.proximity.on.ca/arm-nightlies/ especially todays one.
I have just been bitten by the activation by the builders of "SELINUX" in enforcing mode.
Not sure quite why but the selinux labelling of files has been lost and as a result, it would not allow login as root.
I had to take the SD card and mount it on another system to return the /etc/selinux/config file back to "permissive" mode.
Once booted on the Raspi and logged in successfully this time, I relabelled the whole card.
================================================================
Z.
Re: Fedora 17 ARM
Thanks Zardoz, yes I had read your post and figured it might be the problem with root login but I didn't think it also explained the guest login looping round and round?
Re: Fedora 17 ARM
It's the same problem. SELINUX is preventing things from executing properly due to access blocking.
I have NO idea why they thought setting it to "enforcing" mode on an ARM was a good idea.
You kiss goodbye to about 7% performance apparently just by having it not "disabled".
To restore the selinux contexts while it is set to "permissive" mode, you must be booted on the Raspi and invoke "restorecon -r /" as root and wait for a long time. Probably best to disable it completely to be honest.
Z.
I have NO idea why they thought setting it to "enforcing" mode on an ARM was a good idea.
You kiss goodbye to about 7% performance apparently just by having it not "disabled".
To restore the selinux contexts while it is set to "permissive" mode, you must be booted on the Raspi and invoke "restorecon -r /" as root and wait for a long time. Probably best to disable it completely to be honest.
Z.
Re: Fedora 17 ARM
I've created images with the new kernel for all 3 versions;
https://www.dropbox.com/sh/lsynappe4o7mu8z/qnQMn_kgb1
I've only tested the one without X, but the others should work. Please give feedback.
https://www.dropbox.com/sh/lsynappe4o7mu8z/qnQMn_kgb1
I've only tested the one without X, but the others should work. Please give feedback.
Re: Fedora 17 ARM
I downloaded the smallest image, and xzcat'ed it to my SD card:effbiai wrote:I've created images with the new kernel for all 3 versions;
https://www.dropbox.com/sh/lsynappe4o7mu8z/qnQMn_kgb1
I've only tested the one without X, but the others should work. Please give feedback.
# xzcat f17arm-XXX.img.xz > /dev/sdc
When I tried to boot, I got a kernel panic with it complaining about not knowing what partition to use for the rootfs. I simply ran the SD card through gparted on another machine, and extended the partition all the way out. That worked. I rinsed and repeated to see if I could duplicate the behavior, which I could. Then I tried it a 3rd time, and it booted just fine. Weird.
On another note: I've gotten much more reliable network performance (when trying to install things with yum) by adding a tweak. I was seeing a lot of this message:
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
along with a lot of stack traces on the console. The machine basically froze up. But thanks to reading this thread:
http://www.raspberrypi.org/phpBB3/viewt ... =53&t=7581
I learned to add "smsc95xx.turbo_mode=N" to /boot/cmdline.txt. (Thanks, pepedog). After rebooting, I have had much more success installing packages without the machine freezing.
Last edited by gregjo on Wed Jun 13, 2012 7:47 pm, edited 1 time in total.
Re: Fedora 17 ARM
Hello,
I've installed the xfce version, but I can't log in as a root with fedoraarm password, and when I've log with guest, the GUI restarts a few times while the cursor hangs for sec, then it frozen fully.
I've installed the xfce version, but I can't log in as a root with fedoraarm password, and when I've log with guest, the GUI restarts a few times while the cursor hangs for sec, then it frozen fully.
Re: Fedora 17 ARM
@gregjo
I'll update the images to include that fix.
@sirkope
I'll test the X images myself soon
Also.. I've seen on older kernels alot of "evbug" in dmesg. Is it still there? If yes, I'll add it to the blacklist by default.
I'll update the images to include that fix.
@sirkope
I'll test the X images myself soon

Also.. I've seen on older kernels alot of "evbug" in dmesg. Is it still there? If yes, I'll add it to the blacklist by default.
Re: Fedora 17 ARM
The following is my bring up plan for
f17arm-20120613-230701-arm-rpi-xfce-mmcblk0.img.xz
ow to build a 8GB or larger SDcard with Fedora 17 for Raspberry Pi
with selinux disabled and a 2G swap added.
Remember that the Raspberry Pi root password is "fedoraarm"
1. Download ----.xz and ----.xz.ms5sum from
http://scotland.proximity.on.ca/arm-nightlies/
2. Run "md5sum -c ----.xz.md5sum" to verify download
3. "su - root" to run as root on your support system
4. Run "xzcat ----.xz > /dev/???" build image on SDcard
5. Unload the SDcard and remount it
6. Run "gparted" and allocate and format a 2GB swap area at the high end of the
SDcard. (should probably have extended rootfs but I let Raspberry Pi do it.)
7. Run "gedit" and set the SDcard /etc/selinuc/config to "disabled"
8. Run "gedit" and add to the SDcard /etc/fstab a new line
"/dev/mmcblk0p3 swap swap defaults 0 0"
9. Insert the SDcard into Raspberry PI and boot it
10. logon as "guest"
11. Add a new user (yourID)
12. Start a terminal and "su - root" to run as root on Raspberry Pi
13. Run "swapon -s" and check for swap
14. transfer music, pictures, and other user data to SDcard via
usb stick or "shutdown -H now" and move the SDcard back to your
support system for the transfer.
15. use Add/Remove software application to customize your system.
Hardware configuration is a 8GB class 10 Transcend SD card with an Inland wireless mouse and keyboard using one USB port. Power is from a Gear Head powered USB hub and the hub is also used to extend the second system USB port with additional ports for USB sticks and the like.
Results are steps 1 -14 complete
a. Firefox won't run, minVersion= 12.0, MaxVersion=12.0, and Firefox version= 13.0
b. yum won't run as I always get a repository XML file error.
c. putty runs fine on my support system as a SSH terminal.
d. The provided music player fails to make sounds running ogg files. I see the player clock increase
but no sound out of Raspberry Pi. Ogg files work fine on my Fedora 17 support system which is a
64 bit laptop. I assume that Raspberry Pi has a kernel problem.
e. Can't try mp3 files as yum fails trying to install gstreamer-plugins-good, bad etc.
f. Many MMC0: Note - Long write sync problems.
g. Many MMC0: Too large timeout requested for CMD038!
The swap file is required to run. I had a horrible time until I installed it. I believe the SD card performance is rather poor. I may try running from a USB 3.0 stick or USB 3.0 hard disk to see if
it would be better. I don't yet know if the Raspberry Pi I/O bus on the SD card is the actual
bottleneck. I haven't yet figured out how to use the Fedora Arm Koji system to get updated code
and possibly the yum updates for all the code the is ready. (arm.koji.fedoraproject.org)
f17arm-20120613-230701-arm-rpi-xfce-mmcblk0.img.xz
ow to build a 8GB or larger SDcard with Fedora 17 for Raspberry Pi
with selinux disabled and a 2G swap added.
Remember that the Raspberry Pi root password is "fedoraarm"
1. Download ----.xz and ----.xz.ms5sum from
http://scotland.proximity.on.ca/arm-nightlies/
2. Run "md5sum -c ----.xz.md5sum" to verify download
3. "su - root" to run as root on your support system
4. Run "xzcat ----.xz > /dev/???" build image on SDcard
5. Unload the SDcard and remount it
6. Run "gparted" and allocate and format a 2GB swap area at the high end of the
SDcard. (should probably have extended rootfs but I let Raspberry Pi do it.)
7. Run "gedit" and set the SDcard /etc/selinuc/config to "disabled"
8. Run "gedit" and add to the SDcard /etc/fstab a new line
"/dev/mmcblk0p3 swap swap defaults 0 0"
9. Insert the SDcard into Raspberry PI and boot it
10. logon as "guest"
11. Add a new user (yourID)
12. Start a terminal and "su - root" to run as root on Raspberry Pi
13. Run "swapon -s" and check for swap
14. transfer music, pictures, and other user data to SDcard via
usb stick or "shutdown -H now" and move the SDcard back to your
support system for the transfer.
15. use Add/Remove software application to customize your system.
Hardware configuration is a 8GB class 10 Transcend SD card with an Inland wireless mouse and keyboard using one USB port. Power is from a Gear Head powered USB hub and the hub is also used to extend the second system USB port with additional ports for USB sticks and the like.
Results are steps 1 -14 complete
a. Firefox won't run, minVersion= 12.0, MaxVersion=12.0, and Firefox version= 13.0
b. yum won't run as I always get a repository XML file error.
c. putty runs fine on my support system as a SSH terminal.
d. The provided music player fails to make sounds running ogg files. I see the player clock increase
but no sound out of Raspberry Pi. Ogg files work fine on my Fedora 17 support system which is a
64 bit laptop. I assume that Raspberry Pi has a kernel problem.
e. Can't try mp3 files as yum fails trying to install gstreamer-plugins-good, bad etc.
f. Many MMC0: Note - Long write sync problems.
g. Many MMC0: Too large timeout requested for CMD038!
The swap file is required to run. I had a horrible time until I installed it. I believe the SD card performance is rather poor. I may try running from a USB 3.0 stick or USB 3.0 hard disk to see if
it would be better. I don't yet know if the Raspberry Pi I/O bus on the SD card is the actual
bottleneck. I haven't yet figured out how to use the Fedora Arm Koji system to get updated code
and possibly the yum updates for all the code the is ready. (arm.koji.fedoraproject.org)
Re: Fedora 17 ARM
"yum clean all" or "rm -rf /var/cache/yum/*"
Then "yum update"
Z.
Then "yum update"
Z.
Re: Fedora 17 ARM
The following nightly build just loops on starting display manager, display manager started, but it never actually starts the display.
f17arm-latest-arm-rpi-xfce-mmcblk0.img.xz 15-Jun-2012 04:04 573M
An earlier build worked much better
f17arm-20120613-230701-arm-rpi-xfce-mmcblk0.img.xz 14-Jun-2012 08:31 894M
f17arm-latest-arm-rpi-xfce-mmcblk0.img.xz 15-Jun-2012 04:04 573M
An earlier build worked much better
f17arm-20120613-230701-arm-rpi-xfce-mmcblk0.img.xz 14-Jun-2012 08:31 894M