Martin Decky wrote:
The second binary also fails to load, but this is silently ignored. If
the last binary fails to load, it is considered a RAM disk with the
initial root file system (the kernel does not touch the RAM disk, it
only passes it to the user space) and nothing is reported.
We could do a one line notice that would say something like 'Found RAM disk
'<binary-name>'.
I know, this
is not very user-friendly for debugging, but it is simply the way it is
supposed to work.
Now that actually all our boot methods support binary names, we could change
it. Currently:
- last binary that fails to load is a RAM disk (which is not executed)
- a binary that is statically linked, nevertheless has a PT_INTERP header is
the loader (which is not executed)
I believe the latter makes the loader binary quite unusual, leading to
http://trac.helenos.org/ticket/430 (which is IMHO a bug in strip/BFD). We could
change it so that:
- the binary named 'initrd' is the ram disk
- the binary named 'loader' is the loader
and we might want to announce the loader and RAM disk (always) in the kernel
log - we don't need to announce regular executables, since they will usually
print their own banner when they start.
-Jiri
Error code -11 is ENOTSUP (returned from program_create_from_image())
which means that the elf_load() failed. I have committed a small
changeset to our mainline branch which shows the return value of
elf_load() if the kernel is compiled with the CONFIG_LOG (Detailed
kernel logging) option.
Thus the obvious thing to do now is to look at elf_load() and analyse
what it dislikes about your binaries.
M.D.
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
