Booting Debian on Pogoplug Pro

This sounds that you use the normal 2.6.31.6 Kernel of WarheadsSE. I am providing a bit newer kernel which solves some drawbacks of WarheadsSE Kernel which I had with FTDI Interfaces, PC/SC Cardreaders and USB Sound Cards). This kernel is based on telzeys patches (ALARM Forum) and configured similar to WarheadsSEs Kernel expect PPP and packet readio which I had to disable.

http://www.pogoplug.cwsurf.de/forum/viewtopic.php?style=9&f=5&t=98#p428

This kernel will not prevent the libaccept4 issue but could solve some problems.



Edited 1 time(s). Last edit at 08/01/2013 02:27PM by shv.

@shv: Thanks for pointing this out.

Is there a reason why you went again for 2.6.31.x instead of one of the longterm-supported kernels (2.6.32.61 or 2.6.34.14)?

It belongs to the availability of OXNAS patches for this kernel.

You can get them from there: http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2472&start=10#p15007



Edited 1 time(s). Last edit at 07/31/2013 09:18AM by shv.

@kuleszdl:

I got Wheezy working. I had some problem with the ethernet but this was caused by a wrong MAC address.



Edited 2 time(s). Last edit at 08/01/2013 05:23PM by shv.

@shv: Well, that great! Welcome in the club. :)

Did you build the userland from scratch via debootstrap (like me) or did you update your existing userland with an approach like bodhi did?

I built the userland from scratch via doozan skript with Pogoplug E02 which means dbootstrap. Afterwards I used the procedure in the first message of this thread to make it ready for Pogoplug Pro and added the libaccept4.so and preload configuration.

I get FAIL messages 2 time at the end of the system startup:

[ ok ] Cleaning up temporary files....
[....] startpar: service(s) returned failure: checkroot-bootclean.sh procps netw[FAILg ... failed!
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.
[ ok ] Starting OpenBSD Secure Shell server: sshd.
GREEN
[FAIL] startpar: service(s) returned failure: ssh rc.local ... failed!

It seams that rc.local is stopped after the execution of the line

/sbin/proled green

with the FAIL message even proled is available and the LED is lighted up.



Edited 4 time(s). Last edit at 08/02/2013 01:31AM by shv.

@shv ,

> It seams that rc.local is stopped after the
> execution of the line
>

> /sbin/proled green
>

> with the FAIL message even proled is available and
> the LED is lighted up.

It might be that because devmem was not loaded before proled.

The rc.local FAIL was caused by the return value of proled. The following replacement solved this:

/sbin/proled green > /dev/nul

Now it is still necessary to find the reason for the other FAIL message.



Edited 1 time(s). Last edit at 08/02/2013 03:00AM by shv.

@shv: For me it works without the > /dev/null

You probably inserted the line after "exit 0" in rc.local, didn't you?

If I am not mistaking, the udev problem could be solved by porting OXNAS support to kernel version 2.6.32, right?

If that is correct, I might try to do that. With the emphasis on "try", because I never did something comparable before. But, as 2.6.31-14 to 2.6.32-61 doesn't necessarily seem like a HUGE step, it might be possible.

What's your opinion? I just think that it is highly impractical to have a kernel that needs such hacks to work properly with the current stable Debian release.

kuleszdl Wrote:
-------------------------------------------------------
> @shv: For me it works without the > /dev/null
>
> You probably inserted the line after "exit 0" in
> rc.local, didn't you?

No it is before "exit 0". I get these FAIL messages in the seriell console. Did you check this also with the seriell console?

Just tried the dist-upgrade from Squeeze. This is also possible. I added the preload of libaccept4 already in Squeeze and did the dist-upgrade afterwards. I've got the question whether to upgrade udev and answered yes. The FAIL messages are also there.

@ingmar_k: It would be nice if you could try to provide us a compatible kernel. It would make things much easier.



Edited 1 time(s). Last edit at 08/02/2013 06:54AM by shv.

@shv: No I',m not getting any of these "fail" messages.I looked in dmesg, syslog and log/messages, is there supposed to be something extra on the serial console only?

And yes, 2.6.31 -> 2.6.32 is probably a much smaller step than to 3.x and probably worth a try. I would even expect most of the oxnas patches to be directly applicable to a clean 2.6.32 source, but I don't have that much time to try myself so I hope ingmar_k will try to tackle this. :) But well, personally I can live with the libaccept4 workaround, it's not such a bad hack.

kuleszdl Wrote:
-------------------------------------------------------
> @shv: No I',m not getting any of these "fail"
> messages.I looked in dmesg, syslog and
> log/messages, is there supposed to be something
> extra on the serial console only?

Serial console gives you lot of output, some problem can't be solved without serial console. Output such as in shv's post are console output only.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 08/02/2013 04:03PM by bodhi.

And there is no way of redirecting them elsewhere? I'm not willing to do the soldering job to get the serial port up and running.... and so far, the Pogo seems to run wheezy just fine for me.

There is no other way other than JTAG (i.e. hardware to get the console output). With this Pogo, you don't need to do any soldering. The JST header would be all you need to connect the wires out to serial converter module.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

ingmar_k Wrote:
-------------------------------------------------------
> If I am not mistaking, the udev problem could be
> solved by porting OXNAS support to kernel version
> 2.6.32, right?
>
> If that is correct, I might try to do that. With
> the emphasis on "try", because I never did
> something comparable before. But, as 2.6.31-14 to
> 2.6.32-61 doesn't necessarily seem like a HUGE
> step, it might be possible.
>
> What's your opinion? I just think that it is
> highly impractical to have a kernel that needs
> such hacks to work properly with the current
> stable Debian release.

I like this idea a lot :)

Of the 26 patches that were orignally published by telzey for 2.6.31-14, 12 could be directly used for kernel 2.6.32.61, while 14 of them will need extra care. Will see what I can do. I guess that about one third of these 14 patches are obsolete for 2.6.32.61 anyway. Should leave about 10 patches that need work.
Hope it is possible. Will keep you up-to-date.



Edited 2 time(s). Last edit at 08/03/2013 05:22AM by ingmar_k.

@ ingmar_k: Sounds promising, please keep us updated. If you encounter bigger issues with one of the patches please let us know.

By the way, the end of support for the 2.6.32 kernel has been already announced more than one year ago (May 2012), when 2.6.32.58 was released:

http://www.phoronix.com/scan.php?page=news_item&px=MTA2NjI

Actually, I can't find any concrete information about when this longterm kernel is going to be EOL'ed, and it seems like 2.6.32.61 was released in June 2013, so it still seems to be maintained. Anyways, moving to the 2.6.32 series would render our Pogos back to a supported kernel series for a while which would be a big improvement over the current situation with the pretty much outdated 2.6.31 kernel.

Maybe I'll start a git repo with the patched kernel sources. So other people with more experience could contribute and/or correct my faults. As I said, I am a total noob to kernel porting. What I am doing is mearly a little tinkering without much knowledge what is behind each patch.

Doesn't look too bad at the moment, though, I venture to say. :-\

Looking forward to that!

By the way, the 2.6.32 kernel is announced to be supported until mid of 2014:

https://www.kernel.org/releases.html

As you can see from this table, a target for the next feasible kernel would be 3.2, since support for 2.6.34 and 3.0 will end even before support for 2.6.32 will be dropped.

Well, well. First try and the compiled 2.6.32.61 kernel didn't even boot. :(
Would've been too easy, though. Will have to investigate the next few days, if I find the time.

That's bad luck. I've seen your repo on github, but where are the (altered) patches? Did you push them?

Not yet. At the moment it's just the vanilla kernel, without any patches. The plan was to only push the patched version, if it was at least booting.

Edit:
I will start over in a few days, applying each patch, step-by-step. And updating the git after each of the patches is applied. That should be a better approach than what I did now.



Edited 1 time(s). Last edit at 08/06/2013 04:45AM by ingmar_k.

Yes but I don't think it makes sense to push the patched sources to Github for future compatibility reasons. Instead, we probably want to alter the patches so they apply to the sources cleanly and the just do a normal build. Therefore, I would suggest making a folder "oxnas-patches" and putting the Warhead SE's original patches there. In the next commit, remove the patches which you consider obsolete since they are already part of 2.6.32. And in the next commits, include the modifications to the original patches so they apply to 2.6.32 ...

This way it should be both future-proof and easy to audit for others - and maybe we could spot something you missed when altering the patches easier.

Telzey provided an untested different patchset based on silverstorne source code in the following thread: http://archlinuxarm.org/forum/viewtopic.php?f=55&t=2594. Some information in this thread might be interesting. He stopped working with OX820 in May 2012.
Medion devices are still based on a 2.6.31.14 kernel. The latest source code is from Dec. 2012. (Download: http://www.medion.com/de/service/_lightbox/software_details.php?did=12008&hgt=504).



Edited 2 time(s). Last edit at 08/06/2013 02:54PM by shv.

I will stick to my plan. BTW, it is quite easy to generate patches from certain commits in github.
@kuleszdl:
It won't be a problem to get the patches, as I plan to commit each patch on its own. So, one commit should equal one specific patch. And people can get ready to compile kernel sources without first using "patch -p1 < ..." etc. .
And if you need the patches alone, you just let git generate them for you, based on the specific commit(s).

But let's not get ahead of ourselves. There is no functioning kernel 2.6.32.61, yet. Let's see if there ever willl be one. As I said, this is a pure learning by doing exercise for me. First attempt was not really successful, so let's see what comes next.

Edit:
BTW, I just realized that I had used telzey's older patchset (March 19, 2012) for my first attempt. Will probably use the newer set for the second try.
Edit2:
Just compared the 2 patchsets and partly there are huge differences. I'm quite excited to see how it will turn out.



Edited 2 time(s). Last edit at 08/06/2013 08:54AM by ingmar_k.

I hope that you are aware that both patches are from mid of March 2012 if you look on the file dates within the patch folder. The kernel-2.6.31.14-pogoplug3-2012-03-19.tar.bz2 package is based on cloudengines patches and kernel-2.6.31.14-pogoplug3-s-2012-05-20.tar.bz2 is based on Silverstone patches. The last one is not deeply tested due to telzeys posts in the referenced thread. The 3rd variant is the Medion kernel which can be donwloaded from the provided link.



Edited 1 time(s). Last edit at 08/06/2013 03:00PM by shv.

I honestly don't really care where the patches come from, as long as they work. But yes, I realized that one was based mostly on Silverstone patches.
The silverstone patches seem to take a different approach concerning SATA and USB. Let's see how that turns out. Maybe I'll compile compile some 2.6.31-14 kernels with that patchset first. I don't know when, though. Will be quite busy the next few days.

Edit:
Just had a look at the Medion sources from December 2012 and there are some very interesting additions, too.
Seems like there is a new network feature and maybe it's even based on a newer version of the PLX SDK, if there is such a thing (which I assume). Very interesting indeed. Thanks again for the hints.



Edited 1 time(s). Last edit at 08/07/2013 09:18AM by ingmar_k.

For those interested, I just created the full patch (complete difference in one patch file), representing the difference between the vanilla kernel 2.6.31-14 and the sources provided by Medion/Zyxel in December 2012.

Here it is:
http://www.hs-augsburg.de/~ingmar_k/Pogoplug_V3/medion_oxnas_december_2012_full.patch

Oh and by the way, something that has been bothering me for some time now:
How come Shuttle does have a NAS called "KD20" in their portfolio, which is clearly OXNAS based, but they don't provide ANY sources AT ALL? :-O



Edited 1 time(s). Last edit at 08/08/2013 12:10PM by ingmar_k.