Many thanks for the 3.xx kernel & rootfs! This looks like it will allow me to make better use of the 3 oxnas pogoplug classics I've had for a long time (running 'Arch).

I run them via sataboot. This is mainly because two of my 'pogos have too many bad mtd blocks & it's just not worth running multiple configs when I can run just one across all three.

I'm using the U-Boot: 2013.10-ga72eb8f-dirty - it works fine for what I'm doing. Once I figured out the proper uboot env settings I got a booting system.

I've been running the 3.17 kernel & rootfs for a few days now. The only big issue I've encountered so far: can't mount fat filesystems. Historically & by default, the codepage for FAT is 437. It appears your current 3.17 oxnas kernel doesn't really support that codepage. For example:

CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set

So, I believe codepage 437 doesn't get built (I *think* this would be the module nls_cp437.ko). So, no way to mount FAT partitions or thumbdrives with the 3.17 kernel & rootfs as released. :^(

I see you include the headers with your kernel releases. Any possibility of releasing a full kernel source snapshot too? I don't have a problem building my own kernels or modules (actually, I prefer it).

PS: to be sure, I made and tested image files (uImage, uInitrd, etc) from the boot dir in the 3.17 rootfs and from your most recent 3.17 kernel update release. Same issue with codepage 437 in both.

> I see you include the headers with your kernel
> releases. Any possibility of releasing a full
> kernel source snapshot too? I don't have a
> problem building my own kernels or modules
> (actually, I prefer it).
>

Thans for reporting this missing code page in config.

The kernel tarball (Updated 29 Oct 2014) has everything you need to build your own kernel: .config file and patch file. You can get the source form mainline kernel source tree and apply the patch on top of it, and then build with the .config file.

Hi all
i replaced the awful wifi card with an atheros based one..... installed the appropriate firmware.... THEN

the system thought it would be a fabulous idea to rebuild the headers/ regenerate the image and now i dont have access. The lack of access in itself isnt the issue.

What im curious to know is is this to be expected of this build or have i somehow baulked up the install commands.... im going to replace with a new root system and repeat, but wondered if anyone else had had issues when the system regenerates after installs.

Gravelrash Wrote:
-------------------------------------------------------
> Fairly certain i somehow baulked the installation
> - whether through copy and paste or some other
> mechanism.... the plug is now working - amazing
> what a fresh rootfs will do.....
>
> *looks sheepish and scratches head*

:) it does happen to all of us sometime.

Usually only when you insert modules or install something that results in new module(s) needed, then the initramfs is updated, and then uInitrd needed to be regenerated. vmlinuz is not updated with apt-get upgrade or apt-get install, so uImage does not need to be regenerated.

Any idea why mysql-server 5.5 won't load correctly from the repository with 3.17? It gets installed but doesn't allow you to set a new password and then the restart fails after first load. Purging and reinstalling doesn't work either. Wonder if anyone else has encountered this.

Could someone clarify what is the best way to get latest kernel and rootfs on a stock PogoPlug Pro? Do I install the new uBoot first or the kernel/rootfs? Is there an available Rescue Image for the oxnas based systems? Is it possible to boot from eSATA? Ideally I would like to have an accessable rescue system on NAND and Boot Debian from the eSATA port.

rayknight Wrote:
-------------------------------------------------------
> Could someone clarify what is the best way to get
> latest kernel and rootfs on a stock PogoPlug Pro?
> Do I install the new uBoot first or the
> kernel/rootfs? Is there an available Rescue Image
> for the oxnas based systems? Is it possible to
> boot from eSATA? Ideally I would like to have an
> accessable rescue system on NAND and Boot Debian
> from the eSATA port.
>
> Thanks
> Ray

The more I play around with Oxnas Pogoplugs, having completely bricked one I picked up for $9 last night, the more I am thinking they just are too hard to reimage and setup. And the built-in wireless defies all attempts to get it working without replacing the mPCI-e card to Atheros or something else.

It's actually a shame considering the potential capabilities of the device as what other similar device with dual core processor, Gigabit ethernet, built-in mPCI-e w/wifi, built-in RAM, built in 4 port hub, case and power supply can be had for $15 shipped new? They even throw in a 6 foot cat 5 patch cable. I can't think of anything else, can you?

It's been stated elsewhere, I'll repeat it with regret, you probably should just buy a Kirkwood and your life will be alot happier.

It is best that you have serial console connected first. But you can do without it, but be carefull.

If you intend to install both new u-boot and rootfs then it is best to install both at the same time: prepare rootfs on USB stick, and then install new u-boot, and setup netconsole right away (if you don't have serial console connected), reboot with the new rootfs.

There is no rescue image available. But once you've installed new u-boot, set up netconsole right away as a rescue means

It is possible to boot from eSATA. But you will have to try to know whether the eSata enclosure you use will work. Boot with USB rootfs first to get it working. Then put the rootfs on the SATA drive and try it.

The Debian rootfs won't work with the u-boot and kernel setup by the above Arch installation. You will have to try:

1. Recreate a fresh Arch rootfs just like one of the steps you did in that installation. And try booting with it. Do this entire step on another Linux box, while logging in a root user (not using sudo). And sync a few times to make sure the rootfs was saved correctly.

bodhi Wrote:
-------------------------------------------------------
> @LeggoMyEggo,
>
> > And the built-in
> > wireless defies all attempts to get it working
> > without replacing the mPCI-e card to Atheros or
> > something else.
>
> I hope that this might be possible to fix once I
> got time to look at it.
>
> > It's been stated elsewhere, I'll repeat it with
> regret, you probably should just buy a Kirkwood
> and your life will be alot happier.
>
> I understand the frustration, but that's probably
> not a good recommendation if Ray already bought
> it, is it? :)

I appreciate your work on this, if it weren't for your constant effort updating the rootfs' I think alot of the Oxnas PP would have ended up in the landfill. My frustration is born out of the feeling of being so close to having a fully working device but with the knowledge of all the issues (especially with the Oxnas CPU itself) which prevent fruition of stable functionality. I think we will get there but looking back at all the effort people here and at Arch have put into making these devices stable, well it's been a long and rough road.

1. On Ubuntu, use netcat traditional. If not sure, post the man page of that nc command.

2. Where 192.168.x.xxx is the ip address of the plug (u-boot env ipaddr). The command should be:

nc -lup 6666 192.168.x.xxx 6666

The LED pattern indicates that the kernel image could not been loaded (blinking green and then blinking orange). Blinking green means it was reset to start loading. And finally stays orange means the error could not been overcome with reset, so u-boot stopped.

If you have kept the log of the installation, pls post here (the entire log).