I just updated my 32 bit Haiku in Virtual Box to hrev53029. It is now hanging after all the icons of the boot screen have lighted up.
IIRC, I read somewhere that upgrades can be backed out by disabling the latest hpkgs. Is this correct? How do I go about reverting to the previous version that was running? Is there a key I hold down during boot that will let me select the previous state?
In Haiku 64-bit you can press the space-bar (and keep pressing) very early in boot process in order to see boot options.
From there you can select which partition to boot and which state. I suppose that it’s true for 32 bit also.
Thanks! That did the trick!
Is this permanent? If not, how do I make it permanent?
No, it’s not permanent. You booted actually to a “frozen” state, so no package updates work now. (Learned that recently!).
But you can make it permanent by using these instructions: https://www.haiku-os.org/guides/daily-tasks/updating-system/ (Haven’t tried it myself though).
Hmmm… The repository url’s for downgrading at the bottom of that page are a bit cryptic. They don’t seem to match up with the current url scheme for the haiku and haikuports repositories, so I’m not sure how to specify the hrev I need.
OK. While that’s being sorted out, is there a manual workaround to uninstall the hpkg’s that messed up my Haiku install?
I have two Haiku VM’s, one 32 bit and a 64 bit. Can I just mount the drive image for Haiku 32 in the Haiku 64 VM, manually remove the latest hpkgs and replace them with those from the folder for the previous state? Is there any pkgman housekeeping to be done if I do this?
I just upgraded to hrev53033 in my VirtualBox install and it boots just fine, even with much lower than my usual RAM (256MB.) Try disabling HDA and changing it to AC97, perhaps?
OK, I actually figured out what it was, see #14990 for discussion. The fix is to update the libxml2 package to 2.9.9-3.
I used pkgman to update to the latest hrev. but I must have screwed something up trying to manually back out the 53029 hpkgs earlier, because it’s still hanging at the same point.
I’m backing up my packages and VCS repositories to another vbox disk image. Then I’m going to do a clean install of 53042 to see if that fixes things.
Update: Tried doing a clean install onto the vbox disk image. Completely reinitialized it. Install seemed to go fine, but restarting came up with “no sys loader!”. I created a fresh disk image, and installed onto that. Startup went fine, but restoring the many application packages failed miserably (it had worked fine on earlier builds on the bare metal install). No applications showed up in the menu, and Software Update became useless, consistently reporting the it failed to delete the transaction folder.
So… another clean install. I put off restoring packages, and decided to restore the files from my home folder. Only to discover that some very important files (custom shell scripts for dealing with repository mirrors) were not in the bin folder a few levels deep inside my config folder. Why? BECAUSE NOTHING FROM THE CONFIG FOLDER WAS EVER COPIED TO MY BACKUP DISK, even though I had dragged the folder to the backup disk myself!!!
Please tell me that not copying the config contents is a bug and not a deliberate design decision! I’m having flashbacks to when I first discovered how OS X interferes with how users interact with their own files. It’s one of the main reasons I ditched developing for OS X.
Since the original problem has been fixed, I’m going to mark this topic as solved. Discussion of the config non-copying issue should probably happen in its own topic.
Hello,
I had a boot trouble with hrev53042. Could you please look at ticket again.
Haiku hrev53042 and hrev53043 x86_gcc2 are fine.
This has nothing to do with video-driver. Sure, tried your suggestion but Boot Loader fails to detect boot volume
Well, then I don’t know what’s going on in your case without more information…