[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#560127: freebsd-utils: Mounting /sys unconditionally breaks pbuilder --create



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).

Mraw,
KiBi.



Reply to: