Can Haiku boot from itself (i.e. it’s own image)?

So… I’ve been questioning whether to base what I’m working on either on Linux or Haiku based on one thing: can Haiku boot from itself?

And to explain what I mean by this question, on (Intel) Macs, it’s possible to use Disk Utility to split the disk, write out a live Linux to a USB drive, and set up an additional EFI volume with parted/gparted, then boot a Linux distribution in its own image (using tools usually used for USB sticks like syslinux, etc). And the advantage of this is the Mac’s Startup Chooser will see it without needing to mess with rEFInd, etc.

Can Haiku do this same thing? I gotta ask bc if I just copy the EFI files to an ESP and copy a plain image or ISO there, it can’t find Haiku because I do not have a BeFS volume (and I don’t want to traditionally install it; I’ve done that several times before on Mac hardware using Disk Utility and dd to clone a Haiku volume to disk).

With a modern live Linux, it’s possible to have live persistence in whatever way someone wants (save files on disk, to a volume, to an image, network, etc) and run the system from an ISO (or also from SquashFS like Ubuntu or modules like Slax) and I like being able to do it this way because I really believe that’s the future, to make the OS one interchangeable piece (with testing Nightlies this would be really useful!) and then have the apps, settings, and files on separate volumes, which can be imaged, raw, or both. To explain where that’s useful, on Linux, I can attach/mount an ext4 sparse image for /var/cache/apt on Debian for software packages and have a sparse btrfs home folder (for files, settings, etc) and run the system from a read-only system image. Can everyone see what I’m trying to mention (and why)? Can Haiku be copied to an ESP this same way, where there doesn’t need to be an actual or ‘bare metal’ BeFS volume (or partition) on disk to start? It’d make both setting up Haiku with multi-boot on Macs a lot easier and make Nightly testing a heck a lot easier

We already support network booting somewhat, I am not quite understanding what you want to do, if it’s immutable OS images haiku already has that by default.
I am quite lost what you mean with your usb slplitting thing, but in essence just using the installer is likely the best option, it replicates the OS without deending on the specific disk layout (and in the future, if someone tests the bfs resizing code, installs onto a thumb drive could become a bit easier from linux too (just a cp instead of having to partition the thing and use haiku, haiku will then instead repartition on first boot)

1 Like

I think he meant he would like to boot Haiku from the iso image without having to install it first.
So one would copy the boot EFI file and the haiku iso to the EFI ESP partition, and the bootloader would look for a haiku iso and boot it if there is any.
The iso would be used as a read-only media and every changes would be saved into a different image or to a partition.

At least thats what i understood.

1 Like

Yessss that’s it exactly! :smiley: Is doing such a thing possible on Haiku? The only ways I can think of that might maybe work would be to put the files from system (like the kernel, etc) in with a raw image, point these to either syslinux-efi or grub-efi, and try that way or just point to an ISO by itself but idk if Haiku even supports booting like that — if it doesn’t… then yeah, I realistically can’t use Haiku for my personal projects for what I’d want to do (have everything self-contained on read/write vfat and HFS+ (Mac OS Extended) volumes) if using Installer and BeFS is the only answer

@extrowerk got it exactly, I’m not looking to use the Installer here; with live Linux distros, it’s possible to boot from a combo of the needed EFI files and the ISO itself (or alternatively to extract the kernel, vmlinuz, SquashFS image, etc and start up from that). Either way it’s all read only, but it’s really convenient because the built-in Startup Chooser on Intel Macs can see both macOS and the ’Linux’ volume (which it’ll label ‘EFI boot’ or ‘Windows’) without needing to go through extra steps like cloning a volume or rEFInd, and this also means that along with using virtual images (with a Linux file system inside), it’s possible to keep file systems the Mac can access over whatever media (disk, network, what not) without extra tools and have ‘persistence’ (apps, files, etc don’t get lost between restarts) this way.

For Haiku, this would be super, not just for the 2 reasons I mentioned (easy multiboot, compatible persistence), but it’d be easy to copy Nightly images in and out for testing instead of needing to do an upgrade or rewriting everything again.

No, Haiku doesn’t know how to do this. We need a real filesystem on a real partition.

1 Like

Thanks for the replies… I’d hoped there was a way; maybe in the future there’ll be a way to do this

BeOS 5 are installed on Windows. Then you start from there, the system restarts and boot directly into the beos image.

I remember reading about this feature in BeOS from research I did for my retro reviews, but the point is that Haiku doesn’t have it, and also I’m not talking about Windows in any form. This can’t be done on a Mac, where I need it (I can install Haiku on a separate volume but that requires manually installing Haiku traditionally); maybe when R1 or later is out, this will be implemented; I’ve thought about this myself, like if it’d be possible to put an image there with Haiku’s EFI files… but Haiku can’t see the image (when I last tried). Linux-based stuff like elementaryOS can boot from a SquashFS image with EFI files in place (which is what I’ve done on my MacBook Pro and iMac); also, some distributions can boot from the ISOs with multi-boot tools; one example of how is outlined here ).

Overall the point is Haiku still relies on a BeFS volume to run, and while this works, for what I want to do, I’m looking for something that can work more like Slax (everything runs from modules, with persistence). I’d hoped Haiku made it to that point. It makes it easy to revert, fix, and upgrade the system, while keeping files and settings separate, and imho is the operating system of the future. Imagine upgrading Haiku, or even something like Windows, just as easy as you would install or remove Haiku packages (hpkg) today. The other advantage to running things this way is that macOS can see the volumes on its side, which (out of the box) can’t be done with BeFS without some sort of filesystem in userspace. And afaik same goes for a Windows PC as well; Debian can read BeFS. Anyways, hope this explains more about this missing feature.

But upgrading haiku is just installing a package already, I’m confused what you want insead.

Anyhow since the OS is already in neat packages it might be possible to put the hpkg files into the esp and put them next to a disk image that is for persisnce but stored in the esp… the only problem here is that usually esp partitions are much too small to hold an OS like haiku, which is why we use normal partitions normally, but it might be possible to implement this.

So, to try to explain what I mean… with the PackageFS (package management), Haiku is installed as and works as a series of hpkg which need to be in the packaged folder under the system folder in order to be found and work (or far as I know); it also (again, far as I know) needs to run from a formatted BeFS file system. What I’m seeking is to be able to run Haiku from an EFI volume (vfat/fat32) formatted and have Haiku running in one single piece, solo, whether that’d be a regular or compressed image (like a raw disk image or a read-only SquashFS image) or the ISO file itself with the EFI loader outside, with my files and any downloaded packages on a different volume (they have to be because everything would get lost on shutdown, hence persistent images). Again, most live Linuxes are fully capable of starting from EFI + a SquashFS image or from EFI + an ISO (with a special loader or options). And it’s capable of using images mounted at different points for persistence, so I can mount something at /home, and on a Debian install, at /var/cache/apt, and with a few custom scripts, restore them to bring stuff back, and these are just 2 examples; it’s possible to link other folders to images as well.

So, what I’m essentially saying is that if I run these distros from file system modules (SquashFS, Slax modules, what not) or otherwise inside their own ISO, either way, I don’t have to install them conventionally, so there’s no need to make an ext4, btrfs, etc. volume anywhere. But the downside is they are read-only; the file system is in the image; pieces of an overlay are paged out to memory as it needs it. (Best examples I can think of are Finnix and Slax). Again, I hope everyone is seeing where this would be very, very useful; if Haiku could do the same thing (and I hoped it could but so far it can’t), there wouldn’t be a need to erase a disk with an all new table and make a new volume for BeFS and format it, which btw is a point that can confuse new users at times. All someone would have to do if it worked is split the disk (Disk Utility, GParted, etc), copy a single Haiku disk image to the ESP, the needed EFI files, flag or bless the EFI volume (on Mac), and restart. Then once all that’s set, to solve the read-only problem, any writable changes would be saved in both real and virtual disks (i.e. images) outside the read-only environment. The advantage is that without having a FS the Mac (or Windows if it’s a PC) is blind to, stuff can also be exchanged on HFS+ and other non-Linux FS types like exFAT. Linux can already do all of this, btw (although journaled Mac OS Extended volumes are still read-only on it without making it mount read/write last time I did it).

So going back to the dream in my last post — imagine if you could delete one single file, one single Nightly disk image (or release), pop in a new one, and restart. No need to reinstall or upgrade the old way. No having to download and reinstall multiple packages. A user would literally change out a Haiku release like changing out a single Haiku package today (which is where I was comparing it to packages now). Yeah, there’d prob be sus packages to fix on upgrades, but hopefully the Depot could resolve that later as Haiku gets better.

And anyways… I truly don’t know how to explain what I’m trying to do any clearer, I’ve tried several times now… and again, it sounds like Haiku’s kinda there but not quite to where it’d work. So, for now, my answer for what I’d like to build is to use Linux (for now, maybe someone will implement booting from a contained image at a GSoC or something). Sigh… thanks everyone.

What I always like to say is just about anything is possible on computers, it is just a matter of effort and someone willing to put in the time. Getting Haiku to boot from a compressed image on the EFI partition is probably not even that difficult.

In this case I think part of the confusion is Haiku kind of already works a lot more like you say than you maybe are giving it credit for. Certainly more than any other OS I know of. I think pretty much the entire OS is in haiku.hpkg. You can completely upgrade that in the way you are saying with a new version of that file, and can downgrade easily when the previous versions are saved on your writable BFS disk.

All the system directories and files are read-only because they are virtual and loaded from the PackageFS. But of course if you delete all the hpkgs, your system is hosed. Maybe something could be done to fix that, and certainly one option for that would be to put all the system hpkg files in a compressed image. But that image could maybe still be deleted since it would likely be on writable disk, even if that was the vfat/fat32 EFI disk.

Lastly your idea about this compressed image booted from the EFI partition using other images on other filesystems for persistence is actually very interesting but maybe a bit tricky. For one thing Haiku would have to be able to read and write to those filesystems to be able to read and write to image files on those systems. For vfat maybe that isn’t too bad but it is much harder for HFS+ or NTFS, where even Linux has some trouble. Plus to make life easier there would need to be some way for Haiku to know what images to load, and from what disks, which could maybe just be some well known file location or from data stored in the EFI disk.

Overall it sounds like a lot of work for a situation where if you really want to use Haiku, go ahead and give it a BFS disk to install on. Maybe the support for other filesystems could be improved to make a dual booting more pleasant, but I think at the moment the people who use Haiku are more dedicated and they want to try make it their primary system and take advantage of having BFS disks with indexing and attributes and the various other benefits.


I know how to hack this in Haiku kernel, but I am not sure about boot loader VFS ability to mount disk image. Boot loader need to read boot volume to load kernel and boot drivers.


I could try again, I’ve tried using Haiku’s boot loader and syslinux… maybe there’s a way to find something that can start from a raw image. idk what the answer is but I’m sure there is one if I try at it more…

Well to be clear it is not a matter of configuring things correctly, likely both the Haiku bootloader and kernel would need changes by a developer to work in this way. But I don’t think there is a lot of interest in working on that. There are many other issues in Haiku to work on.

1 Like