OpenWrt Forum Archive

Topic: CC 15.05.1 is here

The content of this topic has been archived on 26 Oct 2016. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

This kernel hang could be the issue I am seeing on several 841v8 & v9's.

Is there a patch coming or should I revert to CC 15.05 for now?

Thanks for your time.

Is 48925 15.05.1?  It sure sounds like the same problem.

(Edit: Later answered below that 15.05.1 is 48532.)

I think any word of a patch will come in the mailing list (click "Thread" at that link for any further responses, though none to date have commented on it), but I wouldn't count on it considering how long it took to get .1 and how all eyes at this stage are probably on DD.

(Last edited by rseiler on 17 Mar 2016, 17:17)

I'm a little confused now because

    git-svn-id: svn:// 3c298f89-4303-0410-b956-a3cf2f4a3e73

Edit: Date:   Thu Mar 3 22:28:12 2016

shows a kernel update to 3.18.27.

I don't think I am on the 15.05.1 branch, git remote -v shows


Edit: The only tag is 15.05.

Is 15.05 branch ahead of 15.05.1?

(Last edited by sailor_ca on 17 Mar 2016, 01:41)

sailor_ca wrote:

Edit: Date:   Thu Mar 3 22:28:12 2016
shows a kernel update to 3.18.27.
Is 15.05 branch ahead of 15.05.1?

According to openwrt-devel, the 15.05.1 build is about 4 weeks old, it seems to be a snapshot of mid-February which hasn't been tagged in the repository.

Edit: 15.05.1 is built off r48532

(Last edited by metai on 17 Mar 2016, 02:13)

Ah ok....makes sense now.  Thanks.  Although a boot problem seems to still exist:

(Last edited by sailor_ca on 17 Mar 2016, 02:03)

From the mailing list, which somehow still hasn't answered the all-important kernel question:

>One note about the kernel version: 3.18.23 is a very unfortunate choice, as
>it contains a regression causing nondeterministic boot hangs (caused by a
>faulty backport), which is very easy to trigger on some hardware. This has
>been fixed in 3.18.24 (see [1]).

15.05.1 certainly seems to have bricked my DGND3700v1. A TTL serial<->USB
adaptor is in the post to see if I can resurrect it.

cheers, Phil

As mentioned, CC 15.05{.1} is now on kernel 3.18.27 so this kernel issue should be resolved according to the devel list.  However, as I mentioned, I still have 841s that are getting stuck on a power cycle.  Given the intermittent power here in Guatemala I may have to revert to BB until this gets resolved.

OK, I didn't realize that necessarily meant that it would ever get built. Compilations are few and far between.

Sorry Rseiler.  I'm not sure when the repository gets updated either sad  It may still be at kernel 3.18.23.

If you go to the 15.05.1 downloads and look at the base files and kernel you will find

  • kernel 3.18.23

  • R48532 … ages/base/

If I understand you right, if I build my own i get 3.18.27 today

I understand why it took a month to deliver 15.05.1, not sure I understand why it was not freshened up though with the latest before it was rolled out.  Is this not just a bunch of build bots?

yes it sucks dick especially cause there was no builds available for month. sent gl-ar150 patches twice and it wasn't added...

Well, with the infrastructure back up, maybe we'd get 15.05.2 with the 3.18.27 kernel to avoid ambiguity.

Some of the 15.05.1 builds are missing packages!  I tried to use the 15.05.1 Imagebuilder for brcm63xx/generic to build an image and get the following response:

Collected errors:
* opkg_install_cmd: Cannot install package luci.
make[2]: *** [package_install] Error 255

Upon researching the issue I discovered that … ages/luci/ does not contain the expected packages.  I think I can work around the issue by editing the packages.conf to point to 15.05 for luci packages, but this make me suspect the quality of the 15.05.1 release!

Perhaps the project could use a dedicated release manager or team to do some checking and QA on builds before they are posted for release.  Since 15.05 also includes  a bad build for adm8668 and adm5120/rb1xx as well.

