Ahoy,
As in the title I wrote I attemted a downgrade of Haiku with file remove from packages directory and copy back the appropriate files from latest state directory in case my nightly Haiku installation - using my R1B5 Haiku…
After restart the Nightly Haiku … its bootloader came up instead of loading Haiku, and there it states that ‘None’ bootable Haiku anymore … even after rescan.
I would like to understand : what the difference when I do it the same
→ using pkgman install packages from a state directory
or
→ the boot option when selecting previous state ?
I was needed to do it, as using bootloader … it failed previously.
→ once I could select the previous state , but seems like there is some timer in bootloader , as when I just got into main menu and wanted to continue boot hitting an enter … it just rebooted before I could navigate to the appropriate line and hit an ENTER.
→ next time I could not reach the boot loader menu for long time (I have already many saved states directories), so I gave up on
→ recently bootloader had not reached … always just rebooted after the vents gone crazy.
I wanted to downgrade my Nightly install from hrev58858 to hrev58841, as on hrev58841 I experienced such issue that display went black just after some seconds as I had reached the Desktop.
CTRL + SHIFT + ALT + ESC - what I was red in a recent forum post - had not helped, as it hat just replaced pitch black screen with blank white screen what I left with an ESC button once. At another attempt it had not worked so I had to do a hard reset with power button.
Anyway Haiku was working behind the black screen as for power button it had stopped gracefully - checkfs showed clean BFS just as bfsinfo.
I can recreate nightly with minimal dataloss from R1B5, I just wanna understand why such package moves concludes into unbootable Haiku, however pkgman or boot option does similar … what my manual action miss in this case ?
Can’t be 100% if this would have solved your case but…
When you manually replace .hpkg files under /system/packages/, always make sure you’re also removing the /system/packages/administrative/activated-packages file, otherwise you’ll just end up confusing package_daemon.
AFAIK, when you remove that file, it forces packagefs/package_daemon to “rescan” what’s available, and only use that, instead of trying to load .hpkg files that are not there anymore (as you have just removed them).
1 Like
Thanks, I forgot about that this file created when installed / removed packages with package manager.
~/Desktop/Debug_reports> cd /HaiQ64_R1Nitely/system/packages/
/HaiQ64_R1Nitely/system/packages> cd administrative/
/HaiQ64_R1Nitely/system/packages/administrative> ls activated-packages
activated-packages
/HaiQ64_R1Nitely/system/packages/administrative> ls -l activated-packages
-rw-r--r-- 1 user root 41537 máj. 2 20:45 activated-packages
/HaiQ64_R1Nitely/system/packages/administrative> grep haiku activated-packages
haiku_svg_icon_theme-5.15.2.38-1-any.hpkg
haiku_userguide_pt_pt-2024_09_09-1-any.hpkg
haiku_userguide_es-2024_09_09-1-any.hpkg
haiku_userguide_uk-2024_09_09-1-any.hpkg
haiku_userguide_fr-2024_09_09-1-any.hpkg
haiku_userguide_tr-2024_09_09-1-any.hpkg
haikuwebkit-1.9.21-1-x86_64.hpkg
haiku_userguide_ca-2024_09_09-1-any.hpkg
libsolv-0.3.0_haiku_2014_12_22-5-x86_64.hpkg
haiku_userguide_zh_cn-2024_09_09-1-any.hpkg
haikuutils-r131~git-2-x86_64.hpkg
synergy_haiku-0.3-1-x86_64.hpkg
qthaikuplugins-5.15.2.38-2-x86_64.hpkg
haiku_userguide_fur-2024_09_09-1-any.hpkg
haiku_userguide_pt_br-2024_09_09-1-any.hpkg
haiku_userguide_hu-2024_09_09-1-any.hpkg
haiku_userguide_sk-2024_09_09-1-any.hpkg
haiku_userguide_de-2024_09_09-1-any.hpkg
haiku_userguide_sv_se-2024_09_09-1-any.hpkg
haiku_userguide_fi-2024_09_09-1-any.hpkg
haiku_userguide_pl-2024_09_09-1-any.hpkg
wpa_supplicant-2.11.haiku.0-1-x86_64.hpkg
fusesmb_haiku-0.9-5-x86_64.hpkg
haiku_userguide-2024_09_09-1-any.hpkg
haiku_userguide_jp-2024_09_09-1-any.hpkg
haiku_userguide_id-2024_09_09-1-any.hpkg
haiku_userguide_en-2024_09_09-1-any.hpkg
haiku_userguide_ro-2024_09_09-1-any.hpkg
haiku_userguide_ru-2024_09_09-1-any.hpkg
haiku_welcome-2024_09_09-1-any.hpkg
haiku-r1~beta5_hrev58852-1-x86_64.hpkg
haiku_loader-r1~beta5_hrev58852-1-x86_64.hpkg
haiku_extras-r1~beta5_hrev58852-1-x86_64.hpkg
haiku_datatranslators-r1~beta5_hrev58852-1-x86_64.hpkg
haiku_devel-r1~beta5_hrev58852-1-x86_64.hpkg
/HaiQ64_R1Nitely/system/packages/administrative> rm activated-packages
/HaiQ64_R1Nitely/system/packages/administrative>
Later I will see, now I cannot reboot R1B5 , due to a longer download in Falkon.
(However I was scared for a moment as display blackout happened once menwhile I was written the previous starting post on here, R1B5, so I had to switch off with power button and boot again …
I hope it is not a sign of begining of a HW issue :((… )
I switched from dev to beta 5 to dev recently and the one thing I found out, at least on UEFI hardware, is that each version needs its own bootloader installed.
I made a copy of each in the haiku’s bootloader folder and activate the one I need before switching version.
Ok, so seems it did the trick, at least the boot started …
Unfortunately it lands at KDL with ASSERT FAILED at “main”
and there was path to a header file DoublyLinkedListFile.h (…/haiku-git/ trallala /DoublyLinkedListFile.h 512) and a condition which is in the file in line 512, I assume.
Seems I deleted some (newer) that I had not copied back or a newer package altered something additionally.
Anyway, seems I should re-create my Haiku nightly 64 bit.
Well, I did once the copy, but later changed back to the Beta4 one, as I use it from the Beta4 installer.
I copied the one of hrev or Beta5 installer version, but restored the older one finally as I had some issues with the newer bootloader. Fortunately I saved the older one with plus __hrevxxxxx, so it was easy to restore.
I know this way I cannot use improvements, but for boot I prefer better reliability than new functions / features.