Haiku Rescue Efi Image

[nephele]

During the "Haiku is not bloat" Topic on the forums it was discussed that haiku's core image ammounts to about 270mib.

I've observed that many Linuxes pick about half a gigabyte of storage for the Efi system partition, Windows sais the minimum size is 100MiB, and for desktops the real limit is about 32MiB. I don't think it is worth targeting the 32MiB here, but ratherr the "default" Oses put on the ESP.

In any case: I would like to create a *second* Haiku image packaged as an PE executable directly, stripped down into an EFI rescue system!

For this purpose we can strip off some components of this System to decrease the size and make it usefull for this purpose, but thereby losing functions it would need for a general OS.

This should allow to install software needed for a rescue, just in the resident RAM and lost on reboot (if so desired, the software can be customized by the installing person)

This also needs support for either the kernel accepting to be a ESP file directly, or the bootloader booting an image off the ESP that isn't an PE executable (but rather a file system image). I'd rather avoid that though to make it easy to boot this from say reFind too.

Components that come to mind:

• kits
  • Mail
  • Midi
  • Media
• Applications
  • MediaPlayer
  • MidiPlayer
  • Codycam
  • Icon-O-Matic
  • Installer
  • Mail
  • MediaConverter
  • Soundrecorder
  • maybe WebPositive (perhaps replaced with Netsurf? or maybe webkit fits too)
• All Demos
• Drivers for miscelanious hardware
  • Webcams
• Preferences
  • Mail
  • VirtualMemory (hardcoded to not use swap)
  • Notifications
  • Printers
• Dependencies of haiku that are then uneeded
  • ffmpeg

[pulkomandy]

I don't see the point of logging every idea as a trac ticket. Anyway, have fun experimenting and tell us what you find, I guess?

I'm not sure integrating this into Haiku git repository is going to be convenient, unless we do quite some refactoring of the way the packages are built. We have already split out the data translators (because this has a lot of external dependencies to all the graphic libraries), and maybe we should consider continuing splitting the haiku package in that way to reduce dependencies.

Otherwise, we end up with many versions of "haiku.hpkg" that don't actually contain the same thing, and that will be confusing and difficult to manage.

[nephele]

I don't see the point of logging every idea as a trac ticket. Anyway, have fun experimenting and tell us what you find, I guess?

Where else do you expect enhancements to be filled? Not everything warrants a discussion on the forums, especially with straightforward enhancements like this.

I don't think seperate hpkg's are needed in this case, just a single haiku_rescue.hpkg with everything inside, conflicting with haiku.hpkg or something.

[X512]

This is effectively the same as booting from RAM disk with minor enhancements. Adding ability to place /boot into RAM is needed to be implemented first.

[pulkomandy]

Where else do you expect enhancements to be filled? Not everything warrants a discussion on the forums, especially with straightforward enhancements like this.

I guess that's the main problem: it is "straightforward" to you only, so far.

Making enhancement tickets means it is somehow an "official" item on the roadmap. I think I would find it interesting to read about this as a blogpost (or several blogposts), exploring what is possible with this idea, how useful it would be, etc. Right now, I admit I don't see it.

For technical discussions, it could also be a thread in the haiku-development mailing list, but it seems the mailing list is largely dormant these days. But they're still there.

I'm also very confused by the application list you chose. I definitely don't expect to play MIDI files and edit icons from a rescue system. If I needed one, the only thing I would use it for is fixing my actual system (which I usually do by booting one of my other partitions, or, if I really broke everything, from an install DVD or USB drive).

So, I guess I just don't understand what the actual use case for this would be. As an experiment to make a small Haiku system, sure, I see it. But as an actual thing we would want to ship in or alongside our releases? I don't get it.

(I'm not saying it is a bad idea, just I don't understand it)

[nephele]

Sorry, I added a paragraph in between so it wasn't completely clear, the list are components to remove, not to ship.

The usecase is exactly as you described: fixing your actual system.

The efi service partition is big enough that we can fit a slimmed down haiku "rescue image" onto it, the bootloader can then offer it as an option if you somehow screwed your system (happens infrequently, but it does happen, so it would be nice to have a recourse other than a new install medium or having a specialized install with multiple partitions in the first place)

Didn't see the point of a blogpost since it really seemed obvious to me, other OS like windows and macos have something similar where you can recover the OS if it is non-booting iirc.

[X512]

The usecase is exactly as you described: fixing your actual system.

What is the problem to write regular Haiku image to liveUSB to fix installed system?

[nephele]

How do you expect to write to a usb drive with a broken system?

This would be a functionality of the installed system, not a second install, anyway.

[X512]

How do you expect to write to a usb drive with a broken system?

It is the same with writing EFI application to ESP partition. In any case you need some working system to write rescue image. It is likely possible to write regular Haiku image to USB drive from smartphone for example (​https://f-droid.org/ja/packages/eu.depau.etchdroid/).

[nephele]

The rescue system would be installed ahead of time and just sit there untill you need, anyhow, one of my motivations behind this is that I indeed got into such a situation severall times and fixing it took severall days (since i first had to get someone to make me a haiku image) while it could have taken just some minutes. (One example was a "easy" pkgman full-sync leaving my OS unbootable because the bootloader now was too old for the compression alghorythm used, and i forgot about that. would have been a very fast fix with a rescue system)

[X512]

The rescue system would be installed ahead of time and just sit there untill you need

You can just do regular install of second system instance into separate small recovery partition (Windows do something similar with "Windows RE" partition) and/or prepare recovery Haiku boot USB/CD. Again I do not see any difference between packaging Haiku into EFI application and regular Haiku boot partition.

One example was a "easy" pkgman full-sync leaving my OS unbootable because the bootloader now was too old for the compression alghorythm used, and i forgot about that.

This can be fixed by selecting old packages state in Haiku boot loader menu.

[nephele]

The differemce is that I don't have to reinstall my OS to add this feature, and it can be updated easily from the running OS without booting to it etc. It's also much easier than telling users tp just install the OS twice (and this case would break too if the bootloader is broken for some reason, a standalone PE executable would continue to work)

This can be fixed by selecting old packages state in Haiku boot loader menu.

In that case it did not work, and it is entirely possible there will be incompatibilities or errors i the future that cause problems that we don't know about yet.

[kallisti5]

I'm going to ask the devils advocate questions.

We already support disabling packages, and removing files on bootup through our bootloader. We also support a "safemode" startup disabling non-essential system components.

Users also would already have the Haiku installation media at hand from when they installed Haiku. So what would making them download an additional smaller installer do beyond what we have already provided them?

also, what you're talking about is literally a @nightly-minimum build of Haiku.

With the above said, I do "get" what you're looking for.. i'm just not sure there would be a big use-case for it.

[nephele]

Yes, I don't expect that every user needs this, but it would be relatively painless to install on OS installation automatically or afterwards and would remove the need for any OS images on a thumb drive.

nightöy minimum is probably fine, just packaged as an fa image the efi loader can boot :)