Hi. I've been looking for a way to get a very power efficient, but
still full featured Fedora server for a while, and the recent influx
of "plug computers" finally provides the answer. Long story short, I
ended up snagging a Pogoplug Pro on sale at Micro Center for $50,
before I learned that the Pro is NOT derived from the Kirkwood
reference design, but is a completely different architecture called
OXNAS from Oxford Semiconductor/PLX. As far as my googling can tell,
the recent "black" generation of Pogoplug hardware seems to be the
only product in the world using the OXNAS 820 SoC right now. It looks
like the WD MyBook uses/used an earlier OXNAS 810 chipset.
It is also "cost reduced" from earlier Pogoplugs, having only 128mb
RAM and 128mb of flash. Its a bit slower at 700mhz but is somewhat
compensated for by being dual-core. On the up side, there is in fact a
SATA port hidden inside the Pogoplug Pro. It also has some interesting
features like TCP offload and supposedly an encryption engine. (but I
haven't seen any sign of support for the encryption engine in the
Cloud Engines source so far) There's also a mini-PCIe slot containing
the Pro's wireless card.
Anyway, I managed to get Fedora 13 beta3 running on it by first
installing PlugApps on it, then I just swapped in a Fedora root FS:
Make sure to copy /lib/modules and /usr/local over from the PlugApps
FS. The network driver is compiled as a module, and it will not auto
load. Especially if you don't have a serial console set up, before
booting you'll need to pop in a script at
exec /sbin/modprobe gmac >/dev/null 2>&1
Make sure it is chmod 755
Also the driver wants firmware for the TCP offload, and seems to have
a bug where it will just lock up the system if it can't find it.
You'll find it at /lib/modules/220.127.116.11_SMP_820/gmac_copro_firmware ,
just move it to /lib/firmware/ and you should have working ethernet.
There's some weirdness with the MAC address, the driver just sets it
to a hardwired default of "00:30:E0:00:00:00" as there does not seem
to be in-kernel infrastructure to read uboot variables. The PlugApps
install script writes the MAC into /usr/local/mac_addr and the network
scripts change it before bringing the interface up. I don't understand
why they don't just read it directly from NVRAM using
/usr/local/cloudengines/bin/blparam . But currently my Pogoplug Pro is
just using the default MAC. Setting the MAC properly should be a
simple matter of scripting...
Unfortunately the PlugApps kernel is very minimal. It does not have
any NFS server support enabled, and for some reason ext4 is compiled
as a module, so your root FS has to be ext2 or ext3.
I managed to successfully compile the Cloud Engines kernel source and
write it to flash just past the original PlugApps kernel, so the
original PlugApps kernel and even the stock Pogoplug OS can still be
booted in a pinch using the uboot console. (But I may have overwritten
a backup Pogoplug kernel...)
If you do not have a serial console set up, do NOT mess with the
flash! If you screw up the boot sequence, there is no way to un-brick
these things without one. There is NO "reset nvram to defaults"
I'd really like to run btrfs on this, but the stock kernel is 2.6.31,
and my research indicates you want at least 2.6.33 for stable btrfs.
Also, support for the wireless card was merged in 2.6.34. I have
successfully upgraded the kernel through the incredibly awkward and
time consuming (but educational) method of applying the Cloud Engines
changes to 2.6.31 in a git branch, then rebasing 2.6.32 on top of it.
So my Pogoplug Pro has been running 2.6.32 for the last few months
with no problem. I'll see about pushing forward further once I have
some time to kill. (Pretty much takes a full day for my old secondary
laptop to chew through the whole rebase...)
So now I have my Pogoplug Pro working nicely as a Samba server for my
windows machines, and a NFS4 server for my Fedora machines.
I originally wanted to run a MythTV backend on it, but that may be
pushing it a bit with only 128mb RAM. Not to mention the fun of
getting MythTV compiled for Fedora arm in the first place...
I'm using F12 pre-built rootfs on TI's AM3517 board.
I noticed that I am unable to add a user or a group which has uppercase
letters in it's name.
For example, I am able to add a user named "test" with "useradd test" but
am not able to add "Test" with "useradd Test".
I was wondering if useradd was compiled with some specific patch since the
shadow source code does not seem to have any such condition.
Also, I am able to add "Test" user or group on Fedora 14 on x86 arch,
Any help on this would be appreciated.
I was inspired by djdelorie's pretty colours stats page and I wanted to try and copy it (you know what they say about imitation!). Anyway, it's still a work in process but here it is below: <br />
Thanks for reading,
On Tue, Nov 15, 2011 at 5:10 PM, Alexander Graf <agraf(a)suse.de> wrote:
> Hi guys,
> We are currently slightly stuck in getting GNU Java to work properly on our
> ARM (hf) builds. Something breaks in the unrolling of exceptions.
> IIUC Fedora already managed to get Java running and I don't want to waste
> too much time in duplicated efforts.
> We found some patches that looked like they might be related here:
> http://djdelorie.fedorapeople.org/armv7-srpms.html (gcc pkg)
> but couldn't find the source rpms to the respective info. Are these related
> / required? Does anyone have some insight in what exactly you have been
Source packages for the java bits that will end up in mainline can be
found here http://aph.fedorapeople.org/
Not sure of the exact details of the fixes, there's a matching email
in the fedora arm mailing list (search openjdk in the archives).
so we have all the tags setup in koji, f15 is completely disconnected
from f14 and f13. we have an external repo setup.
while we dont need the sfp and hfp repos to be exactly the same. koji
does track the packages used in buildroots, and if the nvra is the same
it does expect that the checksums are all exactly the same. koji has
tracked the perl noarch rpms from the hfp repo and wont init a chroot
for armv5tel since there is some perl noarch subpackages that while the
same nvr are different due to being built for either hfp or sfp. so to
resolve this ive removed the symlink into mojis repos,
cp -rl ../f15v5.0/repo/ arm/
rm -rf arm/mock.perl-5.12.4-160.fc15/*noarch.rpm
cp -rl armhfp/perl-5.12.4-160.fc15/*noarch.rpm
createrepo -d arm/
i then did a "arm-koji regen-repo dist-f15-build"
There was some dialog on IRC recently about compile flags. As near as I
can see it, we ought to be consistent in r-r-c between v5 and v7. Did I
miss something in particular? Just tying up some loose ends here.
This week's VFAD was beneficial, but we need to keep momentum as we head
toward final builds in Koji of Fedora 15. Therefore, I believe it is
essential to the effort that we hold a weekly VFAD until we're done.
I propose Monday Nov. 21st at 11am Eastern. Before then, we will compile
a mini-report of current status and a hotlist of blockers to Koji.
Hello fedora arm list.
We are looking for help and ideas to open development of our network
block device driver.
We think it is the perfect match for small arm based systems to increase
storage and we would also like to integrate it into a sheevaplug based
product that we can market in the future.
Amahi with Fedora looks like the smoothest combination so far.
Please send links to Open development licenses, other than GNU because I
am not sure that our current plan is for that much open license.
Basically we plan co-develop with everyone, but remain the sole
distributor of the final product.
We need much advice at this time actually.
There is a public announcement here: http://linux.iocellnetworks.com.
Thanks for your consideration.
I propose a VFAD to clean up and reconcile armv5tel/armv7hl pre-koji
package sets and prep for koji startup:
When: Nov 14 - 11:00 am EST / 8:00 am PST / 15:00 UTC
What: armv5tel-armv7hl package set reconcilliation, koji prep
You us if you can, mail the list with any issues/info if you can't make