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

Re: Cannot cache bootstrap stage of live-build - cp error reading chroot/proc/1/task/1/* - invalid argument



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
> 


Reply to: