Add support for initramfs

[piranna]

At NodeOS we are thinking about using your bootloader but seems we are having problems probably because we are using a initramfs image instead of an initrd. Could it be possible to add support for it?

[owenson]

To my knowledge there is no difference for the bootloader. What's the problem you're experiencing?

[piranna]

Thanks for your answer :-) I haven't had the problem myself, but I have asked for more details on the issue I've linked you. Being different formats, shouldn't they be loaded differently? (I ignore it...)

[owenson]

Initrd is a typo in the readme. It was tested with an initramfs image. In either case the bootloader doesn't do any processing on it.

[piranna]

Maybe @sbuller could give you more details about the problems he has had, he's the guy that was experimenting with tiny-linux-bootloader.

[sbuller]

That was a week or two ago during a whirlwind tour of whatever options I could dig up.

All I ever got was

Booting from Hard Disk...
err!!

I made a show of trying to dig through things with gdb, but I didn't really get anywhere. There was also no indication of x86_64 support, which I find somewhat important.

[owenson]

Hi

There's little point in supporting uefi because the kernel itself can be setup to act as the bootloader.

Happy to look at your disk image for you.

Best
Gareth

[sbuller]

I'm not interested in uefi support either. It's 64bit support I need. I'm not sure if it's the bootloader or the kernel that handles that transition.

Anyhow, the disk image I produced using build.sh is below, along with the two files used to generate it - barebones (the kernel image), and init. I've verified I can boot qemu using the -kernel and -initrd parameters with these files.

http://filebin.ca/2r7SFiHjQkXU/disk

http://filebin.ca/2r7SY8NXGKwd/barebones
http://filebin.ca/2r7SozgVa65N/init

[owenson]

Hi

I've debugged the problem. I didn't envisage that anyone would load such a small init and that's causing the bootloader to bomb out. You can fix this simply by doing:

dd if=/dev/zero bs=512 count=130 >> init

(do it once to your init)

then run the build script. You kernel and init work when I do this.

I'll look at fixing it but it seems a fairly rare edge case. Most inits are many megs.

[owenson]

PS. x86_64 is the same as i386 as far as the bootloader concerns (provided you're not including UEFI).

[piranna]

Most inits are many megs.

NodeOS has an initramfs bundled inside the Linux kernel itself, hosting the standard C lib, a minimal init and the Node.js binary. nodeos-initramfs on the other hand just only have some Node.js modules to mount the users filesystems and the ExclFS over /dev, that's why it's so small.

[owenson]

Yes I understand. Will have a look see if I can fix it - but I only have a few hundred bytes to do everything so catching everything is impossible.

[piranna]

Also @sbuller is using a custom initramfs with just his app code, so that's why is so small :-)

[owenson]

An interim solution is to add the DD command above to the build script.

[piranna]

I only have a few hundred bytes to do everything so catching everything is impossible

Don't worry, take your time :-)

An interim solution is to add the DD command above to the build script.

Not a bad idea as a short term solution...

[sbuller]

Actually, I'm quite comfortable with the solution; thanks for finding it. I really don't think it's worth a more complicated fix. Is 130 sectors the minimum size then?

[piranna]

Actually, I'm quite comfortable with the solution; thanks for finding it. I really don't think it's worth a more complicated fix.

Just don't forget to add a TODO comment about it ;-)

[owenson]

I've just checked in a fix, it should tolerate any size init now. Thanks for finding the bug.