On Fri, Jan 27, 2017 at 05:23:39PM +0000, Thorsten Glaser wrote: > Guido GЭnther dixit: > >On Fri, Jan 27, 2017 at 04:40:13PM +0000, Thorsten Glaser wrote: > >> Guido Gц╪nther dixit: > >> > >> ># echo $? > >> >139 > >> > >> That is signal 11, i.e. segfault; is your RAM good? > > > >It sure is. ButБ─╕ > > > >with 0.228.3: > > > > Jan 27 15:52:23 bogon kernel: dpkg-architectu[13253] vsyscall attempted > > with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffc46aa0158 > > ax:ffffffffff600400 si:0 di:1f38590 > > Jan 27 15:52:47 bogon kernel: dpkg-architectu[13345] vsyscall attempted > > with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffeae684aa8 > > ax:ffffffffff600400 si:0 di:dfe590 > > Ah. This is documented though, I’ve even added it here: > > | http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/pbuilderrc?rev=HEAD
and reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849572 > > # To use a chroot with glibc 2.13 or older (Debian wheezy or older) > # with Linux 4.8 or up, you may need to add this to /etc/default/grub: > # GRUB_CMDLINE_LINUX="rootdelay=5 syscall.x32=y vsyscall=emulate > net.ifnames=0 kaslr" > # (well, the “vsyscall=emulate” part, although the others don’t hurt) > > >This was reported properly as http download error (since apt noticed > >that it's helper died) in 0.227. But 0.228.3 simply dies without any > >hint what the error could be and where it happened to the user. It would > >be great if pbuilder would at least print the command that failed. > > Agreed. I’d lower the severity since apparently, the vsyscall=none > switch was reverted (especially as wheezy is still very much in use). I'll let the maintainers decide if they want to treat is as a regression or enhancement / wishlist bug . Cheers, -- Guido

