Introducing architecture variants: amd64v3 now available in Ubuntu 25.10

[zwede]

Ah, ok, so the kubuntu-backports PPA doesn’t have amd64v3 yet. Thanks.

[bobdenaut]

@zwede

I have Plasma/KDE installed from the kubuntu-backports PPA

can you please share how did you enabled/installed 6.5.1 ?
thanks

[mwhudson]

@grolongo

The example shows how to set it for amd64v3 but does it also work for v2 and v4 supported CPUs?

The machinery supports v2, v3, v4 but we are only building packages for v3 at this point.

@vidtek99

I’m confused, for a completely new install on bare metal, how will this be implemented? Will there be options in the opening screen to pick one? Will there be a test button for users who have no idea what a v1 v2 v3 etc is? Or perhaps a subroutine which will run first and decide for you?

For 26.04 the installer will be v1/baseline only. We definitely want people to be able to install the more modern variants right from the installer but exactly how we’ll do that is not completely clear at this point.

@zwede

So is there a way to get a list of all installed packages that are of the amd64v3 variant?

Something like dpkg --status | grep-dctrl -nsPackage -FArchitecture-Variant amd64v3 should do this.

[vidtek99]

So it’s early days yet, and lots of stuff to be decided, makes sense, thank you.

[mirabilos]

So, how does that work, package-wise, when I have a package with an architecture whitelist and architecture-specific tasks in debian/rules: do I double amd64 as amd64v3 everywhere like for all other architectures?

[zwede]

can you please share how did you enabled/installed 6.5.1 ?
thanks

sudo add-apt-repository ppa:kubuntu-ppa/backports

[bobdenaut]

@zwede

sudo add-apt-repository ppa:kubuntu-ppa/backports

yea, already did that and I cant upgrade:

liviu@bobdenaut:~$ sudo apt upgrade 
Not upgrading:                  
  breeze-cursor-theme  kde-style-breeze-data  libkpipewire-data  libplasma5support-data  powerdevil-data
  breeze-wallpaper     kwayland6-data         libkscreen-data    plasma-desktop-data
  kde-cli-tools-data   kwin-data              libksysguard-data  plasma-discover-common

Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 13

[fprietog]

There is a critical problem here. The security updates are not being offered if you have amd64v3 enabled and there is no amd64v3 package in the update.

Example: today’s security update for webkit2gtk package that don’t have amd64v3 version, only amd64.

With amd64v3 enabled and after issuing “apt update” there is no update available for that package. In fact “apt show” is showing the older version available:

# apt show libwebkitgtk-6.0-4
Package: libwebkitgtk-6.0-4
Version: 2.48.6-1ubuntu2
...

If you disable amd64v3 (i.e. issuing “mv /etc/apt/apt.conf.d/99enable-amd64v3 /etc/apt/apt.conf.d/~99enable-amd64v3”) after reissuing “apt update” the packages are offered and “apt show” is showing the newer version available:

# apt show libwebkitgtk-6.0-4
Package: libwebkitgtk-6.0-4
Version: 2.50.0-2ubuntu1
...

If you enabled amd64v3 again the update vanishes.

Sorry, but at this point I think it’s too early and very risky to stay with amd64v3 enabled.

[bobdenaut]

@fprietog

If you enabled amd64v3 again the update vanishes.

Sorry, but at this point I think it’s too early and very risky to stay with amd64v3 enabled.

True! That was preventing me to get KDE updates, I removed amd64v3 and the updates started to come.
Too soon for this feature!

[mwhudson]

@fprietog

Example: today’s security update for webkit2gtk package that don’t have amd64v3 version, only amd64.

On investigation this seems to have been the result of some confusing ordering issues around releasing packages from questing-proposed, opening resolute and fixing bugs that made Launchpad not trigger an amd64v3 build when it should have. We’ll get it sorted; it’s the sort of thing that shouldn’t happen once this is a properly supported feature.

@fprietog

Sorry, but at this point I think it’s too early and very risky to stay with amd64v3 enabled.

It’s totally fair to make this decision for yourself (amd64v3 in questing is definitely not as well tested as amd64!) but people trying this stuff out is how we find the problems so we can support it properly in 26.04!

@bobdenaut

True! That was preventing me to get KDE updates, I removed amd64v3 and the updates started to come.

This was something else I think; PPAs without amd64v3 enabled published empty package lists for amd64v3 which probably isn’t ideal. This is on my list of ‘variant loose ends’ that need fixing (although I’m not 100% sure what the way forward is here yet).

[bobdenaut]

@mwhudson

This was something else I think; PPAs without amd64v3 enabled published empty package lists for amd64v3 which probably isn’t ideal. This is on my list of ‘variant loose ends’ that need fixing (although I’m not 100% sure what the way forward is here yet).

