Opened 2 years ago

Last modified 6 days ago

#15068 new bug

[packagefs] Cannot handle package activations with identical names

Reported by: waddlesplash Owned by: bonefish
Priority: high Milestone: R1/beta4
Component: File Systems/packagefs Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13574, #15207, #15576, #16573
Platform: All

Description

If you try to update or activate a package with an identical name (including revision) to an installed package, this occurs:

[system] Applying changes ...
*** failed to commit transaction: Failed to change the package activation in packagefs: Name in use

That's because of this code in packagefs.

Probably solving the TODO about looking packages up by node_ref rather than name would fix this.

Change History (34)

comment:1 by waddlesplash, 2 years ago

Blocking: 13574 added

comment:2 by waddlesplash, 2 years ago

Blocking: 15207 added

comment:3 by diver, 19 months ago

Blocking: 15576 added

comment:4 by diver, 15 months ago

Milestone: UnscheduledR1/beta2

Would be nice to fix before beta2 as it might prevent system updates.

comment:5 by pulkomandy, 14 months ago

System updates always come with a different version or revision number so they are not affected. Only trying to reinstall an already installed package will fail.

comment:6 by diver, 14 months ago

Still this is somehow happens: after a fresh install pkgman tries to update a selection of packages with the ones with the same name.

comment:7 by waddlesplash, 14 months ago

IIRC it was hard to get this problem to reproduce in the past; so are you saying this always reproduces under a beta2 image?

comment:8 by diver, 14 months ago

I haven't tried beta2 images yet but I could reproduce it easily using nightlies after a fresh install.

comment:9 by waddlesplash, 14 months ago

OK, then we should at least investigate why this occurs and fix that bug. It is indeed extremely odd.

comment:10 by Forza, 14 months ago

Hello,

This problem happens with the beta2 release-candidate too (haiku-r1beta2-hrev54154_107-x86_64-anyboot.zip) Currently, every time I make a clean install and run the sw updater.

https://paste.tnonline.net/files/vNna30rJuAt6_haiku-update-fails-on-clean-install.png

comment:11 by waddlesplash, 14 months ago

Can you please run "pkgman full-sync" in a Terminal, and paste the output of what it says it is going to do here?

comment:12 by waddlesplash, 14 months ago

Milestone: R1/beta2

Ticket retargeted after milestone closed

comment:13 by waddlesplash, 14 months ago

Milestone: R1/beta3

in reply to:  10 comment:14 by nielx, 12 months ago

Replying to Forza:

Hello,

This problem happens with the beta2 release-candidate too (haiku-r1beta2-hrev54154_107-x86_64-anyboot.zip) Currently, every time I make a clean install and run the sw updater.

https://paste.tnonline.net/files/vNna30rJuAt6_haiku-update-fails-on-clean-install.png

I think you were running into #16092 instead. Installer did not properly do a clean install and makes a mess of the package directory.

comment:15 by mmu_man, 12 months ago

Well this always happens when I full-sync after pushing a recipe to HaikuPorts with a package I built and install myself for testing. It tries to replace the one I built (with me as packager) with the one from HP, which has the exact same version. So it's quite easy to reproduce : build any package yourself and install it, then try to full-sync.

comment:16 by mmu_man, 12 months ago

Here it does this:

The following changes will be made:
  in system:
    upgrade package ocp_x86-0.2.2-1 to 0.2.2-1 from repository HaikuPorts
Continue? [yes/no] (yes) : 
100% ocp_x86-0.2.2-1-x86_gcc2.hpkg [4.53 Mio]
Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/master/x86_gcc2/current/packages/ocp_x86-0.2.2-1-x86_gcc2.hpkg...done.
[system] Applying changes ...
*** failed to commit transaction: Failed to change the package activation in packagefs: Name in use

comment:17 by mmu_man, 12 months ago

Admittedly it shouldn't happen with non-dev users who don't build their own packages.

comment:18 by pulkomandy, 12 months ago

I suspect this could be related to the problem in haikuports, where if you fix a requires or provide and rebuild a recipe, it will fail to activate in the chroot?

