base-files: Removing obsolete file /tmp

[Bryan Evenson]

I know this question is specific to a single package, but I have a hunch it is because opkg is doing something different than the other package managers.  I'm on the dunfell branch for yocto, and I'm testing some updates from the tagged yocto-3.1.14 to some more recent updates this last week.  One of the commits updated glibc, so I have a lot of packages that updated.  During 'opkg upgrade' I saw the following messages:

Upgrading base-files from 3.0.14-r89.25 to 3.0.14-r89.26 on root.
Upgrading base-files (3.0.14) on root.
Removing obsolete file /tmp.

Opkg stores some files in /tmp during upgrade, which were all deleted when /tmp was removed during the base-files package upgrade.  Most of the packages then failed to upgrade.  They then upgraded correctly after I did 'opkg update; opkg upgrade'.  However, I don't understand why opkg decided to delete the /tmp directory during the base-files package upgrade.  I'd like to avoid that.

Between the two builds, there were no changes to the base-files recipe.  I ran 'opkg files base-files' both before and after upgrade and '/tmp' is listed in both.  The /tmp directory exists after base-files upgrades.  This is the only file or directory for the base-files package that opkg is declaring as obsolete.  Does someone know what is going on and how to possibly avoid this issue?

Thanks,

Bryan

[Bryan Evenson]

I see something different with /tmp that might be the issue.  /tmp is not a directory; it is a softlink to /var/tmp, which is then a softlink to /var/volatile/tmp, which is then a directory.  /tmp, /var/tmp and /var/volatile/tmp are all listed in the output from 'opkg files base-files'.  I've been trying to debug remove_obsolesced_files() in opkg_install.c, but I don't see any more verbose debug messages without adding my own and recompiling.  I thought hash_table_get() on line 719 would find /tmp but it appears that is not the case.  Any ideas on what else to try?

Thanks,

Bryan

[Bryan Evenson]

I have a little more information.  For the base-files ipk and for the created image, /tmp is a directory and not a softlink.  There are init scripts that will force /tmp to be a softlink to /var/tmp.  Is it possible this is causing problems for remove_obsolesced_files()?

Thanks,

Bryan

[Alex Stewart]

Hey Bryan,

For clarification: are you running into this issue when opkg is running
in a rootfs context in OE, or after booting into the built image?

On 2/28/22 14:30, Bryan Evenson wrote:
> I have a little more information.  For the base-files ipk and for the
> created image, /tmp is a directory and not a softlink.  There are init
> scripts that will force /tmp to be a softlink to /var/tmp.  Is it
> possible this is causing problems for remove_obsolesced_files()?

My reading of `remove_obsolesced_files()` suggests that it does not
consider link targets at all when determining if a file should be
removed (which seems reasonable). So presumably, `/tmp` being a link
shouldn't trigger its removal.

>
> Thanks,
> Bryan
>
> On Mon, Feb 28, 2022 at 8:38 AM Bryan Evenson <evenso...@gmail.com>
> wrote:
>
> I see something different with /tmp that might be the issue.  /tmp
> is not a directory; it is a softlink to /var/tmp, which is then a
> softlink to /var/volatile/tmp, which is then a directory.  /tmp,
> /var/tmp and /var/volatile/tmp are all listed in the output from
> 'opkg files base-files'.  I've been trying to debug
> remove_obsolesced_files() in opkg_install.c, but I don't see any
> more verbose debug messages without adding my own and
> recompiling.  I thought hash_table_get() on line 719 would find
> /tmp but it appears that is not the case.  Any ideas on what else
> to try?
>

I would have expected that as well. Line 708 in that function [1] has a
suspiscious `20` magic number in it that gets assigned to the
`n_buckets` property of the FILES hash table. I would have expected that
to be the size of the backing array used to resolve hash collisions in
the table.... But reading the hash table source has me thinking that it
might be being used to statically size the number of keys in the hash
table? I'm probably just rusty on my C and misinterpreting the data
structure, but its worth checking that opkg isn't trying to store FILE
lists into a 20-entry static hash table. Because if it is, I can see a
large package like base-files easily breaking that limit and then this
whole function would start behaving weirdly.