also ubuntu-drivers stopped working (even I did rolled back from amd64v3 to amd64

liviu@bobdenaut:~$ ubuntu-drivers list
liviu@bobdenaut:~$ ubuntu-drivers devices
liviu@bobdenaut:~$ 

apt update also stopped woring unless you do:

sudo mv /etc/apt/apt.conf.d/50command-not-found /etc/apt/apt.conf.d/50command-not-found.disabled

[fprietog]

@mwhudson

It’s totally fair to make this decision for yourself (amd64v3 in questing is definitely not as well tested as amd64!) but people trying this stuff out is how we find the problems so we can support it properly in 26.04!

Ok, it’s understandable. I’m also (obviously) interested in having the most possible bug-free LTS so I will stay with amd64v3 enabled but taking special care of the possible missing updates.

I’ve redacted a procedure to make sure that no updates are lost in a system that have amd64v3 enabled. I’m sharing it in case other users want to make sure about their system status. Basically is just to compare the list of upgradable packets we get in the system without amd64v3 enabled with the list of installed amd64v3 packets to find differences between both lists.

This is the procedure:

1. Starting situation is amd64v3 enabled and no pending updates to install including phased ones.
2. Generate the list of installed amd64v3 packages and its versions in “/tmp/___pkg_ins.txt”:
   apt update
dpkg --status | grep-dctrl -nsPackage,Version -FArchitecture-Variant amd64v3 | tr "\n" " " | sed 's/ /\n/g' | sort > /tmp/___pkg_ins.txt
   Note: there will be two spaces between the slashes in sed 's/ / but discourse only print one. You need to add the missing space when copy the command.
3. Temporary disable amd64v3:
   mv /etc/apt/apt.conf.d/99enable-amd64v3 /etc/apt/apt.conf.d/~99enable-amd64v3
4. Generate the list of upgradable amd64 packages and its versions in “/tmp/___pkg_upd.txt”
   apt update
apt list --upgradable | cut -d " " -f 1-2 | sed 's/\/[^ ]*//' | sort > /tmp/___pkg_upd.txt
5. Compare both lists to find possible missing updates (*):
   comm -3 /tmp/___pkg_upd.txt /tmp/___pkg_ins.txt
6. Manual installation of the missing updates.
7. Re-enable amd64v3 and delete the temporary lists:
   mv /etc/apt/apt.conf.d/~99enable-amd64v3 /etc/apt/apt.conf.d/99enable-amd64v3
apt update
rm /tmp/___pkg_ins.txt /tmp/___pkg_upd.txt

(*) In my case I get this result:

# comm -3 /tmp/___pkg_upd.txt /tmp/___pkg_ins.txt
Listing...
gir1.2-javascriptcoregtk-4.1 2.50.0-2ubuntu1
gir1.2-javascriptcoregtk-6.0 2.50.0-2ubuntu1
gir1.2-webkit-6.0 2.50.0-2ubuntu1
gir1.2-webkit2-4.1 2.50.0-2ubuntu1
libjavascriptcoregtk-4.1-0 2.50.0-2ubuntu1
libjavascriptcoregtk-6.0-1 2.50.0-2ubuntu1
libwebkit2gtk-4.1-0 2.50.0-2ubuntu1
libwebkitgtk-6.0-4 2.50.0-2ubuntu1

These are the missing updates that I have to manually install. If you only get the word “Listing…” (depends of your system language) it means that everything seems to be up to date.

I’ve put it in a script to run it daily.

[pkgsivan]

I tried enabling the amd64v3 packages on my workstation. The setup was simple using the steps you outlined, and everything installed without errors.

So far, the system seems stable. I haven’t done detailed benchmarks, but compilation-heavy tasks feel a bit faster. It’s a subtle improvement, but noticeable for workloads like building from source.

One thing to be aware of: you can’t move the drive to older machines that don’t support x86-64-v3. That could be an issue if you plan to reuse drives across different systems.

Overall, the opt-in architecture variants work as described, and having the option to use optimized builds on modern CPUs is convenient.

[fprietog]

Today’s security update missed: poppler
Reason: amd64v3 build failed

Btw, previously detected packages with same problem are still broken:
bind9 libssh mutter rmlint samba xorg-server xwayland

Thanks and best regards.

[SEGFAULT]

I’m trying to find out to see which hardware was used for these testing.

I have an Intel Hades Canyon (i7-8809G) which supports v3 but REALLY doesn’t like these new binaries. It feels a lot slower when using remote VSCode (laggy).

Reverting it and updating (downdating?) all the packages again instantly fixes the issue.

The remote connection is done over SSH.

Anyway I can test this?

[teward]

Just 'cause I’m one of Those People, is amd64v3 being targeted for 26.04 as a fully supported and tested architecture, such that you’ll have dedicated architecture ISOs for it? Or will the standard amd64 ISOs make a decision based on output on what your system can or can’t support for it and selectively choose which amd64 variant to use?

[fprietog]

If its the second option it may be a pretty big ISO for offline installs.

I have a question too. I didn’t find remarkable improvements yet but I think that with a kernel compiled for amd64v3 there will be some. That’s the question: will be the kernels available for amd64v3?

I see that the current 26.04 available kernels are amd64 only and don’t see the point of having some parts of the OS for amd64v3 and the main part not.

[keithjh]

It appears there may be an issue with package rawtherapee as running rawtherapee or rawtherapee-cli resulted in a segfault after a fresh install, adding the variant line to config, and updating. More specifically, it appears to be in an interaction with libglibmm-2.4 (which does have a amd64v3 build).

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f3c168 in Glib::ustring::ustring(Glib::ustring const&) () from /lib/x86_64-linux-gnu/libglibmm-2.4.so.1
(gdb) disassemble
=> 0x00007ffff7f3c168 <+72>:	movzbl (%rsi),%eax
(gdb) p $rsi
$1 = 0

After a haphazard look around I have not noticed any other packages that depend on libglibmm-2.4 having any issues.

I suspect this same problem with rawtherapee impacted the recent phoronix benchmark where the speedup they observed could be the program crashing quickly.

[redwoodsec]

Is there any support for this in Resolute?