hrev56131 64 bit - no boot
////////////////////////////////////////
https://git.haiku-os.org/haiku/commit/?id=956f45070d5b0350c9221bd6757864734e324b6a
hrev56131 64 bit - no boot
Please open a new ticket, and include a screenshot of the KDL.
@X512 already reported one via IRC which I will investigate and fix shortly.
1 Like
Hi @waddlesplash, I rolled back to the previous state but it is not consisent. make fails, for example.
Is there a way to get rid of the the latest update permanently?
I’ve noticed that just after an update is complete but before rebooting, make always fails.
~/Dev/Projects/Weather> make
Error: Failed to find path: No such file or directory
Makefile:140: /etc/makefile-engine: No such file or directory
make: *** No rule to make target '/etc/makefile-engine'. Stop.
I think package activation after a system package update may be inconsistent and lead to failure conditions. Basically, it only is enough to let your system reboot cleanly. That isn’t great, not sure if we have a ticket about it though.
I can look for an old ticket and in case I can open one, once I get my environment back.
Having an inconsistent or unstable environment immediately after the update may be acceptable, although not optimal.
I would investigate the roll back system, instead. It seems to be working much like a “live” update but without the final step that makes the update permanent after a reboot. In fact, I need to revert to the old state every time I reboot as of now.
What does make the update permanent? Can it be applied manually after rolling back to a previous state?
I have much more serious troubles now.
56134 is on the depot and I immediately updated (from the restored state) but an error occurred.
Sorry I didn’t capture it but it says something like unable to install to a path/administrative/ and a date and time.
Now I’m not able to boot anymore
Loading Haiku64
bios_ia32 stage1: Failed to load OS. Press any key to reboot
I have an SSD with three partitions
Haiku64
Haiku32
Empty partition
Boot loader is installed. Haiku32 boots fine but it is still on hrev56087
Dear @kim1963, do you have to “mime” each and every post of yours with partly unrelated screenshots and have us guessing what you mean by closely examining those images?
If you have to announce a breakage here, why not just open a ticket at Trac (including a screenshot of the KDL, syslog etc.) and just link to the ticket here?
Thank you.
3 Likes
With regard to the issues I faced, I think it would be helpful to capture what happened if anyone else faces the very same issues. I did not find anything on the forum regarding a possible recovery procedure so here you go!
After updating to hrev56131 and rebooting, Haiku stopped working due to an issue with the AHCI driver that hrev56134 shortly afterwards solved.
In between, many things happened.
As a temporary countermeasure, I rolled back to the previous working state (hrev56129) and I eventually got my environment back. Apparentely.
The system didn’t completely restore to its former glory as I didn’t manage to run make any longer, for example:
~/Dev/Projects/Weather> make
Error: Failed to find path: No such file or directory
Makefile:140: /etc/makefile-engine: No such file or directory
make: *** No rule to make target '/etc/makefile-engine'. Stop.
This is probably the most apparent symptom of what I believe is a misbehaviour, maybe related to the fact the makefile engine was updated along with other core and non-core packages.
For the records, make stopped working also in other situations after updating Haiku but right before a reboot.
More to that, the rollback is not permanent, after a reboot the current state has always priority. This means that hrev56131 was the default version regardless.
Once hrev56134 was available, I immediately updated while still being on the restored state.
The update did not complete correctly due to a folder not being present in /system/packages/administrative path.
It seems that upgrading from a restored state it’s not well supported.
This turned my Haiku 64-bit partition unbootable as the boot loader was not able to find a consistent set of packages to boot from.
Fortunately, I had a 32-bit installation on another partition still on an old nightly and thus not affected by the AHCI problem.
I was then able to operate on the 64bit affected partition (it seems that my Dell Optiplex 7010 has a bad relationship with USB thumbdrives to boot Haiku from).
It proved that under:
/system/packages/administrative/activated-packages
the list of packages and their respective versions were not correct due to the update process stopped abruptly.
The correct packages corresponding to hrev56134 where not copied into /system/packages/administrative/ but they where under a subfolder called transaction10 (there are other transaction* folders there, I assume they keep a copy of the last update attempt).
I copied the hrev56134 packages to the main /system/packages and fixed the incorrect version number in the activated-packages file.
I also had to delete or move the hrev56131 packages.
Note: I previously tried to use makebootable on the affected partition but I’m not sure if it was a matter of boot record, so I can’t tell if it is a mandatory step to recover the partition.
I rebooted and boom! I had my environment back, fully functional and updated.
I hope you find this useful in case you find yourselves in such a situation.
I also opened ticket #17759
4 Likes