Fedora ARM on Raspberry Pi

RorschachUK said:

flyerblade said:

btw. If anyone comes up with an easy way to do the installation on a Mac, I"d be interested.

Yes - ignore the installers, none of them are for Mac.  Get instead the image file, by direct download or by torrent - since this still hasn't appeared on the Downloads page I had to grab it from one of the mirrors, here: http://ftp.snt.utwente.nl/pub/.....6-03-2012/

Once you've got the file raspberrypi-fedora-remix-14-r1.img.gz onto your Mac, you can move it to your desktop and doubleclick it to unzip it to the actual image file which is called raspberrypi-fedora-remix-14-r1.img.

Now open a command prompt.  We need to figure out which disk device at the BSD Unix level is our SD card.  So, with your SD card reader NOT inserted, type 'diskutil list' in the command prompt window, it'll probably list one or two disk entries and the partitions on it.  Now insert your SD card into your USB card reader and insert that into your Mac, and wait a few moments till the system's mounted the SD card and you can see it pop up as a drive.  In the command prompt window, type 'diskutil list' again - it should be obvious from comparing the two that there's a new entry, for me it was /dev/disk2 (because disk0 was my internal HD and disk1 was my external Firewire drive) - but, depending on your arrangement of disks, you ought to be able to tell which /dev/disk{n} is your SD card, it should also be reporting the right capacity for your SD card, say it's got an FDisk partition scheme and FAT32 partition.

So, having worked out which /dev/disk is your SD card (and for the remainder of this let's say it's /dev/disk2 like mine, but substitute your own correct disk number as determined above):

Type in the command prompt 'diskutil unmountdisk /dev/disk2'

- this unmounts the partition from OS X but still leaves the underlying BSD able to see the disk device.

Change directory to your desktop, where we're storing that disk image - type 'cd Desktop'.  You can check you're in the right directory and can see the disk image by typing 'ls' to list the directory contents - should see that raspberrypi-fedora-remix-14-r1.img file in amongst the other stuff from your desktop.

Now we're going to blast the contents of the image file onto the SD card.  This is pretty slow and doesn't look like it's doing anything, but don't worry.  Don't forget to substitute the right disk number, and type 'dd if=raspberrypi-fedora-remix-14-r1.img of=/dev/disk2'

Now wait several minutes for dd to finish.  If you need convincing that it's doing something, you can press Ctrl-T to cause it to spit out some text about how many bytes it's done so far.

When it eventually finishes, type 'sync' to make sure it's written everything, and then 'diskutil unmount /dev/disk2' to unmount the whole of the disk, and then unplug it and plug it in again.

This time when the disk mounts it should have a FAT32 partition with a kernel and some configuration files, and a big Linux partition ready for when you put it in a Raspberry Pi.  Job done!

flyerblade said:

RorschachUK, you're a star - thanks for that. Excellent

Slightly curious as to if it can be done in Disk Utility - Restore but it's not important. I suspect not as that seems to restore to an existing partition.

Thanks in advance

I have some time before my RPi gets shipped and I would like to start playing with Fedora in a virtual environment.  What would you guys recommend as far as version to download and install on a virtual machine running 256 megs of ram?

I'm concerned that the Fedora Remix might not perform up to the full potential of the Raspberry Pi's ARMv6 processor.

jojopi said here that the Fedora Remix packages are currently not compiled for ARMv6 with hardfloat support.  If this is true, then why not?

There was an interesting note in the Seneca video that the Fedora remix does not support the Pi GPU yet.

If this is still true, is there anything the user community can do to help in this process?

I understand Broadcom released a hardfloat version of the interface libraries.

More precisely, X11 isn't accelerated by the R-Pi's GPU yet.  That's the same across all distros.

The graphics libraries available work outside X11.  You have to write an application specifically to use them.  It might be possible to adapt X11 to work on top of them, which would help more ordinary applications.

esbeeb said:

I'm concerned that the Fedora Remix might not perform up to the full potential of the Raspberry Pi's ARMv6 processor.

jojopi said here that the Fedora Remix packages are currently not compiled for ARMv6 with hardfloat support.  If this is true, then why not?

I had also read in the forums some time ago that they considered building it for ARMv6 with hardfloat. The most obvious reason I can think of why they did not do it, is that they would have had to support 2 different binary repositories one for ARMv5 and for ARMv6+FPU and above.

The current ARMv5 binaries can be used by all ARM platform (ARMv5 and greater), they are not only for the Pi.

Bummer, I wrote up a long and detailed post about the compiler options and ABIs and FPUs and thumb and all, and then the forum software ate it   ... the JavaScript liked my arithmetic captcha answer but the server rejected it and discarded the text.

I don't have the energy to write it all again this late at night, but I will post about this in the next few days.

Better write it in your word processor first; copy and paste.

Golem said:

Better write it in your word processor first; copy and paste.

or write it here but do ctrl+a, copy before submitting the post so you can paste it again if it fails

I notice that the 2GB Debian image just about fills 2GB on an SD card but the Fedora image, which is 3.9GB, still only takes up 2GB on a card. Where did the other 1.9GB go?

Where did you get 3.9GB from?

