[package_daemon] failed to remove transaction directory: Directory not empty

[diver]

hrev47395.

package_daemon failes to activate a package If for some reason there is a leftover settings directory.

Took me quite some time to figure out why my package didn't want to activate, because when installed manually there is no error in syslog.

To reproduce:

pkgman uninstall man
rm -rf /system/packages/administrative/writable-files/man-1.6g-4
mkdir -p /system/packages/administrative/writable-files/man-1.6g-4
pkgman install man

[waddlesplash]

Just got this after a normal pkgman update, I didn't have to "rm -rf" any files.

[system] Applying changes ...
[system] Changes applied. Old activation state backed up in ""
[system] Cleaning up ...
failed to remove transaction directory: Directory not empty
[system] Done.

And it looks like the "transaction-1" directory is indeed not empty:

drwxr-xr-x 1 user root     2048 2014-07-15 10:28 .
drwxr-xr-x 1 user root     4096 2014-07-15 10:26 ..
-rw-r--r-- 1 user root  3139219 2014-07-15 10:28 haiku_devel-r1~alpha4_pm_hrev47498-1-x86_gcc2.hpkg
-rw-r--r-- 1 user root   312344 2014-07-15 10:28 haiku_loader-r1~alpha4_pm_hrev47498-1-x86_gcc2.hpkg
-rw-r--r-- 1 user root   595057 2014-07-15 10:28 haiku_x86_devel-r1~alpha4_pm_hrev47498-1-x86_gcc2.hpkg
-rw-r--r-- 1 user root  6527826 2014-07-15 10:28 haiku_x86-r1~alpha4_pm_hrev47498-1-x86_gcc2.hpkg
-rw-r--r-- 1 user root 53993237 2014-07-15 10:28 haiku-r1~alpha4_pm_hrev47498-1-x86_gcc2.hpkg
-rw-r--r-- 1 user root     5854 2014-07-15 10:28 makefile_engine-r1~alpha4_pm_hrev47498-1-any.hpkg

(I was upgrading from hrev47458 -> hrev47498.)

Making this a blocker because it stops all further use of the package management system after it fails.

[ttcoder]

Same here, tried upgrading a system and got the exact same message; I then tried bisecting to find out which rev causes trouble:

• modified the /system/settings/package-repositories/Haiku file to point not to current but instead to hrev47470: it worked (rebooted to be sure, came up to the new rev as expected).
• modified it to point to hrev47480: worked again.
• modified it to point to hrev47490: didn't work per se, and additionally pkgman utilisability became hosed for good at this point.. I'm even unable to peddle back and do back to 47480 any more.. Didn't dig deep though, it might be because I was hacking directly to the file rather than using the pkgman add-repo command.

So there is a set of hpkg's between 47480 and 47490 that causes trouble it seems.

There is a ticket titled "various quirks when upgrading" but these new symptoms differ somewhat.

Edit: it appears that...

• my remark about the pkgman command no longer working was just silly pebkac: in the process of doing the bisecting search I ended up picking hrev47485, which does not exist on the server.. Once I moved on to 47486 the bisecting worked again.
• the bisecting led me to between hrev47489 and hrev47490: doing a pkgman update from the former to the latter eventually results in the odd Old activation state backed up in "" error mentionned above (which has been found to be off-topic for this ticket). It might be due to an FBC problem or whatever, since the sizeof() of class hpkgwriter seemingly changed in that revision.. Not important since...:
• To solve my problem I'll simply install from a nightly build this time, and from then on I know I'll be able to 'update' again, as per comment:5 ; so this is just a temporary inconvenience, not looking forward to file a ticket.

[waddlesplash]

Yeah, I closed #10278 because package upgrades mostly worked, and as you just discovered this is indeed a new regression. I don't think it works at all post-*90, so something got broken in there. I wonder if Ingo's changes to the bootloader and package_kit caused the problem? At any rate, I don't think we can do much except wait for him to investigate.

[waddlesplash]

Just got this while installing packages I had built with HaikuPorter, so it has nothing to do with some specific set of HPKGs and some bug in the package system.

[bonefish]

The "failed to remove transaction directory" error message is just a harmless symptom of ​missing client-side error handling. It will be printed whenever some package couldn't be installed. The actual error occurred earlier (most likely in the package daemon).

At a first glance the issue reported by diver is not related to the issue reported in the comments. Manipulating the data in the administrative directory -- on which the package daemon relies -- may cause problems. Obviously the daemon should try to work as robustly as possible. I think it can do better in this case, which is why the ticket is still open.

For the other issues please open new tickets (don't forget to include a syslog). FWIW I just tried a system update on x86 from hrev47494 to hrev47499, which worked fine.

[diver]

To workaround it, one can simply install downloaded packages manually:

mv /system/packages/administrative/transaction-1/* /system/packages

As a bonus, next update will work without having to do that.

[bonefish]

Good point. The package daemon will fail to read the haiku_loader and thus simply ignore this package, but install the others. After rebooting you will still have to activate the new haiku_loader package.

[stippi]

I just hit that error after switching repos for Haiku and issuing "pkgman update". But since I thought it is harmless (before finding this ticket), I rebooted and thus have no syslog.

I don't understand what I need to do from comment:6 and comment:7. Won't moving the packages manually result in two haiku packages being installed? What about other packages which would have been removed if the process had worked?

[stippi]

Sorry, of course I have a syslog. Unfortunately, it contains nothing of relevance, it seems.

[stippi]

Syslog of booting after error occurred.

[diver]

package_daemon will offer to uninstall a few older packages.

[stippi]

Thanks! But if there was a problem in the first place, won't that have any effect?

[bonefish]

The problem is that the new haiku_loader package uses a format that isn't supported by the older Haiku yet. pkgman update updates all or nothing and will thus fail completely due to the incompatibility. When moving the packages manually to /system/packages, the haiku_loader package will simply be skipped, since it isn't considered a valid package, and everything else will be activated. Since nothing depends on haiku_loader and the old package can load the new Haiku just fine, there won't be any problems. You'll just have to update the haiku_loader package after rebooting (manually or via pkgman update).

[jessicah]

One of the issues I've seen is when it wants to install a package when a package of that name already exists in the packages folder. Could be triggered by updated packages without an updated revision, for example. And, as shown in the original bug report, also the settings folder.

The package_daemon needs to be a bit smarter and more robust with this occurrence, likely automatically uninstalling the conflicting packages, and handling the duplicate settings folders better.

[michel]

It went a way for a while, but I am seeing this error again in hrev 50126

[waddlesplash]

Fixed in hrev53132. The underlying errors which caused this will now be distinct and error out much sooner; individual tickets for those should now be opened.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone