[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing amd64 netinst LUKS+LVM install broken



On 2024-04-10 at 02:39, Andrew M.A. Cater wrote:

> On Tue, Apr 09, 2024 at 05:51:26PM -0700, Craig Hesling wrote:
> 
>> Hi all,
>> 
>> I'm having an issue with the guided partitioner in the Debian
>> testing amd64 installer. Specifically, the "Guided - use entire
>> disk and set up encrypted LVM" errors out and emit the following
>> error message:
>> 
>> partman-lvm: pvcreate: error while loading shared libraries:
>> libaio.so.1: cannot open shared object file: No such file or
>> directory

The fact that this is libaio catches my eye.

> Hi,
> 
> I suspect that Debian Testing _might_ be uninstallable just at the
> moment. There's a large scale migration and change of packages (to do
> with securing a workable time implementation post-2038 and moving
> from 32 bit values).
> 
> That's taken a lot longer than expected: Debian Unstable and
> therefore Debian Testing have been hit. It's just possible that this
> library is caught up in the dependencies.

Yes, this is almost certainly what's going on. libaio is one of the
small handful of libraries (that I'm aware of) for which the 't64'
version of the package appears to have slipped through the cracks on the
measures being taken to prevent things from migrating to testing until
the transition is properly ready.

$ apt-cache search libaio
libaio-dev - Linux kernel AIO access library - development files
libaio1 - Linux kernel AIO access library - shared library
libaio1t64 - Linux kernel AIO access library - shared library


$ apt-cache search t64 | egrep '^lib[^ ]+t64 ' | cut -d ' ' -f 1
libfyba0t64
libglibmm-2.68-1t64
libaio1t64
libnetcdf19t64
libudns0t64

> This will resolve itself in due course - but it might be better to
> install a minimal stable and then upgrade to testing later.
> 
> Be aware also that the problematic version of xz libraries is also in
> Debian testing - someone else pointed this up the other day.

For some values of "the problematic version". The one that is *known* to
be backdoored has been reverted:

$ apt-cache policy xz-utils
xz-utils:
  Installed: 5.6.1+really5.4.5-1
  Candidate: 5.6.1+really5.4.5-1
  Version table:
 *** 5.6.1+really5.4.5-1 900
        900 http://ftp.us.debian.org/debian testing/main amd64 Packages
        100 /var/lib/dpkg/status

However, while the version reverted *to* in this case - 5.4.5 - is from
prior to the introduction of the known backdoor, it *is* from well after
the now-apparent bad actor began contributing to the upstream project,
and there is discussion of possibly needing to revert to as far back as
a 5.2.x version in order to be completely sure of not having any commits
that come from that bad actor.

(If there's a detail I've missed catching which would mean that any of
that is inaccurate, I would be pleased if someone would point it out to
me.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: