Latest systemd packages: The following packages have Bad Signatures:

Just found out that the latest systemd and basesystem packages made it to main-updates without proper signatures:

The following packages have bad signatures:
/var/cache/urpmi/rpms/basesystem-3-3-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:19:38 PM CST, Key ID eb37e64917d8c628))
/var/cache/urpmi/rpms/basesystem-minimal-3-3-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:19:38 PM CST, Key ID eb37e64917d8c628))
/var/cache/urpmi/rpms/lib64nss_myhostname2-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:41 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/lib64nss_resolve2-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:41 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/lib64nss_systemd2-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:42 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/lib64systemd0-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:41 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:23 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-bash-completion-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:42 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-boot-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:36 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-console-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:36 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-coredump-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:36 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-doc-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:36 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-hwdb-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:37 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-locale-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:40 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-polkit-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:40 AM CST, Key ID 410c21abc2e8ddbe))
/var/cache/urpmi/rpms/systemd-zsh-completion-236-1-omv2015.0.x86_64.rpm: Invalid Key ID (OK (RSA/SHA1, Thu 21 Dec 2017 02:49:42 AM CST, Key ID 410c21abc2e8ddbe))
Do you want to continue installation ? (y/N)

Can file a bug report if needed.

Edit: This should probably be labled attention: @TPG

1 Like

I’ll take a look on this soon.

By now, all but one package already have “good” signatures. The one still left is,

basesystem-minimal-3-3-omv2015.0.x86_64.rpm

Just to report a sad outcome.

I installed the new systemd packages, then applied the trick of installing lib64udev-devel to overcome the difficulties with systemd-doc package and updated the whole systes (105 packages).

I have two computers, both returned a black screen after rebooting, the laptop is now working after XFdrake reconfiguration, the desktop no longer boot. On recovery mode, it keeps on producing logs (more than 12 hours by now!) that barely resembles a disk integrity test.

The desktop has a windows 8 in dual boot and it still seems to work.
I will try the OMV LX installation disk in live mode soon, maybe there is still something I can do.

You should not apply any kind of “tricks”.

Problem of lib64udev-devel is descibed here https://forum3.openmandriva.org/t/systemd-doc-236-1-conflicts-with-lib64udev-devel/1588/6?u=tpg

This is where I got the “trick”.

Tried reinstalling from OMV LX 3.02 iso. It seems the SSD device is bad.

Here’s one just for fun:

A requested package cannot be installed:
systemd-doc-236-2-omv2015.0.x86_64 (due to conflicts with lib64udev-devel-236-2-omv2015.0.x86_64)
Continue installation anyway? (Y/n)

But:

# rpm -qa systemd-doc
systemd-doc-236-2-omv2015.0.x86_64

So if a package is already installed how can it be a requested package that can’t be installed??? Is urpmi lying to us? Obviously it can be installed because it is installed.

I do not understand the behaviour of systemd-doc. I have updated systemd a couple of times to 236-2 and systemd-doc is updated on the first pass of urpmi, but removed during the second pass. But I can then re-install systemd-doc.

The problem with systemd-doc is still on. Just tried to install in another computer …

Can’t confirm that. Please provide urpmi logs with debug enabled.

The attachment outputurpmi.txt (80,8 KB)
is the output of

$ LC_ALL=C urpmi --debug --auto-update --wget

Thanks. Please make sure you do not have any i586 rpm packages already installed

rpm -qa | grep i586

I’ll verify soon. By now let me say that this is fresh install of LX 3.03 where I have just “removed unused packages” and installed thunderbird + thunderbird locale. That is to say, any i586 package are likely installed since LX installation.

For some mistake of mine, the last post did not go about 8 hours ago…

No, there’s no i586 package.

It seems that I have to use that “trick” (installing lib64udev-devel) to overcome this problem.

New updates and still I can’t proceed with systemd-doc unless I apply the “trick” provided by Ben79.

Found the real culprit. New systemd is bulding now.
https://forum3.openmandriva.org/t/systemd-doc-236-1-conflicts-with-lib64udev-devel/1588/5