Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to boot on real hardware or bhyve (Exhausted heap space) #173

Open
shamazmazum opened this issue Aug 5, 2020 · 9 comments
Open

Comments

@shamazmazum
Copy link

When trying to boot with bhyve or real hardware, the bootloader loads about 116000 pages and then fails with the following:

vasily@resurrected:/home/shared/test % bhyve -c 2 -m 10G -w -H -s 0,hostbridge -s 4,ahci-cd,Mezzano.Demo.5.CD-USB-hybrid.iso -s 29,fbuf,tcp=192.168.20.1:5901,w=1920,h=1080,wait -s 30,xhci,tablet -s 31,lpc -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE-devel.fd mezzano
Unable to setup memory (22)
vasily@resurrected:/home/shared/test % bhyve -c 2 -m 10G -w -H -s 0,hostbridge -s 4,ahci-cd,Mezzano.Demo.5.CD-USB-hybrid.iso -s 29,fbuf,tcp=192.168.20.1:5901,w=1920,h=1080,wait -s 30,xhci,tablet -s 31,lpc -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE-devel.fd mezzano
fbuf frame buffer base: 0xac1e00000 [sz 16777216]
BdsDxe: loading Boot0001 "UEFI BHYVE SATA DVD ROM BHYVE-83CE-D888-D389" from PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)
BdsDxe: starting Boot0001 "UEFI BHYVE SATA DVD ROM BHYVE-83CE-D888-D389" from PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)
efi: base @ 0xbe23e000, text @ 0xbe23f000, data @ 0xbe258000, bss @ 0xbe265000
efi: usable memory ranges (31 total):
 0x0000000000001000-0x00000000000a0000 (636 KiB)
 0x0000000000100000-0x0000000000806000 (7192 KiB)
 0x0000000000807000-0x0000000000820000 (100 KiB)
 0x0000000001400000-0x00000000bbfbe000 (3059448 KiB)
 0x00000000bbfde000-0x00000000be23e000 (35200 KiB)
 0x00000000beb1b000-0x00000000beea4000 (3620 KiB)
 0x00000000bf200000-0x00000000bf201000 (4 KiB)
 0x00000000bfe00000-0x00000000bff39000 (1252 KiB)
 0x0000000100000000-0x00000002c0000000 (7340032 KiB)
loader: version is 20151220+42af04c
efi: boot device is PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)/CDROM(0x1,0x63,0x800)
fs: mounted ISO9660 on cdrom0 ('CDROM') (uuid: 2020-07-24-17-08-49-00)
device: detected devices:
 cdrom0  -> EFI disk PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)
device: boot device is cdrom0
config: reading configuration file '/boot/kboot.cfg'
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
mezzano: Loading image 5cf6ee79-2cdf-05a1-ba4b-6325c41a5f10 on device /image with protocol version 0.26
mezzano: Entry fref at 7fff8cde09. Initial process at 013c3139.
menu: booting menu entry 'Mezzano - video console'
Loading 133179 pages...

Internal Error: Exhausted heap space (want 1360 bytes)

Please report this error to https://github.com/aejsmith/kboot
Version: 20151220+42af04c
Backtrace (base = 0xbe23e000):
 0xbe251b43 (0x13b43)
 0xbe25304e (0x1504e)
 0xbe2439ac (0x59ac)
 0xbe242e55 (0x4e55)
 0xbe24db63 (0xfb63)
 0xbe250044 (0x12044)
 0xbe250271 (0x12271)
 0xbe25058a (0x1258a)
 0xbe252e68 (0x14e68)
 0xbe243761 (0x5761)
 0xbff6aacc (0x1d2cacc)

Both real hardware and bhyve use UEFI for booting the OS. Should I probably report this to aejsmith/kboot as suggested?

@froggey
Copy link
Owner

froggey commented Aug 5, 2020

This is a known problem on EFI systems and should be fixed with the latest kboot.
You could try replacing kboot in the image with the latest build, binary available at https://github.com/froggey/Mezzano/blob/master/tools/kboot/kbootx64.efi or booting the system in non-EFI/legacy compatibility mode

@shamazmazum
Copy link
Author

shamazmazum commented Aug 6, 2020

This does not work, unfortunately. On my real hardware I have chosen "Legacy OPROM only" boot option and it boots fine. bhyve does not support old BIOS, so no luck with VM :(

Thanks for the help!

@fitzsim fitzsim closed this as completed Mar 8, 2024
@shamazmazum
Copy link
Author

@fitzsim, hi! Do you mind if I ask, why have you closed the issue? It seems that this project is dead, so I understand that probably this problem will not be solved at all. But it seems that the issue must be closed as completed if only it's really completed. Maybe Mezzano is developed somewhere else now?

@Hexstream
Copy link
Contributor

Hexstream commented Mar 8, 2024

Do you mind if I ask, why have you closed the issue?

Probably useful to note that @fitzsim has helpfully closed 20+ older issues today, I had reviewed all the closed threads and did not find the closings particularly objectionable... (Perhaps this specific issue could or should be reopened, I'm just sharing my overall impression.)

It seems that this project is dead

I don't think it's fair or useful to assume that the project is "dead" just because there has been no public commit activity for around 1 year and 1 month, especially considering that froggey has been doing almost all of the work and has multiple times in the past worked privately for several months and then released dozens of commits at once.

I'm also empathetic to the fact that life frequently gets in the way of raw productivity in unexpectedly time-consuming ways, having repeatedly experienced the situation myself, especially in recent years.

Lastly, the fact that @fitzsim has been assigned as a contributor and been doing some cleanup work should probably be seen as a sign of liveness...

But it seems that the issue must be closed as completed if only it's really completed.

I wouldn't read too much into the fact that the issue has been closed as "completed" specifically, given that this is a relatively new GitHub feature and "completed" is the default. Perhaps there should be a third, more ambiguous option between "completed" and "not planned"...

I hope this alleviates some of your concerns...

@fitzsim fitzsim reopened this Mar 8, 2024
@mmontone
Copy link

mmontone commented Mar 8, 2024

I don't think it's fair or useful to assume that the project is "dead" just because there has been no public commit activity for around 1 year and 1 month, especially considering that froggey has been doing almost all of the work and has multiple times in the past worked privately for several months and then released dozens of commits at once.

froggey said on IRC that she stopped working on Mezzano (no more energy to put into the project).

@Hexstream
Copy link
Contributor

Sad, but good to know, thanks!

(Sometimes, one arrives at the right conclusion through faulty reasoning...)

@fitzsim
Copy link
Collaborator

fitzsim commented Mar 9, 2024

@shamazmazum You should probably build latest kboot from source, then instrument it to narrow down the point of failure. I use the kboot loader for QEMU, but on my ThinkPad I load Mezzano via: libreboot -> Grub2 -> mezzano.mod (a module I wrote). If Grub works in your setup, then perhaps mezzano.mod could help, though I have only tested it against Grub-as-a-Libreboot/coreboot-payload, not against Grub loaded via EFI or BIOS. The code for mezzano.mod is published: https://git.sr.ht/~fitzsim/grub

@shamazmazum
Copy link
Author

@fitzsim Thanks for the tips and reopening!

@shamazmazum
Copy link
Author

@fitzsim Hi! I tried it again without success. Firstly, newly built kboot (from the master branch of https://github.com/aejsmith/kboot) says it does not understand the command "mezzano" (I think it's in kboot.cfg). Secondly, I was able to build your mezzano.mod, but I cannot figure out, what is it for. Is it a standalone bootloader or some mod to that GRUB program? If the latter, where can I acquire GRUB binaries?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants