Implement kernel bootstrap up to building Linux.

[rick-masters]

Resolves #252

[fosslinux]

This is a first-pass review, there's some things I haven't really looked at in detail yet but there's a few larger architectural things;

1. I would like for --kernel-bootstrap to be the default, when QEMU is used. This is meant to be the default pathway. Then, if --kernel is given, then we can not use the fiwix/builder-hex0 stuff.
2. I apologise for not communicating this one earlier, as this has been on my mind for a while with this. I'd like, when running under Fiwix, for an initramfs not to be used (or, at least, used to the minimal extent possible - but from my relatively brief look over this it doesn't appear required). At minimum, it'd be great if all the packages could be build on-disk rather than in-ram (initramfs). This will allow live-bootstrap to be build on much lower memory machines and allow for sysa to be expanded without issue. builder-hex0 does look like it can write to/read from disk, but I'm not sure if that extends to the creation of an EXT filesystem on a disk?
3. This one is more of a question - what's the rationale for using builder-hex0 to start, instead of say, builder-hex0-mini? (it probably doesn't really matter, because both are hex0 anyway, but just wanted to hear your thoughts).

Thank you very much for this PR, I'm excited to get this in 🎉

[fosslinux]

Also, with your comment in #252, will this currently fail or do something else when transferring from fiwix -> linux?

Other thing I just thought of, architecturally I think it would be more consistent to split sysa into sysa and sysb, where sysa is builder-hex0 and sysb is fiwix, and then the current sysb can be removed, since we have guranteed hard disk support in fiwix.

[rick-masters]

@fosslinux
For your other questions:

1. I will work on making removing --kernel-bootstrap and make it the default instead.
2. I will explore writing the ext2 image to disk instead of using a ram drive. This would mean overwriting the builder-hex0 srcfs disk image. One issue is that I believe it may exceed the size of a hard drive supported by a simple BIOS using Cylinder/Head/Sector calculations, at least with the current default qemu disk geometry. It might require LBA but I'm not sure.
3. I think it is a reasonable goal to start with something small like builder-hex0-mini that complies builder-hex0. The problem with the current design of builder-hex0-mini is that it writes the compiled binary to the start of disk and depends on a reboot to activate it. As with the transition to Fiwix I think a reboot can be avoided. This would take some work. I'd postpone this until after the initial integration.
4. There is currently no transition from Fiwix to Linux so the bootstrap stops soon after Linux is compiled. That may be a reason to postpone making --kernel-bootstrap the default initially until I can complete the Fiwix to Linux boot transition.

It is not very clear to me how a redesign with Fiwix as sysb would work exactly. Sysb is currently used for booting Linux (I think) so I don't see how that changes. (To be honest, I'm not sure I want to sign up for changing the method of booting Linux.) I think I'd need some more details to understand what you are suggesting.

It might be a while until I submit the next updated PR. I'm taking a breather to work at a more leisurely pace for a little while.

[stikonas]

@fosslinux For your other questions:

2. I will explore writing the ext2 image to disk instead of using a ram drive. This would mean overwriting the builder-hex0 srcfs disk image. One issue is that I believe it may exceed the size of a hard drive supported by a simple BIOS using Cylinder/Head/Sector calculations, at least with the current default qemu disk geometry. It might require LBA but I'm not sure.

Perhaps it might be simpler to do something like this:

• builder-hex0 boots fiwix with ram drive.
• fiwix then has a hard drive support, so we then populate the hard drive and transition into another fwix.

This would add another kexec like transition but perhaps code can mostly be shared with fiwix to linux transition?

[fosslinux]

I will explore writing the ext2 image to disk instead of using a ram drive. This would mean overwriting the builder-hex0 srcfs disk image. One issue is that I believe it may exceed the size of a hard drive supported by a simple BIOS using Cylinder/Head/Sector calculations, at least with the current default qemu disk geometry. It might require LBA but I'm not sure.

Sounds good. If you think that @stikonas method would be easier, or if two separate disks are used for builder-hex0 and fiwix, that's alright with me.

I think it is a reasonable goal to start with something small like builder-hex0-mini that complies builder-hex0. The problem with the current design of builder-hex0-mini is that it writes the compiled binary to the start of disk and depends on a reboot to activate it. As with the transition to Fiwix I think a reboot can be avoided. This would take some work. I'd postpone this until after the initial integration.

No worries about this for the time being, then - this can come later, as you said.

There is currently no transition from Fiwix to Linux so the bootstrap stops soon after Linux is compiled. That may be a reason to postpone making --kernel-bootstrap the default initially until I can complete the Fiwix to Linux boot transition.

Ah, ok. In my opinion, let's still make --kernel-bootstrap the default, but document/add warnings that --kernel should still be used for a full build. Happy to hear other thoughts though.

It might be a while until I submit the next updated PR. I'm taking a breather to work at a more leisurely pace for a little while.

That is absolutely fine! It is good to spend some time for ourselves.

[rick-masters]

@stikonas

fiwix then has a hard drive support, so we then populate the hard drive and transition into another fwix.

I'm not sure this question matters yet. builder-hex0/BIOS may be able to write to a larger hard disk by using a bigger disk geometry. I just need to look into it. If not, maybe your Linux changes will save enough space. We need to save approx. 140MB to keep under the limit of the current geometry. (Which is 1024 cylinders * 32 heads * 63 sectors * 512 bytes/sector)

@fosslinux
Note that eliminating a Fiwix ram drive does not reduce overall memory requirements. Currently builder-hex0 uses 3GB which is more than Fiwix. The usage is approx. 650MB for live-bootstrap distfiles and builds, 1152MB for the Fiwix ext2 image, 670MB for running processes, and 604MB for suspended processes. Even if the ext2 image is copied to disk it needs to be created in memory first (with the current design of builder-hex0.)

The vast majority of the 1.2GB for processes is for mes. I could eliminate half (the memory for suspended processes) by implementing virtual memory but I'm reluctant to add that complexity. Long term really getting memory down means redesigning or replacing mes, IMHO.

That said, there is a significant benefit to moving away from a Fiwix ram disk. My modification to Fiwix to support large ram drives was difficult/complex/messy and I'd rather not try to upstream it:
rick-masters/Fiwix@747a763

So, I'll continue to look at how to boot Fiwix off a hard drive. For the transition to Linux, I expect sysb/run.sh would need to be modified to do one of: format the first drive (overwriting sysa), format a second partition on the first drive, or format a (or use a pre-formatted) second drive.

[fosslinux]

Note that eliminating a Fiwix ram drive does not reduce overall memory requirements. Currently builder-hex0 uses 3GB which is more than Fiwix. The usage is approx. 650MB for live-bootstrap distfiles and builds, 1152MB for the Fiwix ext2 image, 670MB for running processes, and 604MB for suspended processes. Even if the ext2 image is copied to disk it needs to be created in memory first (with the current design of builder-hex0.)

This is not particularly problematic. If sysa is expanded or more packages are added, then the only added cost to RAM is distfiles & possibly the ext2 image. However, in the current state, we also need to have disk space available for the compilation process - this is where compiling large packages such as the Linux kernel can become very problematic. With Fiwix it seems we should be able to eliminate this problem.

So, I'll continue to look at how to boot Fiwix off a hard drive. For the transition to Linux, I expect sysb/run.sh would need to be modified to do one of: format the first drive (overwriting sysa), format a second partition on the first drive, or format a (or use a pre-formatted) second drive.

If you can handle the Fiwix side, I'd be happy to do this bit.

[rick-masters]

@fosslinux
With Fiwix it seems we should be able to eliminate this problem.

I'm not sure how. If we need more space for compilation then the ext2 image needs to be expanded and since that is created in memory with builder-hex0, it expands the memory requirements. builder-hex0 is near usable memory limits already which is 3GB without implementing PAE.
Perhaps you are suggesting Fiwix could expand the ext2 file system once on disk or format another partition or disk?

[fosslinux]

superseded by #272