Actually you can have Wheezy system which runs great with WarheadSE's standard 2.6.31 kernel (the one from Arch Linux) using libaccept4 as outlined in this thread, so why not first install such a system before experimenting with different kernels? Mine is running now for more than three months without any particular issues so far.by kuleszdl - uBoot
Well, for the last issue there is an easy solution: Write them asking for the source code, if they don't want to provide it or don't answer hand the case over to the guys from http://gpl-violations.org/, I'm sure they will handle this properly.by kuleszdl - uBoot
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 whiby kuleszdl - uBoot
That's bad luck. I've seen your repo on github, but where are the (altered) patches? Did you push them?by kuleszdl - uBoot
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.by kuleszdl - uBoot
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 seemsby kuleszdl - uBoot
@ ingmar_k: Sounds promising, please keep us updated. If you encounter bigger issues with one of the patches please let us know.by kuleszdl - uBoot
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.by kuleszdl - uBoot
@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'tby kuleszdl - uBoot
@shv: For me it works without the > /dev/null You probably inserted the line after "exit 0" in rc.local, didn't you?by kuleszdl - uBoot
@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?by kuleszdl - uBoot
@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)?by kuleszdl - uBoot
@bodhi: Nah, the great work was done by the others who found out how to make udev work on pre 2.6.32 kernels! And I think there are all the instructions on how to flash a newer kernel are there (see here: http://archlinuxarm.org/forum/viewtopic.php?f=29&t=4683), the problem is just that - there is no "proven stable" kernel newer than warhead se's available - some peopby kuleszdl - uBoot
Wohoo, I got it working with a clean wheezy system running the ALARM kernel thanks to libaccept4! As indicated earlier in this thread by bharath (I must have overread this!), apart from adding the libaccept4 library and enabling it via /etc/ld.so.preload you also have to disable the udev-checks done by /etc/init.d/udev. I achieved this by uncommenting the following lines, so that the method &qby kuleszdl - uBoot
I see - you kept back udev and ended up with a "most wheezy but squeeze-leftovers"-system. While this sounds practical and probably is better than staying with squeeze (especially after support will end!) but still I think we should strive to find a way to get a clean and (mostly) complete wheezy on the pogo pro. Actually I see two feasible approaches to accomplish this: (1) get libaby kuleszdl - uBoot
bodhi: Okay, this was a misunderstanding then - I just meant the userland, not the kernel.by kuleszdl - uBoot
bodhi, what is wrong about the upgrade path via the usb drive? This way, if you mess up the system you can easily "reflash" the stick externally via dd or by copying over your backup. Messing with NAND is rather difficult and you always have the danger of screwing up your system and can only recover it with serial cable and other quirks. I was running arch before also from the usb drby kuleszdl - uBoot
Thank you for the hint, bodhi! Indeed I have tried updating the system, and during upgrade you get asked whether you want to keep the old udev due to kernel incompatibility (guess this will not work when doing this in the chroot though). Anyways, it seems like installing udev fails anyways: Moving obsolete conffile /etc/init.d/module-init-tools out of the way... Moving obsolete conffile /etby kuleszdl - uBoot