I think you need to compile in some debug statements and get an
understanding of the logic that opkg is testing in
`remove_obsolesced_files()`. One of the `if (new)... if (file_is_dir...
if (owner...` checks in there should be catching the similar path and
avoiding its deletion.

You might also learn something by trying to reproduce this error in a
test case. If it doesn't reproduce there, it points to something unique
about the `base-files` package or the OE built image.

> --
> You received this message because you are subscribed to the Google
> Groups "opkg-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opkg-devel+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opkg-devel/CAOfHXQzq2XYHCyZsuzkj9ZdwN%2Bs06%3DV0qfyB7xVUPy1s-LfDgw%40mail.gmail.com
> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/CAOfHXQzq2XYHCyZsuzkj9ZdwN*2Bs06*3DV0qfyB7xVUPy1s-LfDgw*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!FbZ0ZwI3Qg!8thyCf63rKiFyNGr80dVKvOhhCoNqXsODXoj2hzr64JdelXdiS82FPH7AcHgCZA$>.


[1]
https://git.yoctoproject.org/opkg/tree/libopkg/opkg_install.c?id=b52c702d0c6e00b3304ac26d517f9a93b63db1c8#n708


Hope that helps,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.s...@ni.com

[Bryan Evenson]

Alex,

On Monday, February 28, 2022 at 4:23:58 PM UTC-5 Alex Stewart wrote:

Hey Bryan,

For clarification: are you running into this issue when opkg is running
in a rootfs context in OE, or after booting into the built image?

I am running into this issue after booting into the built image.

I modified the base-files recipe so it created /tmp as a softlink to /var/tmp instead of a directory.  I verified that in the new image and in the new ipkg /tmp was a softlink to /var/tmp.  I then programmed my device with the image I had been using last week (before the base-files package tweaks).  I then attempted an upgrade with the base-files modifications and the upgrade worked without any issues.  I captured all the output from 'opkg upgrade' and I didn't see the 'Removing obsolete file /tmp' message anymore.  If /tmp was a softlink on disk but in the upgrade package /tmp is a directory, opkg is removing the 'obsolete' softlink and replacing it with a directory.  I may need to dive deeper into the Debian package management policy, but that sounds like correct behavior to me.  I suspect since opkg does not install the new files as early as other package managers that this issue may stay hidden with RPM.

Unless you have any other suggestions, I'm going to keep my changes for base-files and proceed with this change.

Thanks,

Bryan

[Alex Stewart]

On 3/1/22 11:44, Bryan Evenson wrote:
> I modified the base-files recipe so it created /tmp as a softlink to
> /var/tmp instead of a directory.  I verified that in the new image and
> in the new ipkg /tmp was a softlink to /var/tmp.  I then programmed my
> device with the image I had been using last week (before the
> base-files package tweaks). I then attempted an upgrade with the
> base-files modifications and the upgrade worked without any issues.  I
> captured all the output from 'opkg upgrade' and I didn't see the
> 'Removing obsolete file /tmp' message anymore.  If /tmp was a softlink
> on disk but in the upgrade package /tmp is a directory, opkg is
> removing the 'obsolete' softlink and replacing it with a directory.  I
> may need to dive deeper into the Debian package management policy, but
> that sounds like correct behavior to me.  I suspect since opkg does
> not install the new files as early as other package managers that this
> issue may stay hidden with RPM.

Hmm... that's interesting to learn. I agree; that seems to be reasonable
behavior from opkg. Though it also seems like the kind of nuance that a
packager would miss. :/

> Unless you have any other suggestions, I'm going to keep my changes
> for base-files and proceed with this change.

I don't have any further suggestions. If your workaround works for you,
then it works for me.

Thanks,