Prelink problem

Prelink problem

[Andrej Valek]

Hi Ross,

I would like to ask You a question about your commit, which removed
prelink dependency
(http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/insane.bbclass?h=thud&id=659c8b5267dc2220f67bfcb4ae2df91ae5052cdc).
Is it really necessary to remove the QADEPENDS = "prelink-native"?

I was trying to build extensible SDK with multilib support, but without
success. Here is the crash log:

     0709:        if not os.path.exists(prelink_cfg):

     0710:
shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),

 *** 0711:                        prelink_cfg)

     0712:

     0713:        cmd_prelink =
self.d.expand('${STAGING_DIR_NATIVE}${sbindir_native}/prelink')

     0714:        self._exec_shell_cmd([cmd_prelink,

     0715:                              '--root',

File: '/usr/lib/python3.5/shutil.py', lineno: 241, function: copy

     0237:

     0238:    """

     0239:    if os.path.isdir(dst):

     0240:        dst = os.path.join(dst, os.path.basename(src))

 *** 0241:    copyfile(src, dst, follow_symlinks=follow_symlinks)

     0242:    copymode(src, dst, follow_symlinks=follow_symlinks)

     0243:    return dst

     0244:

     0245:def copy2(src, dst, *, follow_symlinks=True):

File: '/usr/lib/python3.5/shutil.py', lineno: 120, function: copyfile

     0116:

     0117:    if not follow_symlinks and os.path.islink(src):

     0118:        os.symlink(os.readlink(src), dst)

     0119:    else:

 *** 0120:        with open(src, 'rb') as fsrc:

     0121:            with open(dst, 'wb') as fdst:

     0122:                copyfileobj(fsrc, fdst)

     0123:    return dst

     0124:

Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/home/.../1.0-r0/recipe-sysroot-native/etc/prelink.conf'


It points into meta/lib/oe/rootfs.py:705

if not os.path.exists(prelink_cfg):

shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),prelink_cfg)


How it's possible to copy non-existing file, because of removed
prelink-native dependency.

Do I need to explicitly inherit some class, let say image-prelink?
What am I doing wrong?

Regards,
Andrej

Re: Prelink problem

[Burton, Ross]

That patch removed the dependency on the QA, but your failure is at rootfs time.

No idea why the opkg rootfs code is doing prelink operations when RPM
or dpkg don't.   CCing Mark who may have an idea here.  I thought the
autobuilder exerised multilib-on-opkg, but maybe not.

Ross

On Tue, 8 Jan 2019 at 07:14, Andrej Valek <andrej.valek@siemens.com> wrote:
>
> Hi Ross,
>
> I would like to ask You a question about your commit, which removed
> prelink dependency
> (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/insane.bbclass?h=thud&id=659c8b5267dc2220f67bfcb4ae2df91ae5052cdc).
> Is it really necessary to remove the QADEPENDS = "prelink-native"?
>
> I was trying to build extensible SDK with multilib support, but without
> success. Here is the crash log:
>
>      0709:        if not os.path.exists(prelink_cfg):
>
>      0710:
> shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),
>
>  *** 0711:                        prelink_cfg)
>
>      0712:
>
>      0713:        cmd_prelink =
> self.d.expand('${STAGING_DIR_NATIVE}${sbindir_native}/prelink')
>
>      0714:        self._exec_shell_cmd([cmd_prelink,
>
>      0715:                              '--root',
>
> File: '/usr/lib/python3.5/shutil.py', lineno: 241, function: copy
>
>      0237:
>
>      0238:    """
>
>      0239:    if os.path.isdir(dst):
>
>      0240:        dst = os.path.join(dst, os.path.basename(src))
>
>  *** 0241:    copyfile(src, dst, follow_symlinks=follow_symlinks)
>
>      0242:    copymode(src, dst, follow_symlinks=follow_symlinks)
>
>      0243:    return dst
>
>      0244:
>
>      0245:def copy2(src, dst, *, follow_symlinks=True):
>
> File: '/usr/lib/python3.5/shutil.py', lineno: 120, function: copyfile
>
>      0116:
>
>      0117:    if not follow_symlinks and os.path.islink(src):
>
>      0118:        os.symlink(os.readlink(src), dst)
>
>      0119:    else:
>
>  *** 0120:        with open(src, 'rb') as fsrc:
>
>      0121:            with open(dst, 'wb') as fdst:
>
>      0122:                copyfileobj(fsrc, fdst)
>
>      0123:    return dst
>
>      0124:
>
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/.../1.0-r0/recipe-sysroot-native/etc/prelink.conf'
>
>
> It points into meta/lib/oe/rootfs.py:705
>
> if not os.path.exists(prelink_cfg):
>
> shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),prelink_cfg)
>
>
> How it's possible to copy non-existing file, because of removed
> prelink-native dependency.
>
> Do I need to explicitly inherit some class, let say image-prelink?
> What am I doing wrong?
>
> Regards,
> Andrej

