I wrote:
> When I tried [poplog] on a kernel based on 2.6.16-1 (still on FC 4) it
> would not start, repeatedly printing access violation messages until
> killed, which I assume is the same as the behaviour on FC 5.
>
> Suspecting that this could be due to yet more security changes made by
> RedHat as described in this file
>
> http://dag.wieers.com/howto/compatibility/
>
> rather than to kernel updates,
> .....
I fetched and compiled the latest stable linux kernel 2.6.16.5
and poplog worked.
> So I conclude that all our woes are due to security measures introduced
> by RedHat and inherited by Fedora Core, like the previous problem cured
> using
>
> sysctl kernel.randomize_va_space=0
Chris Dollin investigated and reported back
[CD]
> As well as
> kernel.randomize_va_space=0
>
> it appears we need
> kernel.exec-shield=0
>
> as things to change with sysctl, the latter presumably because Poplog's
> routine use of live-code generation doesn't fit their expectations.
>
> I can now get xved up. Hooray!
So I added that to /etc/sysctl.conf on my machine
# Prevent problems starting Poplog saved images
kernel.randomize_va_space=0
# Also needed for Poplog on FC 5, etc.
kernel.exec-shield=0
and booted up this kernel, on which poplog had previously looped out of
control:
2.6.16-1.2069_1.rhfc4.cubbi_swsusp2
Now it works for me too.
Thanks Chris.
That also presumably means it will be possible to rebuild poplog on the
latest versions of redhat and Fedora kernels, whereas previously
none of Poplog's system building tools worked on those kernels.
[Posting to pop-forum. Will automatically be forwarded to poplog-dev
as well as comp.lang.pop. Apologies to anyone who gets this twice.]
Aaron
http://www.cs.bham.ac.uk/~axs/
|