Slow boot times after months of using haiku

Is there any plan or progress with the problem that the system stores mass of data in the /boot/system/packages/administrative folder, that slow down the system at startup (after months of use)?

Greetings lelldorin


I pretty much go into the administrative directory and clean up old activation states when things begin to slow down. We really need a flag to clean up the activation directory in pkgman. (pkgman cleanup, etc)

We should also likely limit the number of previous activated states to 25 or something to keep things from getting unruly.

1 Like

FilWip app already clean that directories?

Sure. As is kallisti5…:grinning:

But this should be a service provided by the system. Or at least a solution would be nice that avoids a slowdown when states pile up.
It’s not trivial, however, because the states are accumulative. They can rely on eachother.


We should investigate why these states make things slower at all. When booting the current revision, the system should not need to look there at all, so why do they make things slow?
Also, is that time spent doing something useful, or just sending data to the syslog (and serial port, if there is one)?

1 Like

So if those states are accumulative, can we somehow merge them into one state? It would then be a good task for Filer to perform once in a while (at least as a temporary solution).

From axel’s comments on the linked tickets, it doesn’t seem to be especially easy, or it’d have been done by now, I expect.

But would be important here to find a solution for the later beta version, otherwise come various bug messages because of a haiku system which boots slower and slower.

oh the page for this bug are down.

Avoid increasingly longer boot times


I have fixed the slow boot times and later this week will probably add code to the package_daemon to delete old package states using a particular criteria, namely: delete all states older than 30 days, starting from the oldest, until only 10 (or 20?) remain. We probably won’t make this user configurable in favor of the Haiku philosophy of sane defaults.

If anyone has any feedback about this, let me know.


I sometimes boot up my last previous working state to run an update to see if Haiku devs fixed my unbootable situation. That means that a newer state/hrev will be added to the boot option even if doesn’t boot, maybe we should have an option for last bootable state?

1 Like

Or a function to set a bootstate as favourite and this does not delete by cleaning


I’m in favor of something like this. The last nightly I can use with networking was back in March.

Er… wait, one of the drivers you have an open ticket about used to work? That’s kind of important information, why did you not put this in the ticket? I would actually have something to investigate in that case.

The ticket is for the internal RealTek Ethernet device, which never worked.

I have a USB to Ethernet adapter (also with a Realtek chipset, if I remember right) that did work up until March, when you made a bunch of XHCI fixes. We actually talked about that and you were surprised because those changes fixed USB Ethernet adapters for other people. Later you explained why it stopped working, but I don’t remember what the reason was. So that’s what I mean by my networking stopped working in March.

And then I have an ASIX based USB Ethernet adapter which is recognized and, apparently, the driver loads but the device never shows up with ifconfig or Preferences -> Networking.

I’m telling you, this little box is cursed.

[For fun, I’ll mention that the internal shows up and has a MAC address, but always says it’s disconnected (it’s not). The USB Realtek shows up, has no MAC address, says it’s connected (it is) but doesn’t get a DHCP IP address and a manual one doesn’t work. The ASIX shows as loaded in syslog, but never shows up]