official builds - haiku_loader.bios_ia32 is too big (396664) to fit

[kallisti5]

The build system isn't handling this failure gracefully in #17959. jam returns 1 and concourse doesn't catch the failure.

Somewhere between hrev56476-hrev56480, the haiku_loader.bios_ia32 became too big to fit when --distro-compatibility official is passed to configure (as with official builds)

[kallisti5]

Solution proposed in ​https://review.haiku-os.org/c/haiku/+/5704.

Reverting ​https://cgit.haiku-os.org/haiku/commit/?id=5897f7b6235d36a58582513ad5db270d9b1ce926 resolves the issue.

[davidkaroly]

How did we end up with such a large BIOS loader? I get something like 379128 bytes when I build locally which should fit in the 384K easily.

[kallisti5]

The trigger for this one was passing the --distro-compatibility official to configure. It enables lots of things the official builds get that the "self-developed" builds don't.

My armchair guess is the Haiku logo getting added pushed it over vs your local build.

[davidkaroly]

I can see it now with HAIKU_DISTRO_COMPATIBILITY=official, I also get a haiku_loader.bios_ia32 that is too large.

[davidkaroly]

Can we increase HAIKU_BOOT_ARCHIVE_IMAGE_OFFSET in ArchitectureRules? Even if we kludge this issue with some more ifdefs, #16944 would also increase the bootloader size. (unless we add hrev only to EFI loader but not to BIOS loader)

[kallisti5]

hmmmmm. Now we're getting to the code I absolutely hate lol.

HAIKU_BOOT_FLOPPY is a floppy disk image with our drivers on it. It acts (or acted) as an initrd on a lot of platforms to get some early drivers into the bootup.

*HOWEVER*, looking at the following locations... it doesn't seem used anymore..

• build/jam/images/CDBootImage (disabled?)
• build/jam/images/AnybootImage (Just deleting it?)
• build/jam/images/FloppyBootImage (Creating it.)

I think i've brought up removing it, but some folks said it was still used at startup. I'm not 100% sure where however.

[kallisti5]

Looking up what bootloaders we inform about the floppyboot image is telling...

$ grep -R "BOOT_ARCHIVE_IMAGE_OFFSET" src/
src/system/boot/loader/file_systems/tarfs/tarfs.cpp:static const uint32 kFloppyArchiveOffset = BOOT_ARCHIVE_IMAGE_OFFSET * 1024;
src/system/boot/platform/amiga_m68k/shell.S:	.word	BOOT_ARCHIVE_IMAGE_OFFSET*2
src/system/boot/platform/atari_m68k/shell.S:	// modules will start at offset BOOT_ARCHIVE_IMAGE_OFFSET kB.
src/system/boot/platform/atari_m68k/shell.S:	.word	BOOT_ARCHIVE_IMAGE_OFFSET*2
src/system/boot/platform/bios_ia32/shell.S:	.word BOOT_ARCHIVE_IMAGE_OFFSET*2

So yeah.. definitely used for bios_ia32 in some way. I think it gets shoved before the Haiku partition during the build... the logic is just weird.

Just increasing the HAIKU_BOOT_ARCHIVE_IMAGE_OFFSET might solve it. I think R2 we should drop MBR / Legacy booting all together. Then the floppyboot can be decoupled from such critical code and we can generate the floppy boot archive "as needed"

[waddlesplash]

We definitely should not drop MBR/Legacy in R2. It works fine, we spend a few minutes fixing it now and again, there's no reason to drop it. And, I think the floppyboot is used for the anyboot multi-medium booting somehow?

A better question is how the loader is almost half a MB. That's much larger than I would have expected. Where is all that space going?

[davidkaroly]

the bios loader is around 384K (just on the limit)

significant amount of space seems to be taken up by the various file system drivers including packagefs - i'm not sure if there's much room for optimization there

[waddlesplash]

I switched the bootloaders to use -Os instead of -O2 saving almost 100KB in hrev56502, that should hold us off for a while.