Second time in 3 weeks.
Tried to boot last good state. It is not showing.
I had not yet cleared the old state using filwip, as it had not sucessfully rebooted, after updating…
An assertion is a “deliberate” KDL to catch errors early… if you hit stuff like that please make a bug report, and provide the image of the KDL.
That does not help. Provide a picture for the kdl and open a ticket on the bugtracker.
1 Like
Yes, this is what happens when we work on core parts of the system! If you want to “just use Haiku” and not have to deal with reporting and helping debug such problems, then it’s better to just use the release branch.
No offense meant!!
Looks like in futureI I will quietly use the release branch…
My remark stemmed from my surprise that the same error is cropping up again…
I apologize for my remarks in the first post
Extremely sorry!!
Beg your pardon…please
1 Like
It’s not the same error at all, actually (though perhaps it looks very similar to anyone who can’t decipher KDL messages…)
And, don’t worry about it 
How do I boot into old state, hrev58209? option is not presented… both ‘latest’ and ‘current’ refer to hrev58228 only…Please see the screenshot at the beginning of the post
How to come out of this?
posting from voidlinux
Is this a problem with the bootloader, or did you delete those states? (You should be able to check if other states exist by mounting the BFS partition from Linux; most Linux distros should support mounting BFS read-only out of the box.)
I have not deleted this time, since it did not successfully boot after update…hrev58209 is still on my computer
other hrev…deleted after sucessfull booting after update using filwip
But now, it is not showing hrev58209, which I have not deleted…it is showing only hrev58228
‘Latest’ and ‘current’ both refer to hrev58228…that date shown is when I updated hrev58209 to hrev58228…
Haiku laptop is stand alone…only haiku…voidlinux on another laptop
so…in this laptop, I cannot use linux
Well, at this point you will likely just have to boot a different Haiku version via USB (or CD) and see what is going on. If there is the state in the “administrative” directory and the bootloader isn’t showing it, that will be interesting to find out and we should investigate. But in case the bootloader is correct and the state was deleted, then you should be able to repair the installation by replacing the “haiku” and “haiku_loader” packages with the ones from the USB.
Am I the only one facing this problem now?
Nobody else uses filwip?
Do you think it is not a good idea to delete old package states using filwip?I want to avoid holding data that is not needed…
I would only delete old states after you are running on the new version and it worked fine for a while. Otherwise you run into issues like these. (But also, it may be a good idea for FilWip to delete only states older than e.g. a week, rather than all states except the two most recent.)
Really, we should change Haiku’s package manager to delete such old states automatically…
3 Likes
My 2 cents, hold of on that until you hit R1 (or the nightlies before R1), Haiku is still evolving and in this stage it might not be the best move.
I don’t think there’s any reason to keep around any states which are more than 7 days old, and which aren’t the currently booted state? At least I think it makes sense for SoftwareUpdater to do this automatically, maybe pkgman wouldn’t by default.
Only a few days ago,I was really happy that my main development computer collected a huge number of revisions.
That made it quite easy to track down which commit lead to the bug with future dates.
Without old revisions and therefore a very narrow range of possibly problematic commits,it would have been a lot more work to find out which caused the issue.
I agree that it’s a good idea to allow automatic cleanup for the normal users,but please add a switch for developers to turn it off,so old revisions are kept around and can be used to track down regressions.
1 Like
Or even old packages that have been replaced by new ones (locally), sometimes handy to still have them around, so yes, an option to control this would be nice.
old states themselves are just text files, they don’t take up much space.
The problem is more with big packaged getting needlesly updated, like webpositive getting updated for each hrev with no changes.
Old states should only be cleaned up when the user asks to do this. I.e they want to reclaim disk space.