beeos icon indicating copy to clipboard operation
beeos copied to clipboard

*** kernel panic: init exiting

Open garrettgu10 opened this issue 3 years ago • 5 comments

I have tried building this kernel on a few different machines but seem to have an issue getting a build to run in QEMU.

I didn't make any changes to the source code, and simply ran the following commands: make all && (cd misc; sudo ./mkfs.sh; ./qemu.sh)

From some preliminary println debugging, it seems that the execve syscall is throwing an error, since named(path) ends up being NULL. This is due to !S_ISDIR(dent->inod->mode) in named() returning false on the first iteration.

I am testing on a very clean version of Ubuntu 20.04.2 LTS.

I would love if you could give some insight as to why the first build might not be succeeding. I have attached the disk.img file below.

Thanks!

disk.zip

garrettgu10 avatar Mar 05 '21 02:03 garrettgu10

I have had the same problem (no source code changes)

solomonw1 avatar Dec 30 '21 06:12 solomonw1

Hello @davxy, Is there any new update on this bug? Or do you have any temporary patch that could fix this problem?: image

AxelPreitiT avatar Nov 23 '22 19:11 AxelPreitiT

Hello @davxy, Is there any new update on this bug? Or do you have any temporary patch that could fix this problem?: image

@AxelPreitiT hey I'll look into it soon(ish). For sure not before next month. In the meantime, can you share the disk image that causes you the panic? TY

davxy avatar Nov 24 '22 20:11 davxy

Hello @davxy, Is there any new update on this bug? Or do you have any temporary patch that could fix this problem?: image

@AxelPreitiT hey I'll look into it soon(ish). For sure not before next month. In the meantime, can you share the disk image that causes you the panic? TY

Hello! I had the same problem as @AxelPreitiT. I discovered that the command "sudo ./mkfs.sh" is throwing a bunch of errors. Probably no one saw that because in the readme the suggested command is "(cd misc && sudo ./mkfs.sh)". As these commands are being executed in a subshell (because of the parentheses), the errors don't show in screen. I attached screenshot below that shows the error I'm getting (which probably is causing the kernel panic).

image

azakalik avatar Nov 25 '22 21:11 azakalik