Re: Prelink problem

[Mark Hatle]

On 1/8/19 6:27 AM, Burton, Ross wrote:
> That patch removed the dependency on the QA, but your failure is at rootfs time.
> 
> No idea why the opkg rootfs code is doing prelink operations when RPM
> or dpkg don't.   CCing Mark who may have an idea here.  I thought the
> autobuilder exerised multilib-on-opkg, but maybe not.

They all should be doing prelink operations.  The operation SHOULD be
generically implemented as part of the image-prelink class, which is where I
would have expected that copy to exist.

If any of the package types of specifically doing something, that sounds
broken...  but the generic ones (last I looked) said to copy in the config file
[if it didn't exist], run prelink, remove the file [if it wasn't there to start
with].

--Mark

> Ross
> 
> On Tue, 8 Jan 2019 at 07:14, Andrej Valek <andrej.valek@siemens.com> wrote:
>>
>> Hi Ross,
>>
>> I would like to ask You a question about your commit, which removed
>> prelink dependency
>> (http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/insane.bbclass?h=thud&id=659c8b5267dc2220f67bfcb4ae2df91ae5052cdc).
>> Is it really necessary to remove the QADEPENDS = "prelink-native"?
>>
>> I was trying to build extensible SDK with multilib support, but without
>> success. Here is the crash log:
>>
>>      0709:        if not os.path.exists(prelink_cfg):
>>
>>      0710:
>> shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),
>>
>>  *** 0711:                        prelink_cfg)
>>
>>      0712:
>>
>>      0713:        cmd_prelink =
>> self.d.expand('${STAGING_DIR_NATIVE}${sbindir_native}/prelink')
>>
>>      0714:        self._exec_shell_cmd([cmd_prelink,
>>
>>      0715:                              '--root',
>>
>> File: '/usr/lib/python3.5/shutil.py', lineno: 241, function: copy
>>
>>      0237:
>>
>>      0238:    """
>>
>>      0239:    if os.path.isdir(dst):
>>
>>      0240:        dst = os.path.join(dst, os.path.basename(src))
>>
>>  *** 0241:    copyfile(src, dst, follow_symlinks=follow_symlinks)
>>
>>      0242:    copymode(src, dst, follow_symlinks=follow_symlinks)
>>
>>      0243:    return dst
>>
>>      0244:
>>
>>      0245:def copy2(src, dst, *, follow_symlinks=True):
>>
>> File: '/usr/lib/python3.5/shutil.py', lineno: 120, function: copyfile
>>
>>      0116:
>>
>>      0117:    if not follow_symlinks and os.path.islink(src):
>>
>>      0118:        os.symlink(os.readlink(src), dst)
>>
>>      0119:    else:
>>
>>  *** 0120:        with open(src, 'rb') as fsrc:
>>
>>      0121:            with open(dst, 'wb') as fdst:
>>
>>      0122:                copyfileobj(fsrc, fdst)
>>
>>      0123:    return dst
>>
>>      0124:
>>
>> Exception: FileNotFoundError: [Errno 2] No such file or directory:
>> '/home/.../1.0-r0/recipe-sysroot-native/etc/prelink.conf'
>>
>>
>> It points into meta/lib/oe/rootfs.py:705
>>
>> if not os.path.exists(prelink_cfg):
>>
>> shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),prelink_cfg)
>>
>>
>> How it's possible to copy non-existing file, because of removed
>> prelink-native dependency.
>>
>> Do I need to explicitly inherit some class, let say image-prelink?
>> What am I doing wrong?
>>
>> Regards,
>> Andrej

Re: Prelink problem

[Burton, Ross]

On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com> wrote:
> > No idea why the opkg rootfs code is doing prelink operations when RPM
> > or dpkg don't.   CCing Mark who may have an idea here.  I thought the
> > autobuilder exerised multilib-on-opkg, but maybe not.
>
> They all should be doing prelink operations.  The operation SHOULD be
> generically implemented as part of the image-prelink class, which is where I
> would have expected that copy to exist.
>
> If any of the package types of specifically doing something, that sounds
> broken...  but the generic ones (last I looked) said to copy in the config file
> [if it didn't exist], run prelink, remove the file [if it wasn't there to start
> with].

Note that it's part of the incremental code, so needs to be in the
rootfs code directly I suspect. Frankly I'd love to see incremental
images removed.  It makes promises it can't keep (the moment a rootfs
postprocess command is used, all bets are off) and massively
complicates things.

Ross

Re: Prelink problem

[Mark Hatle]

On 1/8/19 2:37 PM, Burton, Ross wrote:
> On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> No idea why the opkg rootfs code is doing prelink operations when RPM
>>> or dpkg don't.   CCing Mark who may have an idea here.  I thought the
>>> autobuilder exerised multilib-on-opkg, but maybe not.
>>
>> They all should be doing prelink operations.  The operation SHOULD be
>> generically implemented as part of the image-prelink class, which is where I
>> would have expected that copy to exist.
>>
>> If any of the package types of specifically doing something, that sounds
>> broken...  but the generic ones (last I looked) said to copy in the config file
>> [if it didn't exist], run prelink, remove the file [if it wasn't there to start
>> with].
> 
> Note that it's part of the incremental code, so needs to be in the
> rootfs code directly I suspect. Frankly I'd love to see incremental
> images removed.  It makes promises it can't keep (the moment a rootfs
> postprocess command is used, all bets are off) and massively
> complicates things.

We assume the post process command is what an 'admin' would do.  So the various
package managers should be able to deal with it in most cases.  (Note, obviously
it's more freeform, but I wouldn't expect everything to work in you removed a
large part of the filesystem for instance.)

As for prelink, I'm surprised this is in the incremental code.  I'm not sure why
it would be necessary unless the incremental work wants to UNPRELINK the rootfs
before performing the upgrade?

Prelink itself should still be run as a postprocess command that takes the
output of the filesystem and reprocesses it.

So something seems out of sync here.. (at a minimum probably should be better
commented on why it's needed..)

--Mark

> Ross
> 

Re: Prelink problem

[Richard Purdie]

On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote:
> On 1/8/19 2:37 PM, Burton, Ross wrote:
> > On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com>
> > wrote:
> > > > No idea why the opkg rootfs code is doing prelink operations
> > > > when RPM
> > > > or dpkg don't.   CCing Mark who may have an idea here.  I
> > > > thought the
> > > > autobuilder exerised multilib-on-opkg, but maybe not.
> > > 
> > > They all should be doing prelink operations.  The operation
> > > SHOULD be
> > > generically implemented as part of the image-prelink class, which
> > > is where I
> > > would have expected that copy to exist.
> > > 
> > > If any of the package types of specifically doing something, that
> > > sounds
> > > broken...  but the generic ones (last I looked) said to copy in
> > > the config file
> > > [if it didn't exist], run prelink, remove the file [if it wasn't
> > > there to start
> > > with].
> > 
> > Note that it's part of the incremental code, so needs to be in the
> > rootfs code directly I suspect. Frankly I'd love to see incremental
> > images removed.  It makes promises it can't keep (the moment a
> > rootfs
> > postprocess command is used, all bets are off) and massively
> > complicates things.
> 
> We assume the post process command is what an 'admin' would do.  So
> the various
> package managers should be able to deal with it in most
> cases.  (Note, obviously
> it's more freeform, but I wouldn't expect everything to work in you
> removed a
> large part of the filesystem for instance.)
> 
> As for prelink, I'm surprised this is in the incremental code.  I'm
> not sure why
> it would be necessary unless the incremental work wants to UNPRELINK
> the rootfs
> before performing the upgrade?
> 
> Prelink itself should still be run as a postprocess command that
> takes the
> output of the filesystem and reprocesses it.
> 
> So something seems out of sync here.. (at a minimum probably should
> be better
> commented on why it's needed..)

The code is there for incremental opkg multilib image support. Its
trying to compare whether binaries are identical. To make it work, it
has to "unprelink" the files first before comparing.

I'm not convinced this is a good idea :/. I'm wondering if incremental
image generation makes sense at all in this context to be honest.

Cheers,

Richard

Re: Prelink problem

[Andrej Valek]

Hi all

Do we found some solution? As a workaround could be just add dependency
to prelink native into rootfs if the command is really required.

Regards,
Andrej

On 1/8/19 10:46 PM, Richard Purdie wrote:
> On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote:
>> On 1/8/19 2:37 PM, Burton, Ross wrote:
>>> On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com>
>>> wrote:
>>>>> No idea why the opkg rootfs code is doing prelink operations
>>>>> when RPM
>>>>> or dpkg don't.   CCing Mark who may have an idea here.  I
>>>>> thought the
>>>>> autobuilder exerised multilib-on-opkg, but maybe not.
>>>>
>>>> They all should be doing prelink operations.  The operation
>>>> SHOULD be
>>>> generically implemented as part of the image-prelink class, which
>>>> is where I
>>>> would have expected that copy to exist.
>>>>
>>>> If any of the package types of specifically doing something, that
>>>> sounds
>>>> broken...  but the generic ones (last I looked) said to copy in
>>>> the config file
>>>> [if it didn't exist], run prelink, remove the file [if it wasn't
>>>> there to start
>>>> with].
>>>
>>> Note that it's part of the incremental code, so needs to be in the
>>> rootfs code directly I suspect. Frankly I'd love to see incremental
>>> images removed.  It makes promises it can't keep (the moment a
>>> rootfs
>>> postprocess command is used, all bets are off) and massively
>>> complicates things.
>>
>> We assume the post process command is what an 'admin' would do.  So
>> the various
>> package managers should be able to deal with it in most
>> cases.  (Note, obviously
>> it's more freeform, but I wouldn't expect everything to work in you
>> removed a
>> large part of the filesystem for instance.)
>>
>> As for prelink, I'm surprised this is in the incremental code.  I'm
>> not sure why
>> it would be necessary unless the incremental work wants to UNPRELINK
>> the rootfs
>> before performing the upgrade?
>>
>> Prelink itself should still be run as a postprocess command that
>> takes the
>> output of the filesystem and reprocesses it.
>>
>> So something seems out of sync here.. (at a minimum probably should
>> be better
>> commented on why it's needed..)
> 
> The code is there for incremental opkg multilib image support. Its
> trying to compare whether binaries are identical. To make it work, it
> has to "unprelink" the files first before comparing.
> 
> I'm not convinced this is a good idea :/. I'm wondering if incremental
> image generation makes sense at all in this context to be honest.
> 
> Cheers,
> 
> Richard
> 

Re: Prelink problem

[Mark Hatle]

On 1/16/19 1:23 AM, Andrej Valek wrote:
> Hi all
> 
> Do we found some solution? As a workaround could be just add dependency
> to prelink native into rootfs if the command is really required.

If the image stuff needs prelink, there should be a dependency in place.  It
should only use prelink if the image-prelink is being used.

So really something probably needs to be added to image-prelink class that
activates unprelink behavior with opkg, and adds the necessary dependency.

--Mark

> Regards,
> Andrej
> 
> On 1/8/19 10:46 PM, Richard Purdie wrote:
>> On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote:
>>> On 1/8/19 2:37 PM, Burton, Ross wrote:
>>>> On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com>
>>>> wrote:
>>>>>> No idea why the opkg rootfs code is doing prelink operations
>>>>>> when RPM
>>>>>> or dpkg don't.   CCing Mark who may have an idea here.  I
>>>>>> thought the
>>>>>> autobuilder exerised multilib-on-opkg, but maybe not.
>>>>>
>>>>> They all should be doing prelink operations.  The operation
>>>>> SHOULD be
>>>>> generically implemented as part of the image-prelink class, which
>>>>> is where I
>>>>> would have expected that copy to exist.
>>>>>
>>>>> If any of the package types of specifically doing something, that
>>>>> sounds
>>>>> broken...  but the generic ones (last I looked) said to copy in
>>>>> the config file
>>>>> [if it didn't exist], run prelink, remove the file [if it wasn't
>>>>> there to start
>>>>> with].
>>>>
>>>> Note that it's part of the incremental code, so needs to be in the
>>>> rootfs code directly I suspect. Frankly I'd love to see incremental
>>>> images removed.  It makes promises it can't keep (the moment a
>>>> rootfs
>>>> postprocess command is used, all bets are off) and massively
>>>> complicates things.
>>>
>>> We assume the post process command is what an 'admin' would do.  So
>>> the various
>>> package managers should be able to deal with it in most
>>> cases.  (Note, obviously
>>> it's more freeform, but I wouldn't expect everything to work in you
>>> removed a
>>> large part of the filesystem for instance.)
>>>
>>> As for prelink, I'm surprised this is in the incremental code.  I'm
>>> not sure why
>>> it would be necessary unless the incremental work wants to UNPRELINK
>>> the rootfs
>>> before performing the upgrade?
>>>
>>> Prelink itself should still be run as a postprocess command that
>>> takes the
>>> output of the filesystem and reprocesses it.
>>>
>>> So something seems out of sync here.. (at a minimum probably should
>>> be better
>>> commented on why it's needed..)
>>
>> The code is there for incremental opkg multilib image support. Its
>> trying to compare whether binaries are identical. To make it work, it
>> has to "unprelink" the files first before comparing.
>>
>> I'm not convinced this is a good idea :/. I'm wondering if incremental
>> image generation makes sense at all in this context to be honest.
>>
>> Cheers,
>>
>> Richard
>>

Re: Prelink problem

[Andrej Valek]

Hi Hongxu Jia!

I have found, that You have implemented this prelink mechanism regarding
to multilib.
Are you sure, that these changes are required?
If yes, is it possible to add somehow dependency to prelink-native? Or
move it into image-prelink.bbclass.

Just for the information, I have build a general image without including
any prelink stuff.

Regards,
Andrej

On 1/16/19 4:57 PM, Mark Hatle wrote:
> On 1/16/19 1:23 AM, Andrej Valek wrote:
>> Hi all
>>
>> Do we found some solution? As a workaround could be just add dependency
>> to prelink native into rootfs if the command is really required.
> 
> If the image stuff needs prelink, there should be a dependency in place.  It
> should only use prelink if the image-prelink is being used.
> 
> So really something probably needs to be added to image-prelink class that
> activates unprelink behavior with opkg, and adds the necessary dependency.
> 
> --Mark
> 
>> Regards,
>> Andrej
>>
>> On 1/8/19 10:46 PM, Richard Purdie wrote:
>>> On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote:
>>>> On 1/8/19 2:37 PM, Burton, Ross wrote:
>>>>> On Tue, 8 Jan 2019 at 20:15, Mark Hatle <mark.hatle@windriver.com>
>>>>> wrote:
>>>>>>> No idea why the opkg rootfs code is doing prelink operations
>>>>>>> when RPM
>>>>>>> or dpkg don't.   CCing Mark who may have an idea here.  I
>>>>>>> thought the
>>>>>>> autobuilder exerised multilib-on-opkg, but maybe not.
>>>>>>
>>>>>> They all should be doing prelink operations.  The operation
>>>>>> SHOULD be
>>>>>> generically implemented as part of the image-prelink class, which
>>>>>> is where I
>>>>>> would have expected that copy to exist.
>>>>>>
>>>>>> If any of the package types of specifically doing something, that
>>>>>> sounds
>>>>>> broken...  but the generic ones (last I looked) said to copy in
>>>>>> the config file
>>>>>> [if it didn't exist], run prelink, remove the file [if it wasn't
>>>>>> there to start
>>>>>> with].
>>>>>
>>>>> Note that it's part of the incremental code, so needs to be in the
>>>>> rootfs code directly I suspect. Frankly I'd love to see incremental
>>>>> images removed.  It makes promises it can't keep (the moment a
>>>>> rootfs
>>>>> postprocess command is used, all bets are off) and massively
>>>>> complicates things.
>>>>
>>>> We assume the post process command is what an 'admin' would do.  So
>>>> the various
>>>> package managers should be able to deal with it in most
>>>> cases.  (Note, obviously
>>>> it's more freeform, but I wouldn't expect everything to work in you
>>>> removed a
>>>> large part of the filesystem for instance.)
>>>>
>>>> As for prelink, I'm surprised this is in the incremental code.  I'm
>>>> not sure why
>>>> it would be necessary unless the incremental work wants to UNPRELINK
>>>> the rootfs
>>>> before performing the upgrade?
>>>>
>>>> Prelink itself should still be run as a postprocess command that
>>>> takes the
>>>> output of the filesystem and reprocesses it.
>>>>
>>>> So something seems out of sync here.. (at a minimum probably should
>>>> be better
>>>> commented on why it's needed..)
>>>
>>> The code is there for incremental opkg multilib image support. Its
>>> trying to compare whether binaries are identical. To make it work, it
>>> has to "unprelink" the files first before comparing.
>>>
>>> I'm not convinced this is a good idea :/. I'm wondering if incremental
>>> image generation makes sense at all in this context to be honest.
>>>
>>> Cheers,
>>>
>>> Richard
>>>
> 

[PATCH] lib/oe/rootfs: prelink only when image-prelink is inherited

[Andrej Valek]

Use prelink only when image-prelink class is inherited. Inheriting this
class adds prelink-native as dependency to do_rootfs, which makes prelink
binary and configuration available.

|Exception: FileNotFoundError: [Errno 2] No such file or directory:
|'/home/.../1.0-r0/recipe-sysroot-native/etc/prelink.conf'
|
| if not os.path.exists(prelink_cfg):
|     shutil.copy(self.d.expand('${STAGING_DIR_NATIVE}${sysconfdir_native}/prelink.conf'),prelink_cfg)

Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
---
 meta/lib/oe/rootfs.py | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 551dcfc75f..ffbd1438aa 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -747,15 +747,16 @@ class OpkgRootfs(DpkgOpkgRootfs):
         if filecmp.cmp(f1, f2):
             return True
 
-        if self.image_rootfs not in f1:
-            self._prelink_file(f1.replace(key, ''), f1)
+        if bb.data.inherits_class('image-prelink', self.d):
+            if self.image_rootfs not in f1:
+                self._prelink_file(f1.replace(key, ''), f1)
 
-        if self.image_rootfs not in f2:
-            self._prelink_file(f2.replace(key, ''), f2)
+            if self.image_rootfs not in f2:
+                self._prelink_file(f2.replace(key, ''), f2)
 
-        # Both of them are prelinked
-        if filecmp.cmp(f1, f2):
-            return True
+            # Both of them are prelinked
+            if filecmp.cmp(f1, f2):
+                return True
 
         # Not equal
         return False
-- 
2.11.0