[FIXED in hrev57765] Update to hrev57762 nightly - cause : KDL, hrev57761(?) related

Dear All
First time in 3 years that an update has landed me in trouble. I did not update yesterday, today I did.
After updating, I rebooted…
System does not boot now…
goes straight to KDL
Posting from another laptop
How to come out of this? Any body else facing this issue?


Simple. At boot hit spacebar to enter Haiku boot menu, choose a previous state and continue.
Haiku will start like usual but using packages that were installed at that state.
So when a update will be available to fix it, all you will have to do is running SoftwareUpdater. Hopefully, after that, you won’t have to hit spacebar to enter the boot menu again.

1 Like

Thanks. This did the trick.
Strange…I thought it would ask to boot the previous hrev…number. But it asked to boot 57762 only. It showed 2 volumes…hrev 57762, 57762-1…
I selected 57762 and it booted…
I usually delete old state via filwip after it has successfully rebooted after an update…
In this case, since it did not boot up, I have not yet used filwip…so, I expected that it will ask to boot hrev…57755…
Do I have to do this every time, till an update fixes this?

Yes, though there’s a trick to make it permanent.
The thing is none reported that bug yet. So don’t expect it to be fixed soon.

1 Like

Ahoy @san2ban,

If you delete the old state dir.,

you just right delete the old level packages, which helps

you to select the earlier states, so in this case you do
the opposite one act that does not help to you
to restore your healthy Haiku system
before the unexpected result of an unlucky update.
As it is a saving about your old packages - which were updated.
The updated packages are already installed in the main ‘packages’ directory and it is not a right move to select and delete from there manually.
It is better to use pkgman command to do it for you.

Also keep in mind
if you check the referred hrev HERE → you can see this hrev57782 contains only a system document update , so no kernel or userland importand Haiku system file changed in it.
The problematic update should have happened among your previous revision you mentioned - hrev57755 - and this latest level hrev57762.

If you want to avoid the restore healthy Haiku using boot option hitting Space at every boot, then you have to install packages in this old state directory - using pkgman command

  1. First - list the latest state dirs.
~> ls -ltr /boot/system/packages/administrative/|grep state|tail
drwxr-xr-x 1 user root  2048 máj.   30 23:09 state_2024-05-30_23:09:32
drwxr-xr-x 1 user root  2048 jún.    1 02:48 state_2024-06-01_02:48:32
drwxr-xr-x 1 user root  2048 jún.    1 02:50 state_2024-06-01_02:50:32
drwxr-xr-x 1 user root  2048 jún.    3 03:04 state_2024-06-03_03:04:23
drwxr-xr-x 1 user root  2048 jún.    4 00:15 state_2024-06-04_00:15:29
drwxr-xr-x 1 user root  2048 jún.    5 23:56 state_2024-06-05_23:56:40
drwxr-xr-x 1 user root  2048 jún.    8 22:35 state_2024-06-08_22:35:43
drwxr-xr-x 1 user root  2048 jún.    9 10:25 state_2024-06-09_10:25:16
drwxr-xr-x 1 user root  2048 jún.   10 15:54 state_2024-06-10_15:54:26
drwxr-xr-x 1 user root  2048 jún.   12 16:58 state_2024-06-12_16:58:19
  1. List the content of the dir. - to check out the old packages in this dir.
    you can do it :

write ls after the prompt + hit space

katt on the dir. name I used in my command (this is the same on all Haiku)
use right click to copy after ls command ( I hope you hitted space after ls )

katt on last dir. name and use right click to copy after the previous path

