Re: Overview over my outstanding patches

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 24 May 2018 17:02:09 +0200
schrieb "[ext] Claudius Heine" <claudius.heine.ext@siemens.com>:

> On 2018-05-24 16:52, Jan Kiszka wrote:
> > On 2018-05-24 16:50, Claudius Heine wrote:  
> >> Hi Jan,
> >>
> >> On 2018-05-24 15:38, Jan Kiszka wrote:  
> >>> On 2018-05-24 15:34, [ext] Claudius Heine wrote:  
> >>>> Hi,
> >>>>
> >>>> On 2018-05-24 11:21, [ext] Claudius Heine wrote:  
> >>>>> Hi Alex,
> >>>>>
> >>>>> On 2018-05-14 15:47, Alexander Smirnov wrote:  
> >>>>>> Remaining:
> >>>>>> ==========
> >>>>>>     - meta-isar/isar-image-base: added removal of qemu-*-static
> >>>>>> binaries:
> >>>>>>
> >>>>>> Here is the question about case, when user wants to install
> >>>>>> qemu-user-static package to target rootfs.  
> >>>>>
> >>>>> If the user wants to install qemu-user-static to the image, apt
> >>>>> overwrites the one already there and then the linux kernel
> >>>>> complains about infinite symlink since it wants to execute the
> >>>>> new foreign 'qemu-*-static' binary with the foreign
> >>>>> 'qemu-*-static' binary on and on.
> >>>>>
> >>>>> Installing qemu-user-static is simply forbidden until
> >>>>> qemu-debootstrap changes the deployment path and binfmt
> >>>>> settings to avoid this conflict.  
> >>>>
> >>>> With Hennings help we further investigated this. The binfmt_misc
> >>>> flag 'F' would prevent this issue [1]. So installing
> >>>> qemu-user-static could be possible if that flag is used.  
> >>>
> >>> Do we have that under our control, or would we have to patch the
> >>> upstream binfmt debian package to tune that flag?  
> >>
> >> I have to investigate that. On my sid debian host that flag was
> >> set. I think I can see this in the diff between
> >> the /var/lib/binfmts/qemu-arm from the kas container and my host:
> >>
> >> --- kas-qemu-arm    2018-05-24 16:48:31.998958282 +0200
> >> +++ /var/lib/binfmts/qemu-arm    2018-05-22 15:02:13.580660019
> >> +0200 @@ -7,3 +7,4 @@
> >>
> >>   yes
> >>
> >> +yes
> >>
> >> I suppose this yes is were the 'F' flag is set. Currently I don't
> >> know how those files are generated. I can take a look into it.  
> > 
> > There is the binfmt-support package, and its update-binfmts seems
> > to set that stuff.  
> 
> This I know. But were are those qemu configurations defined? Is there
> a way to overwrite them in order to update those flags? I will have
> to investigate how to do that. Maybe we can patch this into those kas 
> containers.

I am not sure the benefit is really worth the complexity. If we mess
with binfmt in the containers, one will need to build using this
container. And the host might end up in a state it does not expect.
And all for installing a package that probably nobody wants.

Deleting the qemu is important, for size and clearing reasons.

Henning

> Claudius
>