Hi Neil, Quoting Neil Williams (2017-10-04 19:27:43) > Setting up passwd (1:4.4-4.1) ... > duplicate group entry > delete line 'sbuild:x:121:neil'? No > group sbuild: no user neil > delete member 'neil'? No > duplicate group entry > delete line 'sbuild:x:121:neil'? No > group sbuild: no user neil > delete member 'neil'? No > grpck: no changes > Multiple entries named 'sbuild' in /etc/group. Please fix this with pwck or > grpck. > grpconv: failed to prepare the new /etc/group entry 'sbuild' > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault
This segfault also looks fishy... > /bin/chown: cannot access '/etc/gshadow': No such file or directory > /bin/chmod: cannot access '/etc/gshadow': No such file or directory > Please correct the error and rerun `/sbin/shadowconfig on' > dpkg: error processing package passwd (--configure): > subprocess installed post-installation script returned error exit status 1 > Setting up login (1:4.4-4.1) ... > dpkg: libuuid1:arm64: dependency problems, but configuring anyway as you > requested: > libuuid1:arm64 depends on passwd; however: > Package passwd is not configured yet. > > The line: > Multiple entries named 'sbuild' in /etc/group. Please fix this with pwck or > grpck. > would seem to indicate a problem within sbuild rather than debootstrap. Your conclusion might be correct. sbuild-createchroot fills /etc/group by running "getent group sbuild" on the parent system. The following output would be interesting to debug this further: - what you get when you run "getent group sbuild" yourself - the actual content of /etc/group inside the chroot Might it also be possible that chroot directory was not empty before you executed sbuild-createchroot? I'm just puzzled that this problem occurs when you use qemu-static and --foreign. It's a weird effect... Thanks! cheers, josch
signature.asc
Description: signature
