Cyril Brulebois a écrit : > Package: freebsd-utils > Version: 8.0-1 > Severity: important > > Hi, > > “pbuilder --create” is broken, presumably since the switch to 8.x > kernels, since: > - current version with kernel 8.x is broken; > - previous versions (even lenny's) with kernel 8.x are broken, while I > it was working fine a few months back, using 7.x kernels. > > I'm not certain I can switch kernels with my (remote) porter box so I > can't tell for sure, but that sounds like something possible. > > The actual failure: > | I: creating base tarball [/var/cache/pbuilder/base.tgz] > | tar: sys/devices/pci0000\:00/0000\:00\:1f.3: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1f.2/host1: file changed as we read > it > | tar: sys/devices/pci0000\:00/0000\:00\:1f.2: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1f.1/host0: file changed as we read > it > | tar: sys/devices/pci0000\:00/0000\:00\:1f.1: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1f.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1e.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1d.7: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1d.3: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1d.2: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1d.1: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1d.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1c.2/0000\:05\:00.0: file changed as > we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1c.2: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1c.1/0000\:04\:00.0: file changed as > we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1c.1: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:1c.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:02.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:01.0/0000\:01\:00.1: file changed as > we read it > | tar: sys/devices/pci0000\:00/0000\:00\:01.0/0000\:01\:00.0: file changed as > we read it > | tar: sys/devices/pci0000\:00/0000\:00\:01.0: file changed as we read it > | tar: sys/devices/pci0000\:00/0000\:00\:00.0: file changed as we read it > | tar: sys/devices/pci0000\:00: file changed as we read it > | tar: sys/devices: file changed as we read it > | tar: sys/class/scsi_host/host1/proc_name: file changed as we read it > | tar: sys/class/scsi_host/host1: file changed as we read it > | tar: sys/class/scsi_host/host0/proc_name: file changed as we read it > | tar: sys/class/scsi_host/host0: file changed as we read it > | tar: sys/class/scsi_host: file changed as we read it > | tar: sys/class: file changed as we read it > | tar: sys: file changed as we read it > | E: failed building base tarball > > Workaround for the current situation: Interrupting (C-z) “pbuilder > --create” once freebsd-utils's postinst has been run, chrooting there, > umounting /sys, and resuming (fg) makes it possible to create a pbuilder > base system successfully. > > A few solutions I can think of: > - maybe ask pbuilder folks to exclude the sys directory when creating > the base tarball. > - maybe mount /sys conditionally. I'm not sure what could be checked > (in this very case, there's /debootstrap/ around, with e.g. > debootstrap.log inside), but then, it could break d-i or such stuff > where one would want various stuff to be mounted. I think this leads > us back to the idea of having a tool telling us whether we're in the > chroot, and of which type, brought up a few weeks/months ago. > > I guess the first option could be fine, without too many side-effects, > and probably accepted. I can't really imagine what interesting stuff in > /sys could be needed in base.tgz but I might be lacking imagination. :) > > In the meanwhile, opening a bug against freebsd-utils since its mounting > /sys unconditionally seems like the culprit at the moment, let's keep it > around until a proper solution is found. > > Just as a reminder, freebsd-utils's postinst calls invoke-rc.d, and > there's no policy-rc.d to deny its being started when creating a chroot > (IIRC sbuild creates one, but after installing the basic chroot).
Given that on GNU/Linux /etc/init.d/mountkernfs also mounts /sys, we should try to understand why there is no problem there, and use the same solution. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
