chroot/proc should be empty at the point where it tries to cache the bootstrapped filesystem it has built. the fact that it is not suggests something has clearly gone very wrong.
as you perhaps already know, running programs within a chroot environment typically requires first mounting /proc, /sys, and /dev/pts within the chroot. live-build makes use of a chroot during the build process, and these (and others) get mounted and unmounted at various points throughout the build. debootstrap is used early in the bootstrapping stage to construct the bootstrapped filesystem, and this itself mounts and unmounts these. live-build has a clean-up mechanism setup to try to catch failure and clean things up like unmounting those mount points when things go wrong. things can sometimes fail in such a way though that it cannot clean up and/or recover if you re-run it, in which case you need to scrap the build and try again afresh (with a clean directory). it is currently typically a good idea to always start afresh after a failure or cancelling to be certain that nothing is wrong (trying to make things more robust is part of the work i'm contributing). it would appear that somehow you have ended up in a situation where the chroot filesystem is getting saved as the cached bootstrap, while the mount points remain mounted, and so it is trying to copy a whole bunch of stuff that should not be copied (the contents of these mounts). with an essentially "corrupt" bootstrap filesystem then in your cache, all subsequent builds are thus going to be corrupt also, if they can even complete without error, (unless you bypass cache use as you found). to fix this you need to clean things up for a fresh start - delete the cached bootstrap! (sudo rm -rf cache/bootstrap). as for why on earth you're experiencing this on multiple machines... are you copying the build directory to them including the corrupt cached bootstrap? are you performing a common set of actions on them that could explain ending up with a corrupt bootstrap? On Tue, 2020-04-14 at 16:36 +0000, dbgr wrote: > Hello. > > I am using the live-build version 20191221 (the one in testing) on a > debian stable/buster system. > > Whenever I try to build an image (even the most basic with all the > default options) the live-build hangs trying to save the bootstrap > stage > to cache with the following messages: > > I: Base system installed successfully. > [2020-04-11 11:17:29] lb bootstrap_cache save > P: Saving bootstrap stage to cache... > cp: error reading 'chroot/proc/1/task/1/attr/prev': Ivalid > argument > cp: error reading 'chroot/proc/1/task/1/attr/exec': Ivalid > argument > cp: error reading 'chroot/proc/1/task/1/attr/fscreate': Ivalid > argument > cp: error reading 'chroot/proc/1/task/1/attr/keycreate': Ivalid > argument > cp: error reading 'chroot/proc/1/task/1/attr/sockcreate': Ivalid > argument > cp: error reading 'chroot/proc/1/task/1/mem': I/O error > cp: error reading 'chroot/proc/1/task/1/clear_refs': Ivalid > argument > > When this happens the ../cache/bootstrap/proc/1/task/1/pagemap file > starts to build up with garbage data until it runs my storage out of > space or until I stop the process with crtl+c. > > I believe this is related to the saving of the bootstrap stage to > cache > (besides the message saying so =P) because as soon I set the flag > --cache-stage deliberately stating to exclude this stage from > caching > (with an empty value or defining other stages) the issue do not > occur > and the build finishes without a problem. > > This also happens in other machines running debian stable/buster > with > this version of live-build and with the one in stable (20190311). > > Can anyone help me diagnose this problem? The possibility to cache > the > bootstrap stage would be very helpful for me :) > > Thanks for your attention. > > -- > > dbgr >
