They come down as a dependency for one of the packages I have selected, not directly enabled.
Any chance for that some of you can add information about you finding on the 1900 fan control issue in issue #345 ?
I have removed this cron job on any WRT router that is not the 1900AC.
My fix was replacing roots crontab file with my own (that does not contain that job), and on first boot there is a one time set up script that runs to check which "model" WRT router the user has. If the model is "WRT1900AC", then it adds the fan logic. Only I am using the fan daemon, not the script. However a user can revert to the script if they choose to do so as I added uninstall logic for the daemon as well.
Not sure if you where replying to me but. My idea was. If there is improvements to how the fan control is done on those Linksys modes, and, like you wrote, detected. Then perhaps that information should go back into a official issue instead of getting "lost" in a community build.
@cybrnook
Installed your latest, r2747 on the wrt1900ac v1, Fan does not run after boot up which is good. The fan script now runs without issue. Permissions are now correct. When run the scheduled tasks is updated with the cron entry for the fan. Fan does not run all the time.
Looks like a winner. Have not updated the wrt1900acs as have a teenager home. Has eye infection and doc said she should stay home from school, so lots of streaming going on right now. Don't think you have made any changes to the build from the previous for the wrt1900acs v1 anyway.
Let me know if you want something else done/tried.
--bill
1 Like
I was 
But nevertheless it's a good topic to point out. I think there would be a nice handful of ways to skin this cat.
One easy one would just be adding a nice little:
echo "*/5 * * * * /sbin/fan_ctrl.sh" >> /etc/crontabs/root
in one of the default setup scripts (instead of one of my own). I agree there is no need to have it baked into ALL WRT model routers, as it doesn't belong. I assume though someone would need to post a PR with the change to fix this. I could likely do this, the work that is, but the path to cleanly publishing a PR for commit is still new to me.
The file that needs to be updated (removing the job) is */target/linux/mvebu/base-files/etc/crontabs/root
The next piece to finish it though, is to add logic elsewhere that would be smart enough to know the router is the WRT1900AC, and add that line back, but only for that model.
What I am doing for my builds is just searching the output of "/tmp/sysinfo/model" and then going from there.
Here is another thread I opened with some good info regarding this:
@mkresin points out the "go to" to be able to do what we are talking about. I just need to sit down and put the pieces together one evening.
EDIT: So the scripting wasn't that bad, just no idea what to name it, where to "drop it" or how to "PR" it..?
I assume I would need to "fork" a copy of source to my git account, make the changes to my fork, then publish a PR against source (master)? (Obviously I am learning 
)
EDIT2: Hell, while we are at it, would be even better to go one step further and roll the fan "daemon" out instead of a cronjob.
@anomeome - Helllllppppp 
I think you've helped me nail it
I am compiling the latest build as of today, with all our current changes, and that will be the next publicly announced release (updated op).
Thanks so much as always @billmy1228 (and of course @anomeome for some assists)
Re: PR, read post by @jow here for initial, and how to squash if a change required. This should be added to the wiki for potential contributors.
I think the correct way to deal with the mamba fan would be to remove the current shell script if not building mamba, so a Makefile change perhaps. The only reason I took the tack that I did in the per-device rootfs thread was I was just looking for an excuse to put to use that facility which had recently been introduced at that time. and of course I am using a modified @gufus fan script on my mamba
Another method would be to deal with it in the init stuff that I linked you at in the other thread to which you referred.
Edit: Or... a PR that removes the current fan script, adds a modified @gufus script as a feed/package for mamba build. The procd way is better than the cron job anyways, so why not. Although I would then suggest that the code should be made current, as in the way things are done now as per the wiki.
1 Like
Absolutely agree, there would be no reason to even have the script sitting in sbin at all if not on mamba. Instead of just "pretending" it's not there.
Would be very trivial to <<EOF EOF the script contents to sbin in the event it is a mamba though, that could be added to the script I wrote above pretty easy.
EDIT: Just added it (I think)
So in this case, we could drop the contents of crontabs/root, delete fan_ctrl.sh, and then just upload this to run in it's place?
Just tested it, and seems to run clean.
I think we are both modifying our posts at the same time 
So my repsonses may be a bit updated since you last read them, as I see yours are too.
I agree as well, that this could be an opportunity to update the cronjob to the fan daemon. With the script I wrote above, We could easily break out 2 x different EOF files (fan_monitor, fan_control), and write them out to the OS. As well, we could embed the "enable" command to then also add them in rc.d as symlinks so they auto start/stop.
But now the question would be whose daemon do we like best, and what would be the most "universal" settings out of the gate to give users, while still making it easy enough for them to modify if needed.
EDIT: So looking at @jow 's response to you in your link, he lays out nicely the steps to make changes. I have a few questions that start before what he has pointed out. 3 x questions really...........
-
I have a git account, but my page is empty. I have no clones, forks etc..... Do I need to "fork" LEDE source first in order to then "clone" my personal repository to my personal dev environment?
-
(A carry over from 1.) In the event that it doesn't matter that my git account is empty (only establishing a git link between my git account and dev environment), would I need to manually create the fully qualified path to the file I want to ultimately modify? And if so, do I also need to take into account chmod/chown permissions within my dev environment? (Will this cascade through, or are permissions and ownership independent once it reaches back to source/trunk?)
-
Will my actions of cloning another git repository in my dev environment (of course into another folder than my lede clone) affect at all my git env that has been established for my lede clone? Or are they now two separate working environments, granted I am in the root folder?
For example, my LEDE source clone is in /lede/source, and my new personal clone is in /cybrnook/source, these are independent, correct?
EDIT2: I think common sense dictates that, "Yes" I need to fork a copy of LEDE trunk to my personal git. Then clone my copy of trunk.
On github, from LEDE source, you fork, which will give you a "source" repository under your moniker.
The rest is going to depend on how you like to work. My way, not necessarily the best way, I have separate trees, but use a bit of a hybred method of working in the trees. No impact between trees, but you now have the extra work of moving things.
Best method, use git branches, work, toss garbage by throwing the branch away, git stash to save things you may want. Don't know if this plays well with ./scripts/env though, but I have not used that in a long time.
Ha, not used that in a long time. 
I am a git newbie, so these old terms and process are completely new to me. I will likely be verrrry singular at first.
Have to plant the seed first so my "tree" can grow it's "branches" which I can then plant other "trees" with. (I have no idea what I'm doing..................)
Just forked off source...... Will clone my own git now.
But I want us to better align before I start mucking in it (before my first add/commit). I want the revision history to be clean, so the least amount of changes we can get away with the better.
EDIT: Cloning was easy enough, will start my vim trip now.
are scripts/files within board.d and uci-defaults both combed during first boot and ran? (I know uci-defaults, as I use that currently)
I need to know where to drop the script at, AND have it run (assuming during first boot) so it can determine which model router it is. I don't think this would qualify as a uci-defaults z* script, would it? But then again it might since this is a one off case......
Can you help me understand what is happening with the scripts already in here with names like 01_, 02_ , 03_
Like in etc/board.d or in /etc/uci-defaults
Could I just place this in board.d or uci-defaults named "04_mambafan" ? And it would be the 4th "setup" script that would run on first boot for mvebu devices? And since I have an exit 0 , it will end clean either way, thus being deleted after first boot?
This, part of the boot, first setup stuff.
I would question doing this after the fact though. To my way of thinking, better to just not put it into the build unless mamba, instead of removing something you don't want.
I am going to do a test commit here in a little bit to try and show you what I mean.
@anomeome , quick question. After I have made my changes (a few file/folder deletions, and creation of a file). What is my process for the "git add" command.
Can I just:
git add target/linux/mvebu/base-files
and catch all the files behind that (recursive), thus catching all my modifications?
I am at @jow 's example of:
$ nano package/kernel/mwlwifi/Makefile
$ git add package/kernel/mwlwifi/Makefile
Only I have played with more than just one file.
Best to add each file that you want part of the change, rather than" -a or ."
git add file
git commit -s -m "mvebu: blah" -m "description"
git push origin branch
That is now in your fork and I could peek
Edit: since you are starting you will have to:
git config --global user.name "REAL NAME"
git config --global user.email real.email@provider.com
git config --global core.editor "nano"
Edit2: git should track all changes, if in the branch,
git checkout master
git branch -d | -D branch
Should get things back to before changes. you may have to clean up github, whether from your environs or on the website.
Edit3: I assume you would just
rm file
and git would see the change. got'ya, ya I guess that would be the way.
Edit4: Just a note on your PR. I assume someone will ask you to amend the PR and add a signed off by email. You will have to add the above git config for name and email; that is the -s option on the git commit, I assume the same name on your github account. Take a look at pending PRs for an example of correct form, and this
1 Like
what if I want to delete a file or an entire folder (that is no longer necessary). How do I track that change?
And, as advised, I follow the instructions and made a branch (and have since deleted files/folders/made updates). Let's say I want to scrap what I did and start over to more cleanly track my changes. Can I do that (even though I have deleted things), or do I need to re clone again? Or scrap (and everything magically shows up again?)
and deleting files/folders I assume would be:
git rm file
git commit -s -m "mvebu: blah" -m "description"
Alright, so I have made the "test" changes and committed them to my fork.
Oh geez...... I seem to have publish this against LEDE source as a PR 
Well, I guess the worst that can happen is it get's denied. Best case it get's approved, and then we take the next step afterwards. Which would be then converting it to the daemon.
I think I have done enough damage for one night 
3 Likes
@anomeome, super big kudos/thanks to you again (as always). You are really helping me to get my bearings in this project as I stumble along 
.
Flashed your latest on my WRT1900ACv2(Access point), and my WRT3200ACM-Main.
Working extremely well ! Will update if I experience any issues.
Thanks very much for your images !