Opened 4 years ago
Last modified 17 months ago
#16573 assigned bug
Un-activated packages after install
| Reported by: | wombatstew | Owned by: | ambroff |
|---|---|---|---|
| Priority: | high | Milestone: | R1/beta4 |
| Component: | Kits/Package Kit | Version: | R1/beta2 |
| Keywords: | Cc: | ||
| Blocked By: | #15068 | Blocking: | |
| Platform: | All |
Description
Version: R1/beta2 (hrev54154+119) x86_64
During install, I selected all optional packages to be installed (includes binutils, gcc).
Post-install, I found that the gcc tools were missing. I tried installing it with pkgman, and it successfully downloaded all the dependencies. However, while installing, the program exits with the following error:
Code highlighting:
*** failed to commit transaction: The to be activated package "binutils-2.31.1-2-x68_64.hpkg" does already exist.
I was able to work through the issue on the discussion forum here. It appeared there were unactivated packages in /boot/system/packages/ that I needed to manually remove to fix the issue.
I was unable to reproduce this issue with a fresh install, but it was suggested that pkgman should be able to clean/handle these types of issues, and to submit a bug report here.
Change History (17)
comment:1 by , 4 years ago
| Blocked By: | 15068 added |
|---|---|
| Component: | - General → Kits/Package Kit |
| Keywords: | pkgman activate package removed |
comment:2 by , 3 years ago
comment:3 by , 3 years ago
Subsequent updates also failed.
I fixed it by removing /system/packages/administrative/activated-packages and rebooting.
comment:4 by , 3 years ago
| Milestone: | → R1/beta4 |
|---|---|
| Priority: | normal → high |
comment:5 by , 3 years ago
was a pkgman full-sync attempted on this one? That's generally how you solve packages refusing to activate.
comment:6 by , 3 years ago
That's not really the question. After installing from the DVD you should end up in a sane state with all the needed packages activated. It doesn't matter if the fix is a simple oneliner, the install process should do the right thing.
comment:7 by , 3 years ago
has anyone else reproduced this one? I personally haven't seen it installing from iso in -cdrom in qemu.
comment:8 by , 3 years ago
The ticket is apparently from beta2, so it's possible that AGMS' rework of the package activation already fixed this?
comment:10 by , 2 years ago
| Resolution: | → not reproducible |
|---|---|
| Status: | new → closed |
comment:11 by , 17 months ago
| Resolution: | not reproducible |
|---|---|
| Status: | closed → reopened |
I'm reopening this since I reproduced it while setting up a new dev machine installing r1beta4.
The way to reproduce it is to use Installer from the live desktop. If you click "Try Haiku", and then install any package, and then install with Installer, the /boot/system/packages/administrative/activated-packages will get copied into the installed system which will not match the actual package set copied by Installer.
I think the fix is to just have Installer never copy activated-packages.
I'll make a quick fix.
comment:12 by , 17 months ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → assigned |
comment:13 by , 17 months ago
Well, it might not be super straight forward. It doesn't look like CopyEngine in Installer has any any rules about skipping files in the source.
I think the right behavior is to just skip /boot/system/packages/administrative entirely. The optional packages selected in the installer will be copied into /boot/system/packages, and any packages installed onto the live system (or an existing installation) will also end up in /boot/system/packages. So if you skip the administrative dir then the repro I used would not be possible.
So I think just omitting the administrative dir is the right thing to do, but I'll need to test that out to be sure.
There are probably some annoying edge cases when installing from an existing installation. For example, if omitting the administrative dir leads to an incompatible set of packages being activated on first boot, that would be annoying. But it seems like getting the Installer behavior from the live CD / release image is more important to get right.
comment:14 by , 17 months ago
The way to reproduce it is to use Installer from the live desktop. If you click "Try Haiku", and then install any package, and then install with Installer, the /boot/system/packages/administrative/activated-packages will get copied into the installed system which will not match the actual package set copied by Installer.
Why is that? Installer should copy all the packages from /system/packages and the activated-packages file should match that. Unless you installed something that requires a reboot, and then did not reboot? In that case, maybe we should mark that somewhere, and Installer should check for that "mark" and show a warning or skip activated-packages.
comment:15 by , 17 months ago
Why is that? Installer should copy all the packages from /system/packages and the activated-packages file should match that. Unless you installed something that requires a reboot, and then did not reboot? In that case, maybe we should mark that somewhere, and Installer should check for that "mark" and show a warning or skip activated-packages.
Whether or not the package requires a reboot for activation doesn't matter. The problem is that the activated-packages that gets copied is the activated-packages from the live environment, not the actual install.
The installer copies all files from the source volume, from /boot/system/packages, and also copies all of the optional packages listed in the installer, like make, which is checked by default.
The live environment doesn't have make installed, but the target system does. So if you create any new transaction in the live environment before running the installer, then the activated-packages file installed to the system doesn't match the intent of the user.
So as an example, if you start the live environment, then do pkgman add zstd_devel, that package is activated and a new transaction is created, creating the activated-packages file in the live environment. Then you install with the optional package "make" selected. The resulting system will have the make-4.1.5_x86_64.hpkg file in /boot/system/packages, but it will not be in the activated-packages file.
I think this isn't a problem when installing from an existing install, since the "optional package" list is not used unless /boot/_packages_ exists as it does in the live environment.
Whatever fix is made for this, I think as a user I expect that whatever I install in the live environment, and whichever optional packages I select in the installer, should all be installed and activated on first boot in the installed system.
I think this logic would lead to very unsurprising behavior for me:
if (_packages_ exists meaning this is the live environment) {
copy everything from src to dst except /boot/system/packages/administrative
} else {
copy everything from src to dst
}
comment:16 by , 17 months ago
Maybe a cleaner alternative is to just have the Installer install any packages from _packages_ selected by the user before actually copying anything.
That sounds a lot nicer, but it would need to handle some edge cases. Like say in the live environment you install make, and the package manager installs a version from the repository which is newer than the file in /boot/_packages_. That might be trivial to handle but I'm not sure yet.
comment:17 by , 17 months ago
Maybe a cleaner alternative is to just have the Installer install any packages from _packages_ selected by the user before actually copying anything.
One of the reasons the _packages_ directory was introduced is to reduce the RAM requirements for the initial install. Otherwise we would end up in situations where the live install ran perfectly fine, but Installer would run out of memory during the installation process. With this system, we have less things activated in the test environment and so less used RAM, and Installer works fine.
The proper solution here would be to let package kit that the new install was created by Installer and it needs to rescan the package directory and activate the new packages. Maybe Installer should install the packages to a transaction directory in the target system, and let the package kit activate them properly at the next boot? I don't know what's needed to create a transaction directory in such a way, do we just need to put the packages there or is there more to it?
I've just ran into it in hrev55185 with coreutils package. Previously I had to force shutdown VM with Haiku while SoftwareUpdater was downloading packages.