This i686 issue should be fixed in the 301 build, sorry about that. 300 only contained half a fix.

Moved from 4.5.1-300.fc24.x86_64 to this w/o issue. dmesg and journalctl -b look clean enough and all's well. I've not tried anything in the BZ reports tho.

FWIW, I did dnf install *.rpm and that downloaded zlib-devel-1.2.8-10.fc24.x86_64 from the fedora repos; it was not in the set downloaded by bodhi. (zlib-devel is needed by binutils-devel). I only mention this in case it's a sign that zlib-devel should have been a product of this build and/or pulled down by bodhi.

FYI: kernel-PAE-4.5.2-301.fc24.i686 boots for me but later on fails with i915-problems.

tested x86_64 on bare metal and VM, and i686 and PAE in a VM, all boot OK.

Wasn't this update primarily to address i686 issues on bare metal?

Works great! LGTM! =)

corsepiu: No, it wasn't. the i686 issue affects VMs as well as metal, and the CVEs are, well, CVEs.

i686 was DOA anyway, so it's not like we can make it any worse by approving the update.

corsepiu: adam is correct, the 4.5.2 update contains 125+ fixes compared to the last update pushed, some of those being security related. That is the main reason for the update. Trying to get an F24 update that would boot on at least some form of 32bit was enough of a reason for me to lose some additional sleep and do a 301 build, but 4.5.2 would have been submitted either way. Anything broken on 32bit at this point is not a regression, previous F24 kernels would not boot on any 32bit system. Getting this booting on some will at least expose the other issues that need to be addressed.

@jforbes: I understand, RH is not interested in the i686 anymore and "fedora-testing" therefore has defined the i686 as irrelevant. I regret, but to me this read as "RH is not interested in the community", anymore.

@corsepiu: Then perhaps you completely misread my comments. Yes, i686 is not a priority for us, but we are very interested in the community here. The fact that a member of the community spent so much time tracking down the problems with i686 was enough motivation for me to stay up most of the night and get a kernel that would boot on at least some i686 out. Sure, there may be other problems, but we can't even know what those are until there is something out there that works for at least some 32bit testing. That will allow the other issues to be discovered and potentially fixed. No one can even try to fix them if they don't know about them. The fact that you can now see an i915 issue is clearly progress compared to the previous updates.

The 4.5.2 update is a separate issue. Yes, it would have been pushed anyway. It does fix a lot of issues. The idea of adding negative karma for a non regression is a broken system. Having a 32bit kernel that won't boot is not a regression, 4.5.1 doesn't boot on 32bit either. Giving 4.5.2 negative karma because it still doesn't boot on 32bit is like saying "because my issue still is not fixed, I don't want anyone else's to have access to their fixes either". That has nothing to do with 64bit vs 32bit, it is the case with non regression issues in general. If the currently supported package in stable has the issue, it is not a regression, it is just a bug that hasn't been fixed yet. If we only issued updates when every single issue was fixed, there would never be an update... ever.

@jforbes: I reported the i915 issue 2 months ago: https://bugzilla.redhat.com/show_bug.cgi?id=1307033 sad but true: it was ignored.

But you are right insofar, it was overshadowed by other issues (those nickc, hjlu and other addressed) which rendered reproducing it difficult.

Anyway, lets stop this discussion here. bodhi is not the right place to discuss it or RH politics.

This update has been unpushed.

x86_64 works for me on a NUC and Macbook Pro.