comment:19 by pulkomandy, 10 months ago

Priority: normalhigh

comment:20 by pulkomandy, 10 months ago

Bumping priority because this makes using haikuports annoying.

I guess packagefs is right to complain that another package with the same name is activated, but should notice that it is going to be replaced?

I guess one option is to make sure the "change activation" request sent to packagefs has the disabling of the old package first, and enabling of the new one only after that? Or it should be a "reactivate package" instead of an "activate package"? In which case the linked code for packagefs would be ok, and the problem would be in the package daemon instead. And indeed the daemon does activation first, then deactivation, and never uses the "reactivate package" code.

Last edited 10 months ago by pulkomandy (previous) (diff)

comment:21 by waddlesplash, 9 months ago

Blocking: 16573 added

comment:22 by kallisti5, 9 months ago

"the problem in haikuports"

aka endless loop of:

waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated
waiting for build package XXX to be activated

Just mentioning it here to make the error searchable :-)

comment:23 by stippi, 7 months ago

I've run into this, and think I am providing a correct fix with this changeset:

https://review.haiku-os.org/c/haiku/+/3597

Please have a look.

in reply to:  20 comment:24 by stippi, 7 months ago

Replying to pulkomandy:

I guess packagefs is right to complain that another package with the same name is activated, but should notice that it is going to be replaced?

The "Name in use" error, as far as I can tell, is from the FS layer. So this shouldn't be about updating a package with the "same name", the issue is replacing a package file with an identical copy from a new transaction.

I guess one option is to make sure the "change activation" request sent to packagefs has the disabling of the old package first, and enabling of the new one only after that? Or it should be a "reactivate package" instead of an "activate package"? In which case the linked code for packagefs would be ok, and the problem would be in the package daemon instead. And indeed the daemon does activation first, then deactivation, and never uses the "reactivate package" code.

I am not sure this has anything to do with packagefs. The error I saw is from the package server, which is responsible for committing one transaction at a time only (among other things). I think there may be other situations why a package file exists already in the packages folder, but one situation how this can form is when there are two concurrent transactions started, both of which depend on the same missing package. So it will be part of both transactions, one of them will be committed first, so the package file will be present at the time the second transactions is committed.

comment:25 by pulkomandy, 7 months ago

Yes, now that I see your change proposal it makes sense, and it's a much simpler explanation. Looking at problems from another perspective seems to help :)

Thanks for investigating this and finding the actual problem!

comment:26 by stippi, 7 months ago

Looking at the ticket description, the original error seems to have to do with packagefs (at the linked code). There seem to be two separate problems, I have fixed only one of them. What I fixed was during commiting the transaction.

comment:27 by stippi, 7 months ago

I mean, both problems would be during committing a transaction... but I don't remember my error to mention packagefs.

comment:28 by stippi, 7 months ago

One package I was able to reproduce this with (my version of the problem) was VLC, with pretty much nothing else installed. If memory serves.

comment:29 by pulkomandy, 7 months ago

The change by stippi has been merged. The remaining part of this is a regression caused by hrev51233, which attempts to overwrite a package without removing it first. That approach is not correct, so I think hrev51233 should be reverted and the initial problem from #10038 fixed in a different way, probably by having the package server synchronize better with packagefs and do not try to resolve dependencies while a transaction is being applied?

comment:30 by pulkomandy, 6 months ago

I cannot reproduce the original issue nor the haikuports one. Is it ok to fix this after stippi's fixes, or are there remaining problems?

comment:31 by waddlesplash, 6 months ago

Can you reproduce it by copying a file out of /system/packages (preserving it as exactly named there) and then trying to "pkgman install" that file?

comment:32 by nielx, 4 months ago

Another bump: is this issue still reproducible on recent nightlies?

comment:33 by waddlesplash, 4 months ago

packagefs was never fixed to solve the underlying problem, so while pkgman may not trigger the bug most of the time, it is still definitely there.

comment:34 by pulkomandy, 6 days ago

Milestone: R1/beta3R1/beta4

Move unsolved issues to beta 4 since there is no chance of fixing them now.

Note: See TracTickets for help on using tickets.