Running a 32-bit host system in 20.04 is explicitly unsupported because running a 32-bit x86 kernel lacks significant security mitigations. We are providing 32-bit library compatibility for use on a 64-bit host only.
1 Like
About 32 bit security, people at kernel mailing list completely disagrees. Having vulnerability doesn’t mean entire arch is unusable. Debian still support 32 bit software. If you don’t want to support 32 bit that’s fine but don’t just blame on security.
Apart from that @willcooke did say that 32 bit netboot images will still be available, this is because it is sometimes impossible to compile 32 bit software or driver on 64 bit os because of missing path, improper packaging. We encounter issues like library not found, module not found etc even if 32 bit libraries are installed. That’s why we still need these libraries on focal.
Hello Discourse,
From your public announcement of this process being formed it stated little-used applications might go unknown so I have a list for your consideration.
The ‘application’ is CheckPoint’s SSL-based Network Extender (“SNX”), available as a Linux agnostic VPN client requiring what I debugged as being:
apt install lib32stdc++6 lib32z1 lib32readline7 lib32gcc1 libpam0g:i386 libstdc++5:i386 libx11-6:i386
(as documented here https://www.modiford.com/index.php/Ubuntu_18.04_CheckPoint_SNX for the benefit of other Ubuntu-using corporate firewall admins).
Thank you for your consideration,
Glyn B.,
One additional update, in the course of reviewing the dependencies of the libraries we are supporting, we’ve identified that the i386-only flashplugin-downloader package is a transitional package (and has been since 2012) so we are dropping this from the list.
It think it would be very useful to have the list of maintained / available i386 packages available on the release notes of all releases which no longer fully support i386, i.e. starting with https://wiki.ubuntu.com/EoanErmine/ReleaseNotes - could this be done? (And thanks in advance!)
I know I am a bit late here but today on a test installation of 20.04 where I follow the development cycle of the next lts version I noted that libnss-winbind:i386 was removed.
This test install is in fact in a active directory domain. Now if I create a new 32 bit wine prefix the uid to name resolution does not work anymore in 32 bit processes. In 64 bit prefixes the USERNAME variable gets populated correctly, but I guess since 32bit and 64bit processes now have a different view of the uid/gid to username/group mapping some applications might get confused.
My question is how is nss accounted in the selection of 32bit libraries. I see that libnss-mdns is available. Also every nss library that comes from systemd seems to be available as 32 bit.
I would suggest including every libnss-* that is in main. I think libpam-* can be ignored since I don’t think there is a 32 bit application around that uses this and is on the list of the still supported 32bit packages (i.e. I am not aware wine does this, which is probably the main reason we still stick with 32 bit)
p.s.: I opened a question here: https://answers.launchpad.net/ubuntu/+source/samba/+question/688146 where actionparsnip proposed filing a bug report.
But I don’t think this is not really a bug but more a decision that has to be made (maybe already done) if/what libnss packages should be availabe in i386
1 Like
please add pipewire to i386 support is needed because in version 0.3 included jack and pulsewrapper.
https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster
Please also add llvm10. Will be needed for mesa. Thanks.
This is a build dependency of mesa so does not need to be declared explicitly in our list. We will include whichever version of llvm is required by the libraries we are committed to shipping.
1 Like
libnss-winbind:i386 remains available
rmadison libnss-winbind -a i386
libnss-winbind | 2:4.1.6+dfsg-1ubuntu2 | trusty/universe | i386
libnss-winbind | 2:4.3.8+dfsg-0ubuntu1 | xenial/universe | i386
libnss-winbind | 2:4.3.11+dfsg-0ubuntu0.14.04.20 | trusty-security/universe | i386
libnss-winbind | 2:4.3.11+dfsg-0ubuntu0.14.04.20 | trusty-updates/universe | i386
libnss-winbind | 2:4.3.11+dfsg-0ubuntu0.16.04.25 | xenial-security/universe | i386
libnss-winbind | 2:4.3.11+dfsg-0ubuntu0.16.04.25 | xenial-updates/universe | i386
libnss-winbind | 2:4.7.6+dfsg~ubuntu-0ubuntu2 | bionic | i386
libnss-winbind | 2:4.7.6+dfsg~ubuntu-0ubuntu2.15 | bionic-security | i386
libnss-winbind | 2:4.7.6+dfsg~ubuntu-0ubuntu2.15 | bionic-updates | i386
libnss-winbind | 2:4.10.0+dfsg-0ubuntu2 | disco | i386
libnss-winbind | 2:4.10.0+dfsg-0ubuntu2.8 | disco-security | i386
libnss-winbind | 2:4.10.0+dfsg-0ubuntu2.8 | disco-updates | i386
libnss-winbind | 2:4.10.7+dfsg-0ubuntu2 | eoan | i386
libnss-winbind | 2:4.10.7+dfsg-0ubuntu2.4 | eoan-security | i386
libnss-winbind | 2:4.10.7+dfsg-0ubuntu2.4 | eoan-updates | i386
libnss-winbind | 2:4.11.5+dfsg-1ubuntu2 | focal | i386Actually, libnss-winbind has been readded on i386 in response to this request (and a matching bug report in launchpad). Apologies for not updating here that this was done!
2 Likes
Hello, please evaluate i965-va-driver-shaders for the 32 bit whitelist. This was mentioned at https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver-shaders/+bug/1864314 which is apparently the wrong place for 32 bit whitelist feedback.
3 Likes
Thanks, I’ve re-added the i386 binary to the focal archive.
3 Likes
libffi6:i386 is an install dependency for libllvm10:i386 but has been deleted from focal. This affects mesa and the steam client. I resolved the dependency by manually installing the package in disco PROPOSED:
The following packages have unmet dependencies:
libllvm10:i386 : Depends: libffi6:i386 (>= 3.0.4) but it is not installable
E: Unable to correct problems, you have held broken packages.
andrew@feynman:~/Downloads$ wget http://launchpadlibrarian.net/399281302/libffi6_3.2.1-9_i386.deb
[snip]
andrew@feynman:~/Downloads$ sudo dpkg -i ./libffi6_3.2.1-9_i386.deb
Selecting previously unselected package libffi6:i386.
(Reading database … 509107 files and directories currently installed.)
Preparing to unpack ./libffi6_3.2.1-9_i386.deb …
Unpacking libffi6:i386 (3.2.1-9) …
Setting up libffi6:i386 (3.2.1-9) …
Processing triggers for libc-bin (2.31-0ubuntu9) …
andrew@feynman:~/Downloads$
This is incorrect. The libllvm10:i386 package in Ubuntu focal depends on libffi7, not libffi6.
Thanks, yes, you’re quite right. The problem was one of my own making and I’ve now confirmed that the current libllvm10:386 does indeed depend on libffi7.
1 Like
I need libssl0.9.8 to be installable for some apps to work, such as Comodo Antivirus.
The last version of Ubuntu to include the (obsolete and insecure, by virtue of not supporting recent TLS protocols) libssl0.9.8 was Ubuntu 14.04. This is therefore out of scope for inclusion in Ubuntu 20.04’s i386 compatibility layer. You should not have trouble installing existing old i386 binary packages on your Ubuntu 20.04 system, but they are not included in 20.04.
1 Like
I’ve found a small packaging issue: the libsdl2-mixer-2.0-0 packages provided for Ubuntu 20.04 now depend on libopusfile0 but the 64-bit and 32-bit versions of libopusfile0 conflict with each other - as a result it is no longer possible to have both the 64-bit and 32-bit versions of libsdl2-mixer-2.0-0 installed at the same time.
Thank you for this information. This is out of scope of the question of which packages to support for i386. Please file a bug against opusfile with ubuntu-bug libopusfile0 for this issue.
1 Like