What change managed to break this? What’s the command just to roll just that back? I haven’t used that before.
I also had that exact issue yesterday. What worked for me was:
sudo pacman -U /var/cache/pacman/pkg/linux-5.13.12-1-aarch64.pkg.tar.zst
Which in the case you haven’t previously cleaned your Pacman cache packages will reverted back from kernel 5.14.1-1 to 5.13.12-1 version.
It would be a good idea before going through an upgrade to check the Upgrade Announcement for Known Issues. If you did not check before upgrading then also refer to the thread as this question is answered.
Hopefully the older kernel is still in your cache and do as @alsc said above.
I am currently building a kernel package, where I have hopefully fixed this issue.
I will link it when it’s done, so you guys can test it.
Also, if you have the option, can you try installing
linux-rc and see if the issue is also present there?
Should be version 5.14-rc7.
New linux-5.14.1-2 uploaded to unstable branch. This should fix the ethernet issue on rk3399.
Please read this:
Especially this bit:
A post was split to a new topic: ARM64 5.13 local cache deleted
today I’m running into the same issue. It is possible to fix this in stable!?
I get “could not find or read package” when using this command. is there another way?
It would be a good idea not to push to stable a release that breaks ethernet connection.
Users shouldnt have to worry about basic things breaking after a routine system upgrade.
That would be ok in a perfect world but it is not our fault upstream broke the wifi for your chip. It was a known issue when it was pushed to the unstable branch and and was posted under known issues in each announcement as it made it’s way down each branch. There are several devices that use that kernel that are ok with that kernel.
Not all users check these forums frequently. If it was a known issue it should not have been pushed to stable, end of.
As a users point of view it shouldn’t been push to the stable, but from maintainer point of view, it is nearly impossible to test kernel update on each and every device we maintain support for.
That will need a full time employee just to test kernel update on the whole list of supported device not to forget the delay in pushing the kernel to our repo as I would assume it will take atleast 2 days to test.
Even linus and greg says in their linux presentation that there is no way to test kernel updates on all the device, it is the community and the users who will have to test and inform the maintainer
They claim that if you chose to use linux you’re a part of the community and its everyone’s job to stay connected to the community hub, for Manjaro its our forum.
I have recently recieved the device and will test rockpro64 on kernel updates but I have the latest version so I cannot guarantee the my test will be the same as those having other version of the same board.
A known issue that breaks basic functions should NOT be released.
This is an expectation with little basis in reality, not with Manjaro nor even the venerable Debian. One should always read the release notes before applying updates or suffer the consequences, this is true of all OSes. It seems you failed to do your part and now blame the Manjaro Team that you broke your system.
First off I do not maintain that kernel but with the one’s that I do I have held back a couple of kernels for @ 2 months now because of a systematic breakage across the board on all devices that uses these kernels but other devices are not affected because they do not use these kernels.
I see from your persistence on this you do not seem to bend or want to take back a step and look at a bigger picture and that is your right to do so.
With this kernel a lot of other devices use this kernel and with your way of thinking of “I should not have to read known issues when a branch snap is done when I upgrade and no kernel needs to be released that does not fully work” you are denying many, many others with other devices the benefit of being able to upgrade to the latest kernel to take advantage of the latest bugfixes and enhancements all because you do not seem to follow our recommended procedures.
You can’t expect all user to read upgrade release notes, nor expect them to think that it will break something so basic in their system. Yes, I pressed the upgrade button, but a bug like this has no place in a stable release. No amount of mental gymnastics will change that.
I’m not blaming you, I’m just pointing out the obvious that the team made a mistake this release, pushing out a known breaking bug to stable release, and instead of owning up to it all I’m hearing is that its the users fault.
I’ll try again, your expectations are unreasonable. You are attempting to use the 5.14 kernel on an ARM SBC and upstream broke your ethernet driver, it happens. This is why Debian/Red Hat/Ubuntu run older kernels.
Stick to a more mature kernel 5.4 or before and you will have fewer issues.