On Jan 16, 2014, at 8:33 AM, nonamedotc <nonamedotc@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx>
>>> wrote:
>>>
>>>>
>>>> On Jan 16, 2014, at 7:14 AM, Dan Mossor <dan.mossor@xxxxxxxxxxx> 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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
