Thanks for the reply. 3.8.13 support is unlikely, unfortunately even 3.9.3 (vanilla) on x86/x86_64 does not handle it. I've seen somewhere this driver was considered somewhat buggy, though I haven't faced any issues yet (luckily).
But I've seen an 'xbian-package-headers' directory in the master branch of 'xbian-package-kernel' github repository (not on 3.6.11 branch though), may I assume master branch and this headers directory might be used to replace a kernel on Alpha5 and help me to build the driver?
UPD. Apparently that didn't work as the module build environment isn't included into that kernel package. Didn't work with out of the box 3.8.13 as well.
May I ask the developers to build the module for me (and anyone else who owns such a "special" edition of TL-WN725N) or at least share a piece of the build environment required for that?
(25th May, 2013 07:09 AM)dot Wrote: [ -> ]UPD. Apparently that didn't work as the module build environment isn't included into that kernel package. Didn't work with out of the box 3.8.13 as well.
May I ask the developers to build the module for me (and anyone else who owns such a "special" edition of TL-WN725N) or at least share a piece of the build environment required for that?
I'm working on a process to provide headers environment together with kernel with each release, unfortunately automation scripts which are supposed to deliver and setup all the needed Makefiles and scripts buggy.
During cross compilation, those are prepared for HOST architecture instead of TARGET and, manual involvement triggers whole source recompilation and compiling on RPI takes hours.
The closest try is currently "working environment" - working technically, but usage of #include <memory.h> due to CONFIG_NEED_MACH_MEMORY_H=y makes #include <mach/memory.h> which is part of the kernel source, but is not included during building of the headers.
Slowly I'm loosing my nerves with this fight.
Hi,
I tried 3.8.13+ from the git repo (expecting headers to build module for my remote) and now, I can't use autofs (missing autofs4 module).
Is there reason to have removed it from the kernel ?
Of course, I was not able to compile my module, missing mach/memory.h
Good luck for your script to bring us headers
I'm currently committing headers. Feel free to create .deb and install. autofs4 will be added - next commit in few hours. Probably lost in the translation from 3.6 to 3.8.
Thanks for the update, headers looks good.
But trying to compile my module failed with :
Code:
/bin/sh: 1: scripts/basic/fixdep: not found
which looks like a missing linux-kbuild-3.8 ?
(27th May, 2013 11:02 PM)afrinc Wrote: [ -> ]Thanks for the update, headers looks good.
But trying to compile my module failed with :
Code:
/bin/sh: 1: scripts/basic/fixdep: not found
which looks like a missing linux-kbuild-3.8 ?
please do a pull from repo, create deb and dpkg -i install over previous.
the "install part" in needed, do not only copy files from repo to your usr. during installation, various scripts are generated ... (this was missing in the previous commit).
also, at xbian-package-kernel (branch testing) is latest version of kernel - from which the headers are generated - with the requested autofs.
Thank you,
autofs, compilation of modules, all works well
(3rd Jun, 2013 04:42 AM)afrinc Wrote: [ -> ]Thank you,
autofs, compilation of modules, all works well
thanks for feedback and test !
i suppose you installed initramfs-tools packasge (and possibly nore) as well (due to dependency)?
Yes I made and installed :
xbian-package-{firmware,initramfs,kernel,kernel-headers,splash,config-xbmc,config-shell}
I don't know which are realy usefull.
(kernel in testing branch)
I noticed a strange beahiour while installing initramfs, during the dpkg process /boot was unmount.
I don't know how to have splash working.
(3rd Jun, 2013 05:43 PM)afrinc Wrote: [ -> ]I don't know which are realy usefull.
(kernel in testing branch)
I noticed a strange beahiour while installing initramfs, during the dpkg process /boot was unmount.
I don't know how to have splash working.
you know how is it with the non useful packages. "What was I doing last before my pc stopped working? Oh yes, I was removing all the non important stuff"
There was a discussion and consensus at the end, that we better don't mount /boot automatically. it seems that unmounted vfat makes less troubles than mounted and crashed during freeze / too high OC, wrong AC. So in beta1 there is noauto flag in fstab and /boot is mounted according the needs. I was putting check everywhere before /boot mount a check, whether /boot was already mounted. If yes, it should not umount it later ... maybe somewhere (at kernel postinst script is this check missing) so needs to be corrected.
during install of splash, new binaries should be assembled inside initramfs as well to allow early start. during switch_root (from initramfs to real rootfs) the root NameSpace is destroyed and new created and normally running process will not survive this or would not be able to access new root. therefore there is a check for md5sum of splash on initramfs and on rootfs. if not the same (old version would crash or become not controllable), process is killed and after swith root new splash started. but this is fail over, normaly both versions should be the same. Sorry for the details, but with the info you can describe the issue you have more precise ... so what is the issue ?
mk
Quote:I don't know how to have splash working.
the "have" means "get" or "make" or ... ?
/boot : thank you for precisions
splash : I downloaded git repo, generated package, installed it, but don't have a splash image during boot.
ok, post please ls -la /boot; cat /etc/fstab; /var/log/apt/history.log and term.log (just relevant day); dpkg --get-selections | grep ^xbian-
As some users seem to stay with A5 for now, is there an easy way to use the latest kernel/firmware with this version?
I'm trying to run 'apt-get install xbian-package-xbmc -y' and I get the following error:
E: There are problems and -y was used without --force-yes
So running it with --force-yes then returns the following:
E: This installation run will require temporarily removing the essential packag xbian-package-config-shell:armhf due to a Conflicts/Pre-Depends loop. This is ften bad, but if you really want to do it, activate the APT::Force-LoopBreak opion.
E: Reverse conflicts early remove for package 'dialog:armhf' failed
Anyone know what I can do to get around this? Never had this problem when I initially set up xbian, just since it went tits up.
Thanks,
Ant
@
anthonyonions
without the whole output (where would be possible to see actual versions of packages) nobody will help you. what is it the version you have currently? looks like pre beta1 (alpha5 or older). and upgrading from this releases is possible, but not just the xbmc package.