/usr/local contents removed after updates

[cmarcelo]

I've seen this happen now and then, after performing update manually and rebooting the machine.

Last update was from X to 25080. X is some release from the previous days (Sep 18 or Sep 17).

[phmccarty]

@cmarcelo I've run into this issue, too, but I think it's related to reboot, not update. I have seen my /usr/local/bin content get wiped as well, but only after a reboot.

[ahkok]

I tried several things, reboot, update, verify fix --picky, but the files under /usr/local that I have remain on the system.

[miguelinux]

I don't have this issue. what did you do before reboot?

[cmarcelo]

I haven't done nothing special between the update and reboot (just closing emacs and mutt processes). The files in question are in /usr/local/bin/ (the directory bin itself it's also removed).

For the record: got it again when updating this Monday (I rebooted just after the update).

[cmarcelo]

OK. At least for this last instance, I know what might have happened:

.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin
.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin/kata-collect-data.sh
.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin/kata-runtime

Sometime in the past we mistakenly shipped extra stuff in /usr/local, and now we are deleting it.

[cmarcelo]

$ swupd-inspector cat clear/25470 Manifest.full | grep /usr/local
D...	6c27df6efcd6fc401ff1bc67c970b83eef115f6473db4fb9d57e5de317eba96e	25440	/usr/local
.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin
.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin/kata-collect-data.sh
.d..	0000000000000000000000000000000000000000000000000000000000000000	25440	/usr/local/bin/kata-runtime
D...	6c27df6efcd6fc401ff1bc67c970b83eef115f6473db4fb9d57e5de317eba96e	25440	/usr/local/share

[ahkok]

looks like 25080 and 25440 both had these files.

We should be able to reproduce this, then, and, of course, if this is actually the cause of other files being deleted, that needs to be fixed.

[ahkok]

@clearlinux/swupd-team

[cmarcelo]

These files are in containers-virt bundle, so it seems everytime that bundle gets update, we get the issue. That would explain why the issue only happens "now and then".

[ahkok]

And not for me - I never had that bundle installed.

[fenrus75]

we need to do to /usr/local to what we do with kernels... never do a "d"

…

On Tue, Oct 9, 2018 at 5:00 AM ahkok ***@***.***> wrote: And not for me - I never had that bundle installed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#206 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPeFa1IAnacTff837uZqvTnGMp8M-yIks5ui7zdgaJpZM4Ww5_A> .

[cmarcelo]

Reproduction steps follow, 25440 will bring a new version of the deleted file.

# swupd-extract clear/25430 containers-virt
# mkdir output/usr/local/bin
# touch output/usr/local/bin/hello
# swupd update --statedir $PWD/swupd-state --path output -m 25440 --no-scripts --no-boot-update
# file output/usr/local/bin/hello

Both hello and the bin directory will be missing after the update. You can use the swupd client for the first step too, just fix the update call accordingly.

[phmccarty]

@cmarcelo I think this is a mixer bug... The deleted file versions should not be updated as part of a minversion bump, ever. I will file a bug.

[phmccarty]

Bug filed: clearlinux/mixer-tools#455

[cmarcelo]

@phmccarty thanks for filing that. The mixer issue you raise aggravates this issue. But I think it is possible the issue could've occurred at the first version the file was deleted (no minversions involved).

Regardless of that, Clear Linux currently has a content bug: we shouldn't be shipping anything to /usr/local, and not marking anything as deleted.

[phmccarty]

@cmarcelo Yes, it would have happened for the first version at which the file was deleted, too. You're right.

[phmccarty]

The mixer considerations for /usr/local are currently tracked at clearlinux/mixer-tools#548. Please follow up on that issue if there are any missing details.

I am tracking this issue as a bug in the common developer tooling, as it should check generated RPMs for blacklisted paths, and exit with an error in this case. The location of the blacklist should also be made configurable.

[phmccarty]

I decided to open a new feature request for clearlinux/common instead. See clearlinux/common#11

Closing