continue the command after dir name with /*.hpkg + hit ENTER

~> ls /boot/system/packages/administrative/state_2024-06-12_16:58:19/*.hpkg

3) Install previous status - manually installing old packages
from the affected state dir.


Simply you can hit up arrow, then you have your previous ‘ls …’ command,
edit this command line with replacing ls to pkgman install

to show you →

~> pkgman install /boot/system/packages/administrative/state_2024-06-12_16:58:19/*.hpkg
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (BeSly Software Solutions)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (FatElk_64)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (Haiku)...done.
100% repochecksum-1 [64 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (HaikuPorts)...done.
100% repochecksum-1 [65 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (KapiX's Depot)...done.
100% repochecksum-1 [71 bájt]
Ellenőrzőkód érvényesítése a tárolóhoz (LOTE)...done.
The following changes will be made:
  in system:
    upgrade package gcc_syslibs-13.3.0_2023_08_10-1 to 13.2.0_2023_08_10-3 from local file
    upgrade package yaml_cpp0.7-0.7.0-3 to 0.7.0-2 from local file
Continue? [yes/no] (yes) : no

You just hit enter to reinstall all old packages, I wrote no, as I just show you how it can be done.

If you want to reassure you reboot now - to see your restoration was OK.

And yes - some reinstall of an old package can deinstall additional other (new) packages, Then you have to reinstall them additionally if you need those packages. It is because that is a dependency for that package.

So if you get warninf of such deintall - save those package names in a text file, save it and after hit the ENTER to reinstall previous old packages.
This way you will exactly know which packages should be reinstalled.

Kind regards,

I just updated from hrev57755 to hrev57762. As usual, I did this on a virtual machine first (not the actual bare metal installation) - just in case. I didn’t find any problem, so I’m not sure what’s going on here.

Wrong link? Copy/paste mistake, guess.

I think I have been facing the same issue, since update it fails at boot for me too


hrev57755 work fine

hrev57762 - disable SMP - boot work fine. Enable SMP - KDL kernel panic

Thamks, @ Pap , - I fixed the link in my post.!

Yepp, sorry from everyone, seems I mixed the 2 clipboards or sh¤t happened …
Earlier I pasted that YT link
from Falkon to QMplay2 - strange as I copied the Gerrit log link , and was in Web+ when I added to that link to my post. It should have been just as now THERE, but I failed to copy the link or got into another clipboard and I copied the YT link from another one.
Generally I re-check what I write, and fixing quickly as I re-read-it.
In case the link I forgot and also … I was sure I was right :)) … but it was wrong - at this time (too :(( … )

Today, I updated to Hrev57763 and rebooted…again kernel panic…goes to KDL

Only Hrev57755 is working
Pl. Suggest a remedy for this issue

1 Like

Re-install an earlier revision eithout this problem from the adminstrative directory in packages.

Dear @kim1963 ,

If this issue can be ignored by disabling SMP in boot options, then …

kernel / SMP - among other thread related stuff - was changed in

→ gnu: add pthread_setaffinity_np()/pthread_getaffinity_np()
→ kernel: add syscalls for thread affinity
→ kernel/smp: change CPUSet::SetBit() and CPUSet::ClearBit() bit order

I suggest to one of you open a ticket about it - to be investigated asap to have a fix for this issue.

Kind regards,

I created a ticket… https://dev.haiku-os.org/ticket/18915


Do not delete anything until a fix is available!

Then start the computer. At boot hit spacebar to enter Haiku boot menu… choode a previous state an continue to boot into Haiku.

Yes…After 55762 update, it did not boot…so I did not use filwip…
Today, I booted from old state…and updated to 55763…but this also lands in kernel panic…so, after 57755, nothing is deleted

I am using old state to boot

1 Like

Thank you very much

I thought 55763 might resolve this, but no…

Since Diver had closed another thread related to this same issue, thought it must have been resolved in today’s update

1 Like

just wait and delete nothing until a working hrev is there!
Would be a good idea together with a monthly report to give user a working hrev advice once a month!


I know nightlies aren’t for end users but I always thought these cases could be handled more gracefully. I am sure a lot of non-devs just use the nightly to check if it works on a dedicated hardware and if they don’t know how to react (hold space and select older state) it just ends there on a bad impression that may last.

It would be nice if one file was touched on startup, and another at the end of the boot processt. And if you reach the boot menu level and start is older than finish then it autmatically offers to chose the previous working state. Something like “Two consecutive boots failed, try reverting to older states from 2024-04-03?”


Your improvement suggestion is reasonable,

but to be honest nightly practically means “no one has tested this”, and automated tests aren’t super easy to implement extensively in a kernel.

Especially when the development team is small, you can expect that master branch will be randomly broken in a project as hard to test as an OS.

A lot of nightly users are a good thing because they will catch the issues that the developers didn’t face, but we need to be prepared to restore our system from previous states or backups whenever necessary. A wrong change to the file system implementation could easily make all your data unreadable even if you boot from a previous state.


Same here but disabling SMP helped.

1 Like