Fedora ARM on Raspberry Pi

Why not use a "date" command in /etc/rc.local that forces the initial system date to something nearer reality? This will take effect before you get to log in and set a new password?

Z

It now appears that there is an underlying issue with installing the distro on the Pi itself, not just loading it into Qemu. Farnell have withdrawn the download after testing it on a real Pi.

http://www.raspberrypi.org/for.....-from-site

Chris Rowland said:

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

QEMU actually emulates an RTC, and sets it to the correct time by default.  So if you use a kernel with rtc-pl031 driver compiled in you will get the right date with or without a network.  Modulo the fact that the remix's timezone selection is also broken.

But the more serious issue is as you say that the real Pi does not have an RTC, and a lack of network there will cause the same fault.

After some extensive hacking over the last few days I'm in a happy place:

1. Qemu with networking.

2. So no instant password aging & I was fortuneate enough to be aware that I was being warned about insecure passwords.

3. chmod on tmp.

4. Disable the xscreensaver so it can't lock me out by ignoring the keyboard

5. 800 x 600 display

6. And some other things I've forgotten (which is why the notes aren't published yet).

Overall it does work but it does suffer from Fedora std bloat on disk space and it doesn't feel as snappy as the Debian release.

There is definitely some work to be done but that's sort of what we are here for, us pioneers!

[texy]

....so please let us know how, especially the 800 x 600 display.
Texy

jojopi said:

Chris Rowland said:

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

QEMU actually emulates an RTC, and sets it to the correct time by default.  So if you use a kernel with rtc-pl031 driver compiled in you will get the right date with or without a network.  Modulo the fact that the remix's timezone selection is also broken.

But the more serious issue is as you say that the real Pi does not have an RTC, and a lack of network there will cause the same fault.

I've read the instructions and found the-rtc [base=utc|localtime|date][,clock=host|vm [,driftfix=none|slew]

command but don't know where to go from there, even after some experimenting. Searching for pl031 gets back to this thread.  Does "use a kernel" mean a different kernel program to "zImage_3.1.9" which is what I'm using and there's one with a working RTC?

I tried setting up a bridge to the network but it although it seemed to have worked the time wasn't updated and the internet doesn't work.

All this with Debian, if I can get this going I'll substitute the Fedora remix in the command line and try it.

zardoz99 said:

Why not use a "date" command in /etc/rc.local that forces the initial system date to something nearer reality? This will take effect before you get to log in and set a new password?

Z

If you do this, you could never start the system in a "headless" configuration, without a monitor or keyboard. With the normal configuration, you could start it headless, with a network connection, and then log into it via ssh.

800x600 is the only thing defeating me at the mo. I"m getting ready to have a go at crosscompiling SDL MESS for the raspi as I have it running just fine on my Laptop Fedora - anyone else want to run their raspi as a BBC Micro?

800x600 is something I've solved with the Debian img using an xorg.conf file as described elsewhere.

I've tried the TAP way to set up a network, it gives the impression it's working but there's no communication. Not sure how to progress.

This is using W7 64 bits as a host system.

rpural said:

If you do this, you could never start the system in a "headless" configuration, without a monitor or keyboard. With the normal configuration, you could start it headless, with a network connection, and then log into it via ssh.

I'm more than a little curious how you come to that particular conclusion...

Z.

rpural said:

If you do this, you could never start the system in a "headless" configuration, without a monitor or keyboard. With the normal configuration, you could start it headless, with a network connection, and then log into it via ssh.

I"m more than a little curious how you come to that particular conclusion...

Z.

If you have the system boot stop to allow you to enter a date, and you have no display or keyboard, how do you suppose the system is going to get past the prompt to get to a point where you could log in?

Ah, I suspected that might be your logic.

It was, however, not what I had in mind at all.

What I am suggesting is something that forces the date on the R-Pi to any non-epoch date, so that things like password management do not break. There are lots of clever ways of doing this, such as extracting the last write date in the SD card filesystem superblock and feeding the result into "date" as a earliest possible system date.

However the following would work just fine as a starting point as a line in /etc/rc.local

date -s "2012/02/29 06:00:00"

Z.

zardoz99 said:

However the following would work just fine as a starting point as a line in /etc/rc.local

date -s "2012/02/29 06:00:00"

Z.

So a "date of least known antiquity". That would work.... Thanks for clarifying.

Explains why I have /etc/rc.d/fakeclock in my (arch) /etc/rc.d, for the times when network / ntpd is unavailable, no doubt easily translatable to other distros:

#!/bin/bash

daemon_name=fakeclock

. /etc/rc.conf
. /etc/rc.d/functions

case "$1" in
start)
stat_busy "Starting $daemon_name"
now=$(date +%s)
log=$(stat -c %Y /var/log/everything.log)
[ $log  -gt $now ] && date -s @${log} > /tmp/clk.log
stat_done
;;

stop)
stat_busy "Stopping $daemon_name"
stat_done
;;
esac
exit 0

spennig said:

Explains why I have /etc/rc.d/fakeclock in my (arch) /etc/rc.d, for the times when network / ntpd is unavailable, no doubt easily translatable to other distros:

My "first blush" attempt at this (not having a Ras-Pi handy to try it on):

ckantiquity.pl:

#!/usr/bin/perl

#  Check the current date against /var/log/messages, and if older, set
#  it to the one on /var/log/messages

my $msgsDate;
my $ls = `ls -l --time-style=+%Y%m%d-%H%M%S /var/log/messages`;
#  -rw-------. 1 root root 56498538 20120321-125826 /var/log/messages */
if ($ls =~ m/\s(\d+-\d+)\s/) {
$msgsDate = $1;
} else {
printf "Could not find /var/log/messages\n";
exit 1;
}

my $date = `date +%Y%m%d-%H%M%S`;
chomp $date;

if ($date gt $msgsDate) {
printf "$date is fine. Leave it be.\n";
} else {
printf "Set date to $msgsDate.\n";
`date -s $msgsDate +%Y%m%d-%H%M%S`;

}

I must be doing somethign wrong, whenever I try to change the time, I get a fibre light display pop up.

@ Chris Tyler or Liam Fraser

Do either of you know what version of Python is/will be included by default?

Also if Pygame is there (And what version) and Geany IDE?

Plus... Has it been tested to see that the sound works?

Without knowing these things, it's hard for me to progress with writing my Python tutorials.

I want to base my stuff on the packages that come by default with your Fedora spin.  I don't want to have to explain to my students how to connect up to the internet and use package manager to update these things.  I'm assuming that some of them won't have that option / will be running offline using a pre-prepared SD card.

[texy]

Pre-prepare the card yourself do you know which version is on the sd card? Other than that, knowing how to update or install packages is usefull for the students to know. In fact Liam goes through that in the first python tutorial.
T.

Can Anyone say how the networking capabilities of the arm/fedora are?

Thanks

texy said:

Pre-prepare the card yourself do you know which version is on the sd card? Other than that, knowing how to update or install packages is usefull for the students to know. In fact Liam goes through that in the first python tutorial.
T.

I was hoping not to have to buy, build, sell and distribute SD cards myself.  If I'm going down that route, I think I will need to put together a team of volunteers.  I don't want there to be a necessity to have an internet connection though.  My project is to teach beginners to program in Python.  I'm not really interested in teaching them how to set up an internet connection, put an OS onto the SD card, install device drivers or download the Python, Pygame and IDE packages.  I'll leave all that as a project for someone else.

Here's my plan for those who want to follow my tutorials:

1. Buy a Raspberry Pi, Power Supply, HDMI Cable, Keyboard & Mouse, Monitor or TV.

2. Buy a pre-prepared Fedora SD card with Python, Pygame and Geany (Or other IDE).

3. Get hold of a copy of my tutorials (Either printed or downloaded).

4. Start learning.

Farnell pulled the link to the Fedora image.  What are the issues? Is Fedora usable at  all? Should we wait untill a new image is available?

Does Fedora have native floating point support for the Raspberry Pi.

Thanks,

Liberty

As far as I can tell, the Fedora image is a little trickier to work with and requires maybe more knowledge than the other offerings.

Having said that, I have it working perfectly now under QEMU with full development/networking/X11.

Liberty said:

Farnell pulled the link to the Fedora image.  What are the issues? Is Fedora usable at  all? Should we wait untill a new image is available?

I think the issue was that the initial Fedora boot requests that you change the account's passwords, and if you aren't connected to a network, the clock has not been set, so the time of the password change is way in the past. As soon as the clock is set, the passwords are expired, and you can no longer log in.

Hence, the discussion of how to set the date to a "least elderly value" during a boot without a network connection.

If I'm mistaken, please, someone correct me.

rpural said:

I think the issue was that the initial Fedora boot requests that you change the account's passwords, and if you aren't connected to a network, the clock has not been set, so the time of the password change is way in the past. As soon as the clock is set, the passwords are expired, and you can no longer log in.

It is more subtle than that.  Passwords in fedora never expire by default.

Shadow-utils uses a password date of 0 (1970-01-01) as a special value to mean "password must be changed at next login"; this is only intended to be set explicitly by the system administrator.  But 1970-01-01 is also the default date when there is no RTC or network.  So until the clock is set (to 1970-01-02 or later) you have to re-change your password at every login.

You can get into exactly the same situation in the debian reference image if you boot without network and then change any password.

Farnell may have found other problems running the remix on a RasPi, but the network/date/password issue is the only show-stopper that I have noticed in QEMU.

The other problem I saw was that the GUI didn't seem to get any keyboard input.