the build of CC 15.05.1  has bin a real fuck up.

Should of waited and fixt the servers before building. What's the point of putting a 4 week old build out that any one could of built and put on the forums.

There is  kernel  bugs. nat leacking through the firewall and missing packages.

Pleas rebuild and reup.


Speaking out of turn since I'm not a dev, but... I believe they have very little extra time available to devote to point releases.

This one was "old" because of unexpected infrastructure problems which interrupted the build and staging process.  Once those were fixed some weeks later the original process was simply continued, not restarted from scratch after rebasing, because of lack of time to do the manual work the latter requires.

That being said, there's some wisdom to Linus's "brown paper bag release" strategy:

- Publicly declare a certain release version an "oops!"  That way everyone knows to avoid it.
- Assemble a new version and release it ASAP.
- Problem solved.

Not my place -- just my 2 cents smile


I've just installed the new CC 15.05.1 and everything works except for my cable connections via homeplugs are running extremely slow. Only getting 50% of my download speeds.

I just downloaded 15.05.1 and checked m5sum and gpg signature. How do I know, that the gpg signature is correct? I didn't find the fingerprint of Jo-Philipp on the openwrt page.

$ gpg --verify md5sums.gpg md5sums
gpg: Signature made Tue Mar 15 18:14:15 2016 CET using RSA key ID 8775B24C
gpg: Good signature from "Jo-Philipp Wich (OpenWrt signing key) <>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: CD32 2753 86BC 17CC 0E21  1C34 BEA8 F6E2 5378 AAF8
     Subkey fingerprint: A07E D873 F481 ACEC 44C7  98BF C9B0 37C2 8775 B24C

Well, at least I know next time that the source is the same...

Latest from the mailing list:

> One note about the kernel version: 3.18.23 is a very unfortunate choice, as
> it contains a regression causing nondeterministic boot hangs (caused by a
> faulty backport), which is very easy to trigger on some hardware. This has
> been fixed in 3.18.24 (see [1]).
> Regards,
> Matthias
> [1]
> … h=v3.18.24

I must correct myself on this issue: 3.18.24 did not fix it, but only hide
it. 3.18.27 is affected as well. I'll try to find out what is causing it.

Fortunately, the official 15.05.1 images seem to be unaffected (at least on
the two devices I've seen the issue on, TL-WR841 v5 and v7), but building
the CC HEAD will often yield broken images.

There are multiple reports of this issue already, I've found the following:

The issue is extremely suspectible to timing (or minor differences in the
kernel image?), adding any additional debug output just made it go away in
my tests so far... hmm


I'm using the Image Generator which is being locally built.

I see some strange things about CC 15.05.1 - the kernel is v3.18.27 rather than the announced v3.18.23
As a result - it is impossible to use the officially built modules for my custom firmware images - the version mismatch.

I've asked some gurus on another forum - they say it is an error with branch tagging.

I hope the CC 15.05.2 will fix this.

rseiler wrote:

Does this help at all by any chance? … 40489.html

Most probably, those gurus have used exactly that patch - I'm using their github for now.
(I'm a novice, so I let it to professionals)

Is it possible to replicate the exact configuration for 15.05 with 3.16.23 kernel? What it the right tag for git to get the exact clone of 15.05.1?
I have to backport 


and to compile three kernel modules:


to get my Huawei E3372 working on WDR7500 (generic ar71xx).
I cloned git for 15.05, waited hours for toolchain, patched modules and built kernel. I got nice IPK but certainly for 3.18.36 kernel.
How can I backport this patch or where are the sources used in 15.05.1 release?

(Last edited by mbrudka on 10 Sep 2016, 23:34)

As it seemed that nobody knew how to get the exact recompilation of 15.05.1, I decided to switch to bleeding edge version to get the patch I needed. It worked.

The discussion might have continued from here.