On Thu, 30.10.14 07:57, Dave Reisner ([email protected]) wrote: > On Thu, Oct 30, 2014 at 12:39:53PM +0100, Lennart Poettering wrote: > > On Wed, 29.10.14 21:02, Dave Reisner ([email protected]) wrote: > > > > > On Wed, Oct 29, 2014 at 11:55:29PM +0100, Lennart Poettering wrote: > > > > On Wed, 29.10.14 14:29, Cristian Rodríguez ([email protected]) > > > > wrote: > > > > > > > > > Add syscall numbers for 32 bit x86 and arm and Correct > > > > > the system call number for x86_64 (it is 318 not 278) > > > > > > > > Hmm? I did my testing on x86_64 3.18rc2, 278 is what worked > > > > here... Did you test 318? Where does that number come from? > > > > > > I didn't see Cristian's patch and committed this: > > > > > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=74a550c > > > > Humm? Did you test it with that? I tested it on my 3.18 with 278, and > > it worked fine. > > > > Sure did. A value of 278 leads me to a unusuable nspawn binary and an > unbootable system. After my change to 318, nspawn works again, and I can > boot. > > Where did you get this value from? How did you test it? My hypothesis: > your kernel API headers are from 3.17 and provide a definition of > __NR_getrandom. Therefore, this fallback was never picked up from > configure.ac in your test build.
Oh, indeed. That explains it! Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
