Evening all,
I managed to get a preorder for the B580 - so hoping to have my hands on it around Christmas.
I’m currently running Zorin OS (Ubuntu 24.04 based) so I’m currently on 6.8.
With the Xe2 driver only really making it into the bleeding edge 6.12 / 6.13 kernel builds, I would appreciate some assistance / guidance as to how I should proceed.
I did try to install the latest (6.12) mainline kernel, however, this fails due to dependencies on packages which cant be met with the default repos:
dpkg: dependency problems prevent configuration of linux-headers-6.12.3-061203-generic:
- linux-headers-6.12.3-061203-generic depends on libc6 (>= 2.38); however:*
- Version of libc6:amd64 on system is 2.35-0ubuntu3.8.*
- linux-headers-6.12.3-061203-generic depends on libelf1t64 (>= 0.144); however:*
- Package libelf1t64 is not installed.*
- linux-headers-6.12.3-061203-generic depends on libssl3t64 (>= 3.0.0); however:*
- Package libssl3t64 is not installed.*
I saw intel state the driver is being backported to 6.11 in some cases…
The above in mind - am I missing an option here?
I really like Zorin, packages have been rock solid - so don’t feel like moving to another distro.
I’ve been a linux user for a few years, however this is the first time I’ve attempted to run a later kernel than main…
Thanks in advance!
Some additional context:
linux-headers-6.12.3-061203-generic : Depends: libc6 (>= 2.38) but 2.35-0ubuntu3.8 is installed
Depends: libelf1t64 (>= 0.144) but it is not installable
Depends: libssl3t64 (>= 3.0.0) but it is not installable
In case this helps anyone else who may land here with a similar situation…
I was able to get the latest mainline kernel running without updating all the packages / moving to a sid repo.
This is not ideal practise, however seems reasonable enough for a non critical system - especially as this leaves the option of rolling back by simply booting back into the ‘correct’ kernel.
Step 1. Install the desired kernel files either via manually dpkg or use a tool such as mainline kernels.
Step 2. assuming you run into the issue with dependencies as above - I went with a ‘dirty’ solution of editing the dependency list under ‘/var/lib/dpkg/status’ by removing any missing packages that aren’t included in your configured repos / changing the version of installed but older ones) - dont worry too much about this - if you remove and reinstall this package, the dependency list will be corrected.
This will stop package your manager(s) (rightly so) warning you of the missing dependencies.
Step 3. Next, run, sudo apt —fix-broken install - this should correct the partially installed package and finish the configuration steps as needed.
This is NOT good practise - should you have any system issues, boot back into to the ‘correct’ kernel (hold shift whilst booting for grub menu)
Step 4. reboot (you will need to disable secure boot if running mainline, unsigned kernels) - run uname -r to check which kernel is running - for me this is currently: 6.13.0-061300rc1-generic
You might be able to take the Debian backport packages here, otherwise the official solution is to build it yourself from the kernel sources.
https://help.ubuntu.com/community/UbuntuBackports
https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
1 Like
Gross. But I love it!
I can tell you what’s happening here, the Debian (and so Ubuntu) devs went through an arduous process of checking each and every lib to make sure they fully use 64-bit timestamps, that 32-bit timestamps weren’t being used internally (these roll over to “time 0”, January 1 1970, on January 19 2038). On 32-bit platforms this especially meant making sure the (non-traditional) 64-bit time type and calls are being used. So they added t64 (short for “time64”) to the names to make sure this had been done on everything.
In this case, libssl3 and libelf probably have no “64-bit time” related changes whatsoever, so whatever kernel build scripts etc. do want libssl3 and libelf aren’t going to care about having the “t64” version or not.
I was going to build a newer kernel from source – but I’m going to install with mainline and do this instead!
What kernel is the HWE kernel for Ubuntu on right now? HWE follows a rolling release and should have a recent kernel, supplied by Ubuntu.
If you’re on Ubuntu 24.04 then this is your command.
sudo apt install linux-generic-hwe-24.04
This is the simplest and easiest way to run the latest hardware on Ubuntu and what I did when I built my machine I am typing this on with a Ryzen 7950X and a 7900XTX shortly after they both released. This is the way Ubuntu deals with the specific problem of latest hardware on an LTS release.
It is 6.11, same as in 24.10. The next HWE kernel will be 6.14 in august(?)
They have probably backported the relevant driver(s) as ubuntu is maintaining it until the next HWE release.
If you want to be on the latest kernel now, I have found it easiest to use a custom kernel like liquorix or xanmod. Both support ubuntu LTS so there should be no dependency issues.
1 Like
Thanks for the answer. Personally, I don’t know why Ubuntu doesn’t use the yearly LTS kernels. That’s 6.12 until the end of this year. 6.11 just seems an odd choice.
They use whatever is the latest kernel that is out before the kernel freeze of whatever ubuntu release. Since the release is late october or late april, and the freeze is roughly a month before, the LTS kernel is never out in time for the fall release. They have used the previous years LTS kernel for the spring LTS releases before, like 5.4 (20.04) and 5.15 (22.04) but last time they opted for 6.8 presumable because it had important enough features compared to 6.6 (LTS).
Anyway it doesn’t really matter since they will always maintain it themselves for the lifetime of the ubuntu LTS release regardless. If you have older hardware, it is entirely reasonable to get a new kernel or graphics drivers every six months or so, as the hardware is already well supported. For fresh hardware tho, you can find support lagging behind even with the latest HWE or non-LTS ubuntu release.
Personally I have come to like this cadence and am accustomed to pacing my upgrades for after the release of the required kernels. I do find using a PPA for the latest stable Mesa drivers beneficial tho, even for older GPU’s, as there can be specific fixes for recent games for example, like the recent RT emulation patch for indiana jones on older AMD gpu’s like polaris.
I am aware, but I still think it’s an odd choice.