You are not logged in.
Pages: 1
Several issues with modules occurred after today's kernel upgrade.
I think that the kernel that is pushed should be compiled with the compiler that we have in our systems.
If the kernel is compiled with a different gcc than the one that we have (today's 4.0.1 kernel is compiled with gcc-5.1) then we get issues with modules that we need to compile (e.g. vmware).
I solved worked around this issue by uncommenting the testing and the testing-multilib (i got skype) repo, to download gcc-5.1 and all its deps, compile the vmware modules with it and downgrade everything back.
Last edited by redsolja (2015-04-30 08:10:56)
Offline
If what you're stating is true, check for an open bug report and if you cannot find one, open one. You cannot verify that the devs will find and read this post.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I didn't consider this a bug and yes I thought that the devs will look here.
But I guess you 're right. I will.
Offline
Same problem here. Vmware modules failed to compile since updating to kernel 4.0.1, error message was something like gcc path not valid. I reverted to kernel 3.19.3 to get back Vmware working.
Offline
@gamaraan - https://bugs.archlinux.org/task/44784
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I temporarily falled back to kernel 3.19.3 instead of that (luckily I still had the packages in the cache). I have another problem, with my video flickering and waving with kernel 4.0.1 (Intel HD 3000 + GT550M optimus), so I'm forced to wait a little more longer till I can upgrade to kernel 4.0.1.
Offline
I temporarily falled back to kernel 3.19.3 instead of that (luckily I still had the packages in the cache). I have another problem, with my video flickering and waving with kernel 4.0.1 (Intel HD 3000 + GT550M optimus), so I'm forced to wait a little more longer till I can upgrade to kernel 4.0.1.
Could someone point us Arch newbies that are just switching to Arch now, in the last week or so, how to downgrade the kernel on a *new* install?
https://bbs.archlinux.org/viewtopic.php … 4#p1526794
Reading a lot, it seems I need a previous binary in my cache - which doesn't exist for a new install (for someone who is just switching to Arch!).
More than happy to compile my own kernel if that is needed... Though, I am not sure what packages I need to downgrade?
Last edited by eduncan911 (2015-05-07 17:56:48)
Offline
Could someone point us Arch newbies that are just switching to Arch now, in the last week or so, how to downgrade the kernel on a *new* install?
Even newbies should know we have a wiki that covers a lot of topics. Just search for downgrade (package); probably best not to add "kernel" as if that's very different from other packages.
Offline
Yes, and I have read how to downgrade packages.
But as I asked directly, how to "downgrade the kernel" for *new* Arch installs? There is no "cache" in a new installation.
Offline
how to "downgrade the kernel" for *new* Arch installs? There is no "cache" in a new installation.
Offline
eduncan911 wrote:how to "downgrade the kernel" for *new* Arch installs? There is no "cache" in a new installation.
Awesome. You missed @WorMzy in another thread by 2 minutes. I'm all over that ATM.
Offline
Yes, and I have read how to downgrade packages.
Clearly not all of it, only the part about using the cache.
If you get pointed to documentation even if you have already had a look at it, it can't hurt to look again, maybe a bit more closely.
Last edited by Raynman (2015-05-07 19:43:48)
Offline
More to the topic, I think that there is a better solution/workaround for this, especially for a new installation.
You can just recompile the archlinux kernel, using exactly the same configuration file, but with your own gcc version (4.9.2). I think that this will enable compiling the vmware (and other) modules easier.
Offline
More to the topic, I think that there is a better solution/workaround for this, especially for a new installation.
You can just recompile the archlinux kernel, using exactly the same configuration file, but with your own gcc version (4.9.2). I think that this will enable compiling the vmware (and other) modules easier.
Just coming back to say you were right! Rebuilding the kernel using the gcc version is the cleanest approach to stay on tip (and I'm assuming rebuilding the kernel every time a new version is released).
Offline
redsolja wrote:More to the topic, I think that there is a better solution/workaround for this, especially for a new installation.
You can just recompile the archlinux kernel, using exactly the same configuration file, but with your own gcc version (4.9.2). I think that this will enable compiling the vmware (and other) modules easier.
Just coming back to say you were right! Rebuilding the kernel using the gcc version is the cleanest approach to stay on tip (and I'm assuming rebuilding the kernel every time a new version is released).
I don't think that you 'll need to compile the kernel each time a new kernel is released. I guess gcc-5.1 isn't that far from getting into [core]. Just remember there are at least 3 workarounds for this:
enable [testing] repository and issue a pacman -Syyu. After that, compile the modules that you want to compile with the new gcc version. This is will work for as long as gcc-5.1 is in [testing] AND the kernel is compiled with that version. To get the gcc version that compiled the kernel you are booting, issue a journalctl -b and close to the top, you should see a line that looks like this:
arch kernel: Linux version 4.0.1-1-ARCH (builduser@tobias) (gcc version 5.1.0 (GCC) ) #1 SMP PREEMPT Wed Apr 29 12:00:26 CEST 2015
recompile the kernel with the gcc version that your system has. This is the most helpful article i think
downgrade. I would suggest downgrade
I am pretty sure that people will come with more workarounds for this, but I find these to to be the simplest.
Last edited by redsolja (2015-05-08 08:06:53)
Offline
eduncan911 wrote:redsolja wrote:More to the topic, I think that there is a better solution/workaround for this, especially for a new installation.
You can just recompile the archlinux kernel, using exactly the same configuration file, but with your own gcc version (4.9.2). I think that this will enable compiling the vmware (and other) modules easier.
Just coming back to say you were right! Rebuilding the kernel using the gcc version is the cleanest approach to stay on tip (and I'm assuming rebuilding the kernel every time a new version is released).
I don't think that you 'll need to compile the kernel each time a new kernel is released. I guess gcc-5.1 isn't that far from getting into [core]. Just remember there are at least 3 workarounds for this:
enable [testing] repository and issue a pacman -Syyu. After that, compile the modules that you want to compile with the new gcc version. This is will work for as long as gcc-5.1 is in [testing] AND the kernel is compiled with that version. To get the gcc version that compiled the kernel you are booting, issue a journalctl -b and close to the top, you should see a line that looks like this:
arch kernel: Linux version 4.0.1-1-ARCH (builduser@tobias) (gcc version 5.1.0 (GCC) ) #1 SMP PREEMPT Wed Apr 29 12:00:26 CEST 2015
recompile the kernel with the gcc version that your system has. This is the most helpful article i think
downgrade. I would suggest downgrade
I am pretty sure that people will come with more workarounds for this, but I find these to to be the simplest.
Thanks. Yep, those are options. But for vmware I did try all 3.
#1 i could get to compile with patched source under gcc 5.1 in testing but the binary would hard lock the VM guest. I did this on two different machines and two Arch setups. So i don't think it was me.
#3 downgrading the kernel couldn't be done on a new install without the pacman cache for the previous kernel. someone did link me to the ARM archives and i was in the process of locking down my pacman to a specific date. but that started to feel dirty, limiting my entire system just to get an older kernel. one of the main reasons i'm switching to Arch is to have the latest and greatest. but if i time lock my pacman, what's the point?
hence, why i ended up with #2 - just use ABS and recompile the existing kernel and headers.
thanks again! it was really helpful!
Last edited by eduncan911 (2015-05-08 12:26:38)
Offline
I temporarily falled back to kernel 3.19.3 instead of that (luckily I still had the packages in the cache).
If you didn't, it could've been easily grabbed from the Rollback Machine and then placed in the pacman cache.
PC: Arch Linux x64 | customized Cinnamon desktop | Latitude E6440 | Core i5-4310m | 16GB RAM | 500GB SSD | Das Model S Pro Soft Tactile keyboard | Logitech Trackman Marble trackball.
Audio: Sony STR-DH500 5.1ch AVR | Modified Koss Portapro headphones | Rockboxed Sansa Fuze | Realistic Minimus 11 front and rear satellite speakers + Minimus 7 center channel.
Offline
#3 downgrading the kernel couldn't be done on a new install without the pacman cache for the previous kernel. someone did link me to the ARM archives and i was in the process of locking down my pacman to a specific date. but that started to feel dirty, limiting my entire system just to get an older kernel. one of the main reasons i'm switching to Arch is to have the latest and greatest. but if i time lock my pacman, what's the point?
thanks again! it was really helpful!
You can lock a specific package, not all of them. It is what I did at that moment.
Offline
eduncan911 wrote:#3 downgrading the kernel couldn't be done on a new install without the pacman cache for the previous kernel. someone did link me to the ARM archives and i was in the process of locking down my pacman to a specific date. but that started to feel dirty, limiting my entire system just to get an older kernel. one of the main reasons i'm switching to Arch is to have the latest and greatest. but if i time lock my pacman, what's the point?
thanks again! it was really helpful!
You can lock a specific package, not all of them. It is what I did at that moment.
I tried locking down the kernel, and then it asked for dependencies. I started to lock them down and there was more dependencies of those dependencies. What scared me (newbie) was that it didn't list the kernel headers as a dependency.
That's why I just went the #2 route... Besides, I've always built my kernels 20 years ago. Getting back into linux after a long career in Microsoft, I wanted to do that anyhow.
Offline
Pages: 1