IIRC you need to copy your /system and /boot/home folder to another bfs partition, delete everything in system/packages except for haiku_loader.hpkg and boot from this new partition.
I haven’t tried it myself, tho.
You can try to boot with Clover, it can Patch various usb relaxed problems. AFAIK it can delay the usb initialization too.
Btw I used the haiku.hpkg trick to test the app_server fix this morning.
Do you have to work on the same machine? Maybe you could scp haiku.hpkg to it ?
You can extract all packages to /boot/system directory and delete /boot/system/packages. I use that for testing Haiku RISC-V port, files are updated with a script. If you want to do this, I recommend to create separate disk/partition for testing because it breaks package installation.
Rebuilding haiku.hpkg takes much more time than compiling and copying just one file. Speed is important when testing, it allows to do more test cycles at the same period of time.
5 Likes
Thanks everyone for all the hints, gives me a lot more to try… I will keep you posted 
Well, I guess in the meantime approx 8 systems are lying around here, just added three more from my employer. Really cool, grabbed them literally from the old scrap bin (among others a samsung laptop which still had some juice but no hd). It’s so cool to just plug in my 1Gb 50 cent Haiku stick and stand next to the bin with a working Haiku desktop within half a minute! 
Anyhow, I’ll stay focussed on the 64bit boot on the microsoft surface for now to see if the intel driver will run on that (in the end)…
thanks again!
10 Likes
I’d recommend getting the EFI app from an older version of Haiku. I’m not sure but it may try to do package validation on boot now.
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??
2 Likes
I think you need another BFS partition to copy already extracted files to it.
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?
2 Likes
@s40in do you have an idea what could go wrong here?
Also check this thread, maybe I’m missing something:
1 Like
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)
I’ll read that thread Thanks again!
2 Likes
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.
2 Likes
For BIOS boot you need to have package with BIOS boot loader. All other packages are not needed.
2 Likes
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
I’ll forget about that now.
Stage 1 bootloader info:
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.
1 Like
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.
3 Likes
I tried to run the latest Haiku hrev55240 x64(bios) in unpacked mode.
Its works in VirtualBox.
I think that haiku_loader must be unpacked and haiku_loader _xxx.hpkg must be in the packages folder. I always do this.
This is weird as I did exactly the same and also in VirtualBox.
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.
5 Likes