On Jan 16, 2014, at 8:33 AM, nonamedotc <nonamedotc(a)fedoraproject.org> wrote:
On 01/16/2014 09:22 AM, Dan Mossor wrote:
>
>
> On 01/16/2014 08:49 AM, Chris Murphy wrote:
>>
>> On Jan 16, 2014, at 7:44 AM, Chris Murphy <lists(a)colorremedies.com>
>> wrote:
>>
>>>
>>> On Jan 16, 2014, at 7:14 AM, Dan Mossor <dan.mossor(a)outlook.com>
wrote:
>>>
>>>>
>>>>
>>>> On 01/16/2014 01:10 AM, Ankur Sinha wrote:
>>>>> There's something off somewhere. I just fresh installed from the
>>>>> Alpha USB
>>>>> stick I had. I ran a dnf update which went OK, other than the
usbmuxd
>>>>> scriptlet failure which iirc is a known issue. After that, I got
>>>>> down to
>>>>> installing my other packages and I get quite a few scriptlet
>>>>> failures now:
>>>>>
>>>>> 1 warning: %post(perl-libs-4:5.18.2-289.fc20.x86_64) scriptlet
>>>>> failed,
>>>>> exit status 127
>>>>>
>>>>> <Snipped>
>>>>
>>>> I ran into this problem yesterday myself on a fresh install. It
>>>> first cropped up during the update to KDE 4.12, and I asked Rex
>>>> Dieter in the KDE channel about it. I managed to copy the output
>>>> from the sddm install, and this is our brief convo about it. He
>>>> seems to think it is a systemd problem:
>>>>
>>>> [12:05] <danofsatx> Non-fatal POSTIN scriptlet failure in rpm
>>>> package sddm-0.2.0-16.20130914git50ca5b20,fc29,x86_64
>>>> [12:05] * rdieter checks sddm packaging
>>>> [12:06] <danofsatx> warning:
>>>> %post(sddm-0.2.0-16.20130914git50ca5b20,fc29.x86_64) scriptlet
>>>> failed, exit status 127
>>>> [12:06] <rdieter> odd, looks like systemd's fault
>>>> [12:06] <rdieter> it just has: %systemd_post sddm.service
>>>> [12:07] <rdieter> hrm, maybe missing runtime dep
>>>> [12:07] <rdieter> nope, %{?systemd_requires}
>>>> [12:08] <rdieter> wierd
>>>>
>>>> I did a final update last night to bring everything up to speed with
>>>> the updates-testing repo enabled, and got this output - it's too
>>>> much to paste in the email so it's on paste.fedora:
>>>>
http://paste.fedoraproject.org/68957/89881516/
>>>>
>>>> Summarization: I'm getting A LOT of scriptlet failures with exit
>>>> status 127. Any clues what that exit status means, and what's
broken?
>>>
>>> Me too. It can't be systemd-208-11 because I don't have that
>>> installed, I still have the original one F20 installs with which is
>>> 208-9. I haven't tracked down what's causing this but it must be
>>> something in u-t.
>>
>> Who having this problem has *NOT* been using dnf?
>>
>> Chris Murphy
>>
> I forgot to mention that - I haven't typed the letters dnf at all on
> this system until I wrote this email.
>
> Yum is what I know, yum is what I use.
>
> Also forgot to mention that I have systemd-208-9.fc20.x86_64
>
I am not sure if dnf is the problem here. I updated my system yesterday using dnf and
(thankfully?) did not see this problem. Just for comparison, here is a subset of packages
I have in commmon with Ankur's list -
# rpm -qa NetworkManager qt selinux-policy libreoffice firewalld firewall-config
initscripts | sort
firewall-config-0.3.9-1.fc20.noarch
firewalld-0.3.9-1.fc20.noarch
initscripts-9.51-1.fc20.x86_64
NetworkManager-0.9.9.0-24.git20131003.fc20.x86_64
qt-4.8.5-14.fc20.x86_64
selinux-policy-3.12.1-116.fc20.noarch
For the sake of completeness, I run XFCE here and my systemd is systemd-208-9.fc20.x86_64
I don't think it's selinux because I ausearch -m AVC hasn't report anything
for me in three days. I'm suspicious of initscripts though.
Right now, dnf update produces only one suggested operation which is the removal of a
rawhide kernel (this on an F20 system with u-t enabled, nothing else is rawhide). The
operation fails to remove the suggested kernel.
If I strace, I get a bunch of stuff I don't understand that doesn't help me locate
the problem. Unexpected, and maybe unrelated is that there are hundreds to thousands of
these types of entries:
stat("/var/lib/dnf/yumdb/a/c0223d2705904a638d59a893efc153228c03e68c-augeas-libs-1.1.0-2.fc20-x86_64/checksum_type",
0x7ffff2087b30) = -1 ENOENT (No such file or directory)
So there's a stat in the dnf yum database for some package that ends in ENOENT. Is
that normal? Is the database stale?
I'm going to do a rollback and see if updating initscripts is the source of this
problem.
Chris Murphy