1726468 -rw-rw-r--.   1 kelvin kelvin 1767899136 Mar 12 14:06 raspberrypi-fedora-remix-14-r1.img

Ah. I see now. Because I loaded my Fedora image into Qemu, it has now expanded to 3.9GB as part of the initial setup. The other images stay at 2GB, even after you have loaded them into Qemu.

Grumpyoldgit said:

Ah. I see now. Because I loaded my Fedora image into Qemu, it has now expanded to 3.9GB as part of the initial setup. The other images stay at 2GB, even after you have loaded them into Qemu.

It is impossible for anything running inside qemu to make the image file bigger -- that would be like running software to increase the size of your hard disk.  And although the remix attempts to resize the partition and filesystem on first boot, this will fail in qemu due to the device names being different.  (Unless you manage to get qemu to emulate an MMC card reader instead of a SCSI or ATA hard disk.)

If you want to have any free space at all in the remix in qemu you will need to manually resize the image, partition, and filesystem using commands like those I posted on page 12.  I believe that you have at least partially attempted this, which is why your image has grown, but your partition and filesystem may not have.

I got as far as the gui login screen screen late one night but eventually gave up when I just couldn't get in. I had to kill Qemu a couple of times when I got locked in a change password loop. The image is now 3.9GB so maybe it is a little trashed inside. I will be scrubbing it and starting again as I see that several people have managed to get in and have produced some helpful notes. I did start on some notes so that might be it.

Chris, if you're monitoring this thread, the mirror list server for installer & yum at scotland.proximity.on.ca is offline.

nmcc said:

Chris, if you're monitoring this thread, the mirror list server for installer & yum at scotland.proximity.on.ca is offline.

I'm offsite but there have apparently been some pretty disruptive power issues down there today. I think we're back online now, sorry for the problems.

Grumpyoldgit said:

I notice that the 2GB Debian image just about fills 2GB on an SD card but the Fedora image, which is 3.9GB, still only takes up 2GB on a card. Where did the other 1.9GB go?

3.9G? It's a 1.6G image...

Chris Tyler said:

nmcc said:

Chris, if you're monitoring this thread, the mirror list server for installer & yum at scotland.proximity.on.ca is offline.

I'm offsite but there have apparently been some pretty disruptive power issues down there today. I think we're back online now, sorry for the problems.

Yup, back on line - playing nicely with all my VM's again! Thanks.

I am pretty certain that the inability to login to the gui is because X is not seeing the keyboard. This in turn is because udev is not working properly. I can make it work if I struggle at it but it's a real nuisance. Not exactly what we need to get beginners started.

When I get time to test and document the get-round, I'll post it here.

I got into Fedora using qemu on an XP PC but the broken security make it impossible to use.  It left me in a cycle of having to provide a password and everything I chose was not acceptable.

So I gave up.

I will try Fedora again when it is less user hostile.

This sort of thing does not enhance security. It encourages passwords on postit notes.

Chris Rowland said:

I will try Fedora again when it is less user hostile.
This sort of thing does not enhance security.

You have jumped to the wrong conclusion.  It is not user hostile, and it is not intended to enhance security.  It is simply not working as intended due to a bug.

If you get networking to work on the first boot then you can happily set a password of "123" and will never need to change it; even if the network is broken on later boots.

And, by the way, the same bug applies to the debian reference distro also.  Boot it without network and change the user's password.  Now try to log in again.  Oops!

(The problem occurs if you change any password while the date is 1970-01-01 (UTC).  1970-01-02 or later is fine.)

I think the problem is that most people seem to find setting up Debian a doddle by comparison. There was a bit of a learning curve as I had not used Qemu before but after you got me through a couple of glitches over the Qemu version and the kernel it was plain sailing. People are spending days on Fedora and seemingly not getting very far.

Grumpyoldgit said:

I think the problem is that most people seem to find setting up Debian a doddle by comparison. There was a bit of a learning curve as I had not used Qemu before but after you got me through a couple of glitches over the Qemu version and the kernel it was plain sailing. People are spending days on Fedora and seemingly not getting very far.

Most definitely agree - it's definitely not a hardened release.  To be fair to them, we are using an emulator, not something that was necessarily intended to be supported - it's just the fact that Debian is so stable that is making Fedora appear unstable.

To be fair, it may just be the emulation that is the problem, though it has been said that the Fedora mix performance is plodding by comparison with Debian and Arch.

Nothing was said about a lack of date, it was all about password problems.  It's good to hear that it's a bug not a feature - that make it more likely to get fixed.  It had accepted one user name and password, then when I tried to run the GUI it insisted in changing the password I'd just set.  This time instead of just complaining about an insecure password it refused to accept it.

A system that's this sensitive to the date is likely to have trouble with a system with no RTC and no expectation that it must be connected to the internet.

I don't suppose there is some way to pass the current date in on the QEMU command line?

I'm afraid that User Hostile was how it felt to me, after a number of attempts to set an acceptable password that failed and with no indication of what constituted a valid password.

The Debian img file was no problem, it installed and ran. I was even able to change the screen resolution. It didn't ask me to change the password so I didn't; after all a system that's not networked isn't at much risk of being hacked into.