paul- wrote:
> Some processes may not like being backgrounded and then trying to
> daemonize. You likely don't need to use the "-d". Or you can just put
> what you want in a script, then put the script name in user commands.
Removing the "-d" daemonize option from the USER_COMMAND irexec
paul- wrote:
> The url encoding is correct, it gets decoded at run time, it's the best
> way to preserve spaces and such.
>
> I'll have to see what is so special about irexec as to why it doesn't
> want to run from a shell script.
OK, I can see how the encoding would help, it just wasn't
jeroen2 wrote:
>
> >
Code:
> > #!/bin/sh
> #things to do at startup
> /usr/local/bin/irexec /home/tc/.lircrc &
>
> >
On a whim, I followed @jeroen2's suggestion:
* Commented out my /home/tc/.profile invocation of "/usr/local/bin
irexec
jeroen2 wrote:
> When I tried that it seemed to have an issue with finding the lircrc
> file. Since I already had a startup .sh script, I added it there with
> the lircrc path:
> >
Code:
> > /usr/local/bin/irexec /home/tc/.lircrc &
>
> >
On a tip from
https://www.brianlinkletter.com/persistent-configuration-changes-in-tinycore-linux/,
I manually edited /usr/local/etc/pcp/pcp.cfg and removed the
percent-encoding from USER_COMMAND_1:
USER_COMMAND_1="/usr/local/bin/irexec -d"
I then made this configuration persistent:
sudo
OK, I managed to get irexec running daemonized at boot. To do so, I had
to add it to /home/tc/.profile (excerpt):
Code:
if [ -f "$HOME/.ashrc" ]; then
export ENV="$HOME/.ashrc"
. "$HOME/.ashrc"
fi
# Can't start irexec from Tweaks->User Command, try it here
Per Ralphy's suggestion, I found that running irexec daemonized allows
me to invoke custom scripts via IR remote. I added irexec to
Tweaks->User commands, but irexec never survives reboot:
30907
I find nothing in Main->Diagnostics indicating that it started. Irexec
invocation is in pcp.cfg,
paul- wrote:
> I'm concerned about the error. It seems part of the install script from
> the source package did not pickup the new kernel name, and used the
> running kernel name. The extension may have no contents. However the
> compiled driver should still be sitting on the persistent
And if it isn't obvious, THANK YOU for all the work you have put into
pCP, and dealing with all this stuff. Probably time for another project
contribution...
Braklet's Profile:
paul- wrote:
> Rebooting is fine, since you are on 7.0.1. The new kernel drivers
> would not be used anyway. I'm concerned about the error. It seems part
> of the install script from the source package did not pickup the new
> kernel name, and used the running kernel name. The extension
paul- wrote:
> The wifi driver does indeed take forever to compile on a piZero. Anyway
> I found the problem
>
I will give this a go tomorrow. Thanks very much, paul! I do
appreciate your help with this, pCP allows me to maintain my now
decades-old LMS ecosystem.
Braklet wrote:
>
> Do you think it's worth rebuilding my extension using "-e 88XXau" ?
I tried it, no change. No LED activity from the WiFi USB dongle.
Have to ponder my next course of action.
Braklet
paul-1, is the extension name critical in loading? I used "88XX" as my
extension name, and got these extensions as a result:
88XX-5.10.42-pcpCore.tcz
88XX-5.10.42-pcpCore.tcz.md5.txt
But the actual driver name is "88XXau.ko" in the contents:
D:\Devices\Raspberry
Sadly, my wireless drivers didn't work after the 8.0.0 upgrade. The
LEDs on my pCP Pi B+ showed CPU activity, but the WiFi dongle never
recovered any LED activity, indicating no drivers.
I'm pulling an SD image now, in case I want to debug further. I will
restore the 7.0.1 image I took a
paul- wrote:
>
> Then obviously move it to the proper location.
Hi paul-1, your instructions worked a treat. Here's what I now have in
/mnt/mmcblk0p2/tce/optional:
Code:
tc@piCorePorch:/mnt/mmcblk0p2/tce/optional$ ls -al 88*
-rw-r--r--1 tc staff
I have dealt with the vagaries of Ralink and Realtek chipsets for many
years now, so I endorse the decision to remove problematic drivers from
the piCorePlayer distribution.
However, this puts me in a quandry. I'm happily running pCP 7.0.1 on a
RPi B+ with a Realtek-based USB dongle using the
Editing the quote...
paul- wrote:
> there is a chance you are running low of ram.
> You can look at the drivers in the extension wireless-KERNEL.tcz and see
> the list of drivers.
> What are your wifi specs? I don't have a good feel of the AC and AX
> chipsets that work. (Since I use the
paul- wrote:
> If you have an x86_64 ubuntu system, you could also cross compile the
> driver. I use a x86_64 system to compile all of the pCP kernels.
I have set up cross-compile environments for OpenWrt and work with Yocto
and buildroot occasionally, so I'm not completely clueless there.
I rebooted back into 7.0.1 with my new driver in onboot.lst, and
wireless came back up. (This is a headless system, wifi only.)
I will probably shut it down, take a SD card image, and then attempt a
8.0.0 in-situ upgrade.
But I am still very interested in swapping to in-tree USB WLAN
paul- wrote:
>
> Did you make this change to the driver source when you downloaded it?
> https://github.com/aircrack-ng/rtl8812au#for-raspberry-rpi
I followed your README here https://github.com/piCorePlayer/pCP-Kernels
The result is the same: all Makefile CONFIG_PLATFORM* options are n
Restarted with my 8.0.0 SD, monitor and KB.
The extension loading phase was MUCH faster than with my 7.0.1 SD,
leading me to believe something critical is not loading.
Console output reflects my migrated 7.0.1 configuration in 8.0.0. The
system thinks it enables WiFi and wlan0. Console keeps
Braklet wrote:
>
> Problem: I fumble-fingered my onboot.lst entry, so it couldn't read my
> new WiFi driver extension. Chalk this up to pilot error, duh.
Don't know how much of my own ignorance I want to put on display, but I
have a related script change request and welcom
paul- wrote:
> Im not following, because -KERNEL is precisely what should be in
> onboot. The word KERNEL gets replaced in the extension loader by the
> running kernel name.
I'm missing something here, because my 8.0.0 system did not load the
extension until after I changed onboot from
paul- wrote:
> You cannot do this.
>
> >
Code:
> >
> pcp_make_module_extension -k 5.10-42-pcpTEST -e 88XXauTEST
>
> >
>
> The kernel name that you use in the build scripts, must match the name
> of the kernel shown when you run `uname -r`
Here is the specific USB WiFi dongle model I use:
https://www.edimax.com/edimax/merchandise/merchandise_detail/data/edimax/au/wireless_adapters_ac600_dual-band/ew-7811utc
I fired up my pCP 7, the dongle works great. Here's some driver-related
stuff:
dmesg:
[4.652782] usb 1-1.3: new
Braklet wrote:
>
> I expected to find a 8812au driver module in /lib/modules, but did not.
> Is 8812au built into the pCP kernel?
>
Expanded my search, and found the associated driver module:
/usr/local/lib/modules/5.4.83-pcpCore/kernel/drivers/net/wireless/realtek/rtl8812au
/u
paul- wrote:
>
> lsmod
>
> and then run dmesg, and look towards the end, there should be a section
> that shows the detection of the wifi chipeset. Need to see the USB
> identifiers. :
Thanks for the response, sorry for the delay. (My pCP is remote and not
always accessible.)
I rebuilt my wireless driver extension on my pCP 7 system, installed and
rebooted back into pCP 7. Here are the associated directories for both
7 and 8 kernels:
Code:
tc@piCorePorch:/$ sudo find / -name "*pcpCore*" -type d -print
/lib/modules/5.10.42-pcpCore
28 matches
Mail list logo
