[ptxdist] ROOTDIR and image packages

[ptxdist] ROOTDIR and image packages

[Baeuerle, Florian]

Hello,

I making heavy use of image packages with collections. Some images select and
install packages that are in conflict with each other due to installing the same
file. This creates problems when they are targetinstalled to ROOTDIR
concurrently. I often get errors like this:

install alternative:
  src=foo/configs/platform-imx27/projectroot/etc/rauc/system.conf
  dst=/etc/rauc/system.conf
  owner=0 
  group=0 
  permissions=0644

chmod: cannot access '/home/jenkins/workspace/foo/platform-
imx27/root/etc/rauc/system.conf': No such file or directory
Error: install_alternative failed!

xpkg_finish: failed.

/home/jenkins/workspace/foo/configs/platform-imx27/rules/image-squashfs-
jaeger90-release.make:45: recipe for target
'/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs-jaeger90-
release.targetinstall' failed
make: *** [/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs-
jaeger90-release.targetinstall] Error 1
make: *** Waiting for unfinished jobs....

The same file is touched by the -devel package. I suppose that there is a race
condition between those two packages.

Please ignore the fact that I am creating and installing an extra package via an
image package, this works fine. The problem also exists for "normal" packages.


So my question is: How should that be fixed?

My proposals are:

1. Add an option to disable nfsroot / ROOTDIR
 -> Image packages can have their own exclusive nfsroot
 -> With image packages the contents of ROOTDIR are not really useful

2. Lock ROOTDIR similar as was done with sysroot in commit 82d0922
 -> Might slow down targetinstall for no use

3. Lock each and every file or directory
 -> Could be rather complex for no real use

Currently, I use something like "@sleep 3" in .targetinstall, but this just
sucks and it even fails sometimes.


- Florian
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] ROOTDIR and image packages

[Michael Olbrich]

Hi,

On Tue, Oct 16, 2018 at 12:31:52PM +0000, Baeuerle, Florian wrote:
> I making heavy use of image packages with collections. Some images select and
> install packages that are in conflict with each other due to installing the same
> file. This creates problems when they are targetinstalled to ROOTDIR
> concurrently. I often get errors like this:
> 
> install alternative:
>   src=foo/configs/platform-imx27/projectroot/etc/rauc/system.conf
>   dst=/etc/rauc/system.conf
>   owner=0 
>   group=0 
>   permissions=0644
> 
> chmod: cannot access '/home/jenkins/workspace/foo/platform-
> imx27/root/etc/rauc/system.conf': No such file or directory
> Error: install_alternative failed!
> 
> xpkg_finish: failed.
> 
> /home/jenkins/workspace/foo/configs/platform-imx27/rules/image-squashfs-
> jaeger90-release.make:45: recipe for target
> '/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs-jaeger90-
> release.targetinstall' failed
> make: *** [/home/jenkins/workspace/foo/platform-imx27/state/image-squashfs-
> jaeger90-release.targetinstall] Error 1
> make: *** Waiting for unfinished jobs....
> 
> The same file is touched by the -devel package. I suppose that there is a race
> condition between those two packages.
> 
> Please ignore the fact that I am creating and installing an extra package via an
> image package, this works fine. The problem also exists for "normal" packages.
> 
> 
> So my question is: How should that be fixed?
> 
> My proposals are:
> 
> 1. Add an option to disable nfsroot / ROOTDIR
>  -> Image packages can have their own exclusive nfsroot
>  -> With image packages the contents of ROOTDIR are not really useful

I would accept a patch for this.

> 2. Lock ROOTDIR similar as was done with sysroot in commit 82d0922
>  -> Might slow down targetinstall for no use

I think I can do some tests with this. To check what the impact is. For
sysroot I didn't meassure a difference, probably because it's I/O limited
anyways. It could be different here, because creating debug files happens
here too.

> 3. Lock each and every file or directory
>  -> Could be rather complex for no real use

We would need to rewrite the whole code: We need make all operations for a
file under the lock (install + chmod etc.). But that will include debug
file generation right now. And I think that would be the main benefit of
this version.

So probably 1. or 2.

> Currently, I use something like "@sleep 3" in .targetinstall, but this just
> sucks and it even fails sometimes.

I've added some extra dependencies among the targetinstall stages for stuff
like this. It's not so nice, because some pacakges are recreated
unnecessarily.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de