Thanks for the hint!
So I extracted haiku-loader and haiku (the 40Mb sized thing) both with extractor. That’s only possible if -not- booted from the stick as in that case the target folder becomes read-only.
Unfortunately when I try to boot from the stick it wants these packages per se: it does not look at the extracted versions even though they are in the correct places. I guess that might be the EFI app’s doing?
I wondered if it had to do with not officially uninstalling these packages: apparantly that can only be done when booted from the stick, by just deleting the package, that triggers the package manager or so and it also uninstalles a lot of other packages (dependancies).
Still no boot possible after that.
Is it possible to just have an unpacked app_server for instance? I seem to remember that Axel told me that this might not work, when I tried to work on it for the drivers a long time ago. I find it annoying this has stopped me from developing more than once in the past years already. My fault, no doubt, as I am just a simple guy
Anyhow: it was soooo easy with beos… ah… memory lane…
Maybe I have to quit on this again, as I don’t like it very much spending weeks on this stuff I really don’t want to spend time on.
This weekend I’ll do a few more attempts and then it either works or I quit on it.
So: anymore hints for me anyone?
Thanks!
BTW: with those two packages when lauch_deamon is started it fails. Just above that I have a message telling me that cpufreq and cpuidle are missing. In which package are these sitting??
Somehow I have the feeling I have to instruct it to -not- look for packages and just use the existing structure on disk. I just created a partition on the hd of a 64bit system (no uefi), and it won’t boot at all without the two packages: but as soon as I add those, it boots. until launch_deamon should be started that is (the two modules are sitting inside the 48Mb thing so should not be a problem when these packages are there btw, from my simple point of view )
I would love to grasp this, but I simply fail at it. Are there docs I can read about it somewhere for instance?
Ah nice, I’ll check that.
Update btw: apparantly I can boot that hd partition without using makebootable on it with packages installed. I just tried without packages, just extracted, and with makebootable, then it says: bios_is32 stage1: Failed to load OS.
if all is right it will boot again as soon as I place the packages back (did that before on the surface and saw same messages)
You need more packages to run Haiku, freetype for example. I recommend to extract all packages from nightly image and delete “packages” directory (it may cause conflicts). It is also possible to extract packages with a script.
This method works with EFI, at least on RISC-V version, I haven’t done anything special with boot loader to support non-packagefs boot.
Thank you both for your help I’ll try these things a bit more. @X512 I do find it strange that if I have just those two packages in the packages folder the system boots upto launch_deamon, while if I extract both, remove the packages folder: nothing happens at all. not a single line is written onto the screen for instance.
While I can see more packages are needed to complete the startup, I -would- have expected approx the same behaviour in both ways I just described. More than just the packages folder is interfering I fear.
I’ll test some more and report back here
Update: the Hakilo thing doesn’t work for me. Seems like it just makes symlinks to the read only hierarchy (beos/system). There are some scripts for installation/deinstallation of packages, and if there is intended to be more I don’t understand it or it is meant for something completely different
Stage 1 boot code for the good (?) old BIOS for use as boot block of HD
; partitions. The offset of the partition in 512 byte blocks must be written at
; position PARTITION_OFFSET_OFFSET (32 bit little endian; makebootable does
; that) or otherwise the code can't find the partition.
; The partition must be BFS formatted. The haiku_loader hpkg file must be located
; at "system/packages/haiku_loader*" and the haiku_loader.bios_ia32 must be the
; first file in the haiku_loader package.
So, yeah this is not going to work.
EDIT: o yeah, I did try with just one package: then the message disappears and loading goes a tiny little bit further. I guess this one package in turn also per se wants the package version of the system, etc. This route is going nowhere for me.
If I often have to create a 48Mb package to replace the system for just the app_server changes I would like to test, then this is going to cost way to much time per try. nogo for me that way.
I’ll try a app_server in the non-packaged hierarchy once more, but I don’t expect much there either.
I just tried it myself and indeed it doesn’t boot to the Desktop.
All boot icons light up and it sits at a rocket icon. When I enable on-screen debug I see this:
@X512 can you still boot a recent unpacked Haiku? Just to rule out that not being a recent regression.
Hi, So in the end I tried this: and failed as well. linking fails where symbols are not found for x64 (__divmi4 or something like that, multiple errors. seems that for x64 these should be inside libgcc btw).
I never compiled the complete sources, just cloned it and just compiled the intel driver sofar. So then I configured for the cross compiler (did not do that because I am on x64 Haiku there). Tried again: same fail.
Then I finally compiled @haiku-nightly. Success. After this I can succesfully compile/link haiku.hpkg seperately.
As I thought, this indeed does cost much more time than just recompiling the app_server for instance, so I keep thinking it’s a shame it is not possible (for me yet) to use app_server (etc) outside of the packaging system (still could not manage to get this going, and indeed this is not supported via non-packaged hierarchy).
The above message is just a heads-up from my side on this. Thanks for the pointer anyway, I think I’ll try a few iterations, but I will keep that very limited as it really takes too much time to work this way.
Well, even that won’t work: while I can install the haiku.pkg, it will not boot. Looks like I have to rebuild the entire nightly for a single shot… bummer.
)
