On 01/07/2011 09:25 PM, Gordan Bobic wrote:
On 01/07/2011 08:27 PM, Andy Green wrote:
> On 01/07/11 20:17, Somebody in the thread at some point said:
>> On 01/07/2011 08:13 PM, Andy Green wrote:
>>
>>>> counters haven't increased at all, my guess is that it all happened
>>>> last
>>>> night when I was building/testing dietlibc stuff. I'll test that
>>>> hypothesis when the new kernel is built.
>>>
>>> Fine but what has happened with your sha512sum then?
>>
>> That didn't cause thousands of errors, only a handful - it wasn't being
>> used much. The only thing I can think if that could have produced that
>
> So both sha512sum binaries are giving correct results now or what?
No. The broken one is still broken if I disable alignment fix-ups.
>> may alignment errors (and segfaults to go with them, as it happens) was
>> what I was doing with dietlibc.
>>
>>> Is it the case that
>>> somehow the shared libc in memory is the dietlibc one? Maybe if you
>>> reboot without touching anything that touches dietlibc you won't see
>>> this issue again and the whole thing is a painful lesson to leave
>>> dietlibc the hell alone ^^
>>
>> I don't really see how. As I said, dietlibc is long uninstalled and the
>> boot-up still trips this 24+1 times. I think the coreutils bug was a
>> separate one. Now I just need to find what is causing the remaining few
>> alignment issues.
>
> What you should do about that is set
>
> alignment=3
>
> on your kernel commandline. That'll then be the default reaction to the
> alignment fault and it should give some logging about who is the process
> with the alignment faults.
Ooo, thanks for that. :)
I've attached the dmesg output.
All the errors on boot seem to be coming from
/lib/udev/devkit-disks-part-id.
# rpm -qf /lib/udev/devkit-disks-part-id
DeviceKit-disks-009-3.fc12.armv5tel
yum updating this (and the 13 dependencies it has) from the F13
repository doesn't make the problem go away. :(
Thankfully, though, nothing on the Sheeva uses this. I'll try rebuilding
the latest version of DeviceKit from source and see if that makes the
problem go away.
Bah. The F14 DeviceKit src.rpm doesn't build. :(
/usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/../../../libgirepository-1.0.so:
undefined reference to `g_malloc0_n'
collect2: ld returned 1 exit status
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 38, in <module>
sys.exit(scanner_main(sys.argv))
File "/usr/lib/python2.6/site-packages/giscanner/scannermain.py",
line 313, in scanner_main
glibtransformer.get_get_type_functions())
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
231, in compile_introspection_binary
return dc.run()
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
132, in run
self._link(bin_path, o_path)
File "/usr/lib/python2.6/site-packages/giscanner/dumper.py", line
226, in _link
subprocess.check_call(args)
File "/usr/lib/python2.6/subprocess.py", line 488, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/bin/sh', '../libtool',
'--mode=link', '--tag=CC', '--silent', 'gcc',
'-o',
'/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0',
'-O2', '-g', '-march=armv5te', '-L.',
'libdevkit-power-gobject.la',
'-pthread', '-Wl,--export-dynamic', '-lgio-2.0',
'-lgirepository-1.0',
'-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt',
'-lffi',
'-lglib-2.0',
'/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject/tmp-introspectz_WQKT/DeviceKitPowerGlib-1.0.o']'
returned non-zero exit status 1
make[2]: *** [DeviceKitPowerGlib-1.0.gir] Error 1
make[2]: Leaving directory
`/usr/src/redhat/BUILD/UPower-0.9.0/devkit-power-gobject'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/UPower-0.9.0'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.C7DE1t (%build)
In the end, I just gave up and did
rpm -e DeviceKit-disks since I don't actually need it. Works fine now,
but it looks like DeviceKit needs fixing.
Gordan