Ditching v4.8.x for good


Hi community,

v4.8.x series is EOL for a long time now. There won’t be any updates to this branch anymore. Also it has some security flaws by now and is NOT recommended to be used. Therefore we will ditch it from our repos soon. Is anybody using that branch still and why?

  • Yes, I use that branch still (post why)
  • No, it is fine to be ditched

0 voters

1 Like

I need this kernel because this is the latest version of kernel with no this kind of ‘error’ log (?) when on boot :

platform wdat_wdt: failed to claim resource 4 
ACPI: watchdog: Failed to create platform device

(Though the system boots just fine…)

Please don’t remove it @philm, pleaseeeee

Or maybe its better if I use 4.4 kernel instead…oh well

1 Like

When did you test linux49 last? According to this it is already fixed.


Well…I have used 4.9 before the last stable update (2017-5-12) and it still show the same error log

Does the new one (the stable) update offers the fix for 4.9??

Or maybe I could install one tomorrow and see for myself…

The dev said it has been fixed on v4.9.6 or newer…not on my case

Is this happen because I used nowatchdog parameter???


Maybe also try linux410 and linux411 to see if they are also broken …


I remember when I install the 4.10 kernel before 3 known stable updates and it still show the same error log as 4.9 not sure about 4.11 though

Anyway I will install these ‘new’ kernel tomorrow and see what happens…

Thank you @philm for the response


If nothing else works, you could try 3.16. That one is supported until April 2020.


4.4 works just fine though… I’m using it right now

I didn’t know 4.8 was deprecated so I switched to 4.4 right now

(Though I still voted against ditching 4.8…)


Well, this regression should be fixed somehow. Depending on the hardware a git-bisect might take a while. Then it would be always good if a newer kernel might had fixed it or not. The latest is linux412 btw. :wink:

1 Like

Hello !

I would like to report that both linux410 and linux411 still shows the same error log when trying to boot, But like before the system boots just fine…

Oh! I almost forgot…Not sure if this helps…but there are others users that faced almost the same problem like me

And about the regression thing…Some folks from Arch Forum (Don’t know the link to the discussion) said that those error log happen because of outdated BIOS firmware…So I try update it and I realized my BIOS firmware is already latest version… so I’m stuck with these error log…


So then it has to be maintained by our devs because of ONE error message?
I have a solution that might work for you:

When you boot, do this:


That seems to work… Thanks for the help @jsamyth


I actually didn’t asked to be maintained I just ask how do I fix this error on my end…

1 Like

@thefallenrat I have the similar errors as you linked my thread - but in 4.9.27-1 (the LTS) I do not have them; Also its the last “recent” kernel where I do not see “ß” during boot where normal “s” would be ^^

Currently on 4.11.0-1 the errors got even more, on 4.10.15 it only was one line which I did as @jsamyth suggested - ignore; But getting more it seems ^^


To find the issue a git-bisect is needed. This means you have to know which kernel version was fine for your and which version might be the first not working for you.

For example:

  • current v4.8.x release is fine for you and has no issues
  • you might assume it was introduced with v4.9-rc1 or earlier

Then you have to compile v4.9-rc1 once again to check if that version already has the issue. If yes, then we have the last good version and one bad version. git-bisect can then find the first bad version, which might be the introduction of the issue for your hardware.

What does this mean:

  • you need some time to find the issue (depending on your hardware)
  • you need to put some effort into it
  • you might learn some new stuff

To have a small impression on what I’m talking you can take a look at this and the result. And yes, it takes some time.

We have great connections to the Linux foundation and with Greg Kroah Hartmann. If additional help is needed on the matter, don’t hesitate to write me an email.


Looks like there’s no other way around than to git-bisect huh?

At first, I thought git-bisect was hard until I saw @ groeck in github from the 1st link you posted explained the steps easily. I think I can do this git-bisect (hopefully). Wish me luck guys…

Anyway, Thank You so much @philm for the response, the links, guiding me, and for this amazing distro you maintained. And I wish you for a good day onwards…

Thanks again.

1 Like

@thefallenrat: git-bisect is not so hard. If you need help, email me. Also take the PKGBUILD I used for linux41 and check the history of the same to get intel on how I did it :wink: