So yesterday I ran pkgman update and saw that an updated coreutils package was available for beta 5. I downloaded the update and everything seemed fine. The problem started today when I booted up my system. Many of the major coreutils commands (including ls of all things) simply won’t run and print out error messages instead.
I managed to get into the boot menu and revert the system to an earlier state, but I don’t know how to make it my new “current” state. Because of this I have to go through the boot menu every time I turn on my system and want the console to be functional. I am also unable to install new packages.
Is it because beta 6 is in testing?
Can you post a few of those errors?
I’m on hrev59922 (nightly). I didn’t see this issue yesterday and today. Make a bug ticket out for @waddlesplash to review.
Example:
- Run chkdsk (check filesystem and disk health)
- ls -alR
Here’s my shell output after starting a new Terminal window and running ls:
Welcome to the Haiku shell.
runtime_loader: /boot/system/bin/id: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/id: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/id: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/id: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/uname: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/uname: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/uname: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/uname: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/id: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/id: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/id: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/id: Troubles relocating: Symbol not found
runtime_loader: /boot/system/bin/dircolors: Could not resolve symbol '__fpending'
resolve symbol "__fpending" returned: -2147478780
runtime_loader: /boot/system/bin/dircolors: Troubles relocating: Symbol not found
~> ls
runtime_loader: /boot/system/bin/ls: Could not resolve symbol 'mbrtoc32'
resolve symbol "mbrtoc32" returned: -2147478780
runtime_loader: /boot/system/bin/ls: Troubles relocating: Symbol not found
~>
Again, I’m not on nightly but on beta 5. My best guess is that this is a case of coreutils getting updated but not getting the “requires beta 6” tag.
It seems there may be some problems with that update, see also #20251.
I am also unable to install new packages.
What do you mean, HaikuDepot, pkgman and family fail in the same way as the coreutils? I don’t know from the tip of head, but if those don’t work in your current state, maybe booting into the working state and installing the old version again (like in the issue, look for it in /system/packages/administrative/state_whatever) works? If it doesn’t, you may have to manually copy the hpkg and edit the activated-packages file, but here be dragons.
I just looked at the package and indeed you’re correct, it doesn’t have a version attached to the haiku package requirement. I’m not sure why, all packages at HaikuPorts are supposed to get that automatically…
1 Like
What I meant is that I am unable to install new packages to the rollbacked instance. They get applied to the “current” instance and then pkgman tells me to restart.
I tried following the troubleshooting guides but they all tell me to uninstall the offending package. Unfortunately I don’t think I can have a functional system without coreutils.
You can just install the old coreutils package, from the old administrative directory, and it will “roll back” the version on the current instance: pkgman install /system/packages/administrative/state.../coreutils...
2 Likes
Thanks, that worked! Maybe this could be added to the troubleshooting section of the manual? It seems like a good safety system.
1 Like
Interesting suggestion; I’ll let @humdinger make that call.
I agree. I think it should replace what we have now in SoftwareUpdater - “Downgrading to a previous Haiku revision”.
I think downgrading to a working local state is the more common use case than downgrading to a specific hrev (if in fact that hrev number is even available).
I suggest to replace the above with:
Downgrading to a previous “state”
It’s rare but possible that an update to the latest Haiku revision (“hrev”) introduced a regression you’re not willing to live with. From the boot options menu you can load a former, working state (see Boot Loader - Troubleshooting). Find the last working state and boot into it.
You can permanently revert to a state, by opening a Terminal in that “state” folder under /system/packages/administrative/ and install all packages there with pkgman install *.hpkg.
Nonetheless, you should report the regression and help to fix it, if you can. Because until it’s fixed you cannot update the system, or you’ll end up with that non-working state again…
Once fixed - watch the commit logs - you can safely update again.
1 Like
Unfortunately that doesn’t suffice to revert to any earlier state except the most recent. Because you might have installed or uninstalled other dependency packages of those packages in other states between an earlier one and the present one, and those packages are needed to actually “revert” to that state…
Aww… I only tried with recent “states” and was happy that it appeared to work. 
OK. We’ll keep the “downgrading” topic as is and I’ve added another paragraph to the end of the info box on that page. It now reads:
This is wrong. This will not bring you back to a previous state
Consider this:
state A installs new packageA
state B deinstalls package B
State C breaks Haiku
Now the user wants back to State A so they install everything from State A, but now are, despite the userguide instructions mysteriously short of a package B
Ideally we should have a gui tool for this (that would also more easily do the cleanup in a “the user knows what they are doing” sort of way
Thanks for the example.