Invalid symbol table on NetBSD boot

Invalid symbol table on NetBSD boot

[Grégoire Sutre]

Hi,

When booting a NetBSD 5.0 (i386 or amd64) kernel with knetbsd (as per
docs/grub.cfg), the first message displayed by the NetBSD kernel is:

[ Kernel symbol table invalid! ]

and after boot, the device /dev/ksyms is not configured.  The same
problem occurs with multiboot instead of knetbsd (for i386 only, as the
NetBSD kernel does not support multiboot on amd64).

However, the system after boot seems to work fine.  This issue
apparently only affects the in-kernel debugger.

A similar problem is mentioned in the archives of the mailing list [1]. 
  I tried to adapt the patch given in [1] to the current trunk, but with 
no luck.  And the patch focuses on multiboot, so I guess it would not 
solve the problem with knetbsd.  This stuff is way above my head 
anyway...  But I'd happy to help by testing :-)

Thanks for your help,

Grégoire

[1] http://lists.gnu.org/archive/html/grub-devel/2008-09/msg00194.html

Re: Invalid symbol table on NetBSD boot

[Robert Millan]

On Wed, Jan 06, 2010 at 07:07:29PM +0100, Grégoire Sutre wrote:
>
> A similar problem is mentioned in the archives of the mailing list [1].  
> I tried to adapt the patch given in [1] to the current trunk, but with  
> no luck.

I suggest you test if GRUB Legacy's Multiboot loader supports this
properly, as the code I used derives from that.

(be careful though, GRUB Legacy has a unified "kernel" command so when
given a kernel of NetBSD it might not use Multiboot automatically)

> And the patch focuses on multiboot, so I guess it would not  
> solve the problem with knetbsd.

I believe NetBSD kernel developers (that'd be jmmv) implemented Multiboot
support in order to avoid duplication of efforts.  I think it's appropiate
to consider knetbsd loader as "legacy" and resolve this problem in our
multiboot loader.

(but I'm not against improving knetbsd loader of course)

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: Invalid symbol table on NetBSD boot

[Grégoire Sutre]

Robert Millan wrote:

> I suggest you test if GRUB Legacy's Multiboot loader supports this
> properly, as the code I used derives from that.

Yes, the problem disappears with GRUB Legacy's multiboot.  Moreover, I 
noticed another issue: the command line is stripped (first word missing) 
with GRUB 2's multiboot. Here are the logs.  After setting the root 
variable appropriately, I get:

--- With GRUB Legacy ---------------------------------------------------

grub> kernel /netbsd.generic -z root=wd0a
    [Multiboot-elf, ...]
grub> boot

And everything works as expected: silent boot (-z), root device not 
asked by the kernel, /dev/ksyms working.  The kernel says (dmesg):

multiboot: Information structure flags: 0x000003e7
multiboot: Boot loader: GNU GRUB 0.97
multiboot: Command line: /netbsd.generic -z root=wd0a
multiboot: 638 KB lower memory, 1562048 KB upper memory
multiboot: Symbol table at 0xc0b980d4, length 519152 bytes
multiboot: String table at 0xc0c16cc4, length 505776 bytes

--- With GRUB 2 -------------------------------------------------------

grub> multiboot /netbsd.generic -z root=wd0a
grub> boot

And the kernel here does not boot silently, but takes into account 
`root=wd0a'.  As reported before, /dev/ksyms does not work.  The kernel 
says (dmesg):

multiboot: Information structure flags: 0x00000247
multiboot: Boot loader: GRUB 1.97
multiboot: Command line: -z root=wd0a
multiboot: 638 KB lower memory, 1562048 KB upper memory

Nothing regarding symbol or string tables.  See also how the command 
line seen by the kernel is missing `/netbsd.generic' w.r.t. GRUB Legacy. 
  If I use

grub> multiboot /netbsd.generic dummy -z root=wd0a

then the kernel boots silently (-z), and command line reported by the 
kernel is `dummy -z root=wd0a'.
-----------------------------------------------------------------------


> I believe NetBSD kernel developers (that'd be jmmv) implemented Multiboot
> support in order to avoid duplication of efforts.

AFAICS, it's implemented only for i386 in NetBSD stable.

> I think it's appropiate
> to consider knetbsd loader as "legacy" and resolve this problem in our
> multiboot loader.

Ok.

Grégoire

Re: Invalid symbol table on NetBSD boot

[Robert Millan]

On Fri, Jan 08, 2010 at 01:44:25AM +0100, Grégoire Sutre wrote:
> Robert Millan wrote:
>
>> I suggest you test if GRUB Legacy's Multiboot loader supports this
>> properly, as the code I used derives from that.
>
> Yes, the problem disappears with GRUB Legacy's multiboot.  Moreover, I  
> noticed another issue: the command line is stripped (first word missing)  
> with GRUB 2's multiboot. Here are the logs.  After setting the root  
> variable appropriately, I get:
>
> --- With GRUB Legacy ---------------------------------------------------
> grub> kernel /netbsd.generic -z root=wd0a
> [...]
> --- With GRUB 2 -------------------------------------------------------
> grub> multiboot /netbsd.generic -z root=wd0a

There was an intentional backward-incompatible (but still compatible with
the specification) change.  The equivalent command on GRUB 2 would be:

grub> multiboot /netbsd.generic /netbsd.generic -z root=wd0a

First argument is the file being open;  in GRUB Legacy it's implicitly also
the first arg passed to payload, which is less flexible than letting user
specify it.  It doesn't have to be the filename at all, and usually the
payload doesn't need this information.

I'm not sure if this explains your missing word problem, but it sounds like
it could be related.

-- 
Robert Millan

  "Be the change you want to see in the world" -- Gandhi

Re: Invalid symbol table on NetBSD boot

[Grégoire Sutre]

Robert Millan wrote:

>> grub> multiboot /netbsd.generic -z root=wd0a
> 
> There was an intentional backward-incompatible (but still compatible with
> the specification) change.  The equivalent command on GRUB 2 would be:
> 
> grub> multiboot /netbsd.generic /netbsd.generic -z root=wd0a

Ok.

> First argument is the file being open;  in GRUB Legacy it's implicitly also
> the first arg passed to payload, which is less flexible than letting user
> specify it.  It doesn't have to be the filename at all, and usually the
> payload doesn't need this information.

I don't know how it is used in NetBSD, the only difference I could 
observe is the sysctl parameter `machdep.booted_kernel' which is set to 
the file name of the booted kernel (or empty if the information could 
not be derived from the multiboot command-line).

> I'm not sure if this explains your missing word problem, but it sounds like
> it could be related.

Yes, it sure explains the problem, thanks!  I had a look at the 
multiboot command-line parsing in the NetBSD kernel: the first argument 
in the command-line is ignored (here `-z') as it is assumed to be the 
kernel file name.

Anyway, the above solution (duplicating the kernel file name) is simple 
enough. :-)

Grégoire