[parisc-linux] vmlinux header for savecrash.

[parisc-linux] vmlinux header for savecrash.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

	Hi
As I said few days ago, I've a dump driver ready.
Now I'm working on a savecrash command. It works fine
for the dump, but I need to save with the dump some
informations like the running kernel at dump time.
So in the dump I've got this informations:
utsname_release and utsname_version. Now, how can
I found the right kernel in /boot ? In other
word, how can I retrieve utsname informations in a
binary file (without system.map and gdb) ?

	Thanks.

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] vmlinux header for savecrash.

[Grant Grundler]

Bruno Vidal wrote:
> As I said few days ago, I've a dump driver ready.
> Now I'm working on a savecrash command. It works fine
> for the dump, but I need to save with the dump some
> informations like the running kernel at dump time.

Bruno - this is great!


> So in the dump I've got this informations:
> utsname_release and utsname_version. Now, how can
> I found the right kernel in /boot ? In other
> word, how can I retrieve utsname informations in a
> binary file (without system.map and gdb) ?

A couple of ideas/hacks:
o assume it's /boot/System.map + /boot/vmlinux. Tell people if they
  want to use dump/savecrash, that's what they have to do.

o assume it's in /boot. Use fgrep to find the matching strings.
  Something like
	#!/bin/sh
	cd /boot
	for i in *
	do
		fgrep $1 $i > /dev/null 2>&1
		if [ $? -eq 0 ]
		then
			echo $i
			exit 0
		fi
	done
	exit 1

The case that /boot might not be mounted could cause problems.

Since klogd seems to want System.map, perhaps savecrash could use
the same heuristics to find the "right" System.map.
See Documentation/oops-tracing.txt for more details.

hth,
grant

Re: [parisc-linux] vmlinux header for savecrash.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]

	Sorry, but on my system, fgrep gives nothing
(and by using strings, I found nothing also). And I
can't use dmesg buffer, because by definition it is a buffer,
so after running sometime, the palo boot strings is not
in the buffer anymore. Some new ideas ?

	Thanks.

Grant Grundler wrote:
> 
> Bruno Vidal wrote:
> > As I said few days ago, I've a dump driver ready.
> > Now I'm working on a savecrash command. It works fine
> > for the dump, but I need to save with the dump some
> > informations like the running kernel at dump time.
> 
> Bruno - this is great!
> 
> > So in the dump I've got this informations:
> > utsname_release and utsname_version. Now, how can
> > I found the right kernel in /boot ? In other
> > word, how can I retrieve utsname informations in a
> > binary file (without system.map and gdb) ?
> 
> A couple of ideas/hacks:
> o assume it's /boot/System.map + /boot/vmlinux. Tell people if they
>   want to use dump/savecrash, that's what they have to do.
> 
> o assume it's in /boot. Use fgrep to find the matching strings.
>   Something like
>         #!/bin/sh
>         cd /boot
>         for i in *
>         do
>                 fgrep $1 $i > /dev/null 2>&1
>                 if [ $? -eq 0 ]
>                 then
>                         echo $i
>                         exit 0
>                 fi
>         done
>         exit 1
> 
> The case that /boot might not be mounted could cause problems.
> 
> Since klogd seems to want System.map, perhaps savecrash could use
> the same heuristics to find the "right" System.map.
> See Documentation/oops-tracing.txt for more details.
> 
> hth,
> grant

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] vmlinux header for savecrash.

[Enrik Berkhan]

On Tue, Jan 22, 2002 at 10:20:59AM +0100, Bruno Vidal wrote:
> 	Sorry, but on my system, fgrep gives nothing
> (and by using strings, I found nothing also). And I
> can't use dmesg buffer, because by definition it is a buffer,
> so after running sometime, the palo boot strings is not
> in the buffer anymore. Some new ideas ?

I think the correct way would be to use libbfd to achieve something
similar to the following in "shell notation":

| objdump -t vmlinux| grep " system_utsname"
102860c0 g     O .data  00000186 system_utsname
^ start                 ^ size
| objdump --start-address=0x102860c0 --stop-address=0x10286246 vmlinux
...
102860c0 4c696e75 78000000 00000000 00000000  Linux...........
102860d0 00000000 00000000 00000000 00000000  ................
102860e0 00000000 00000000 00000000 00000000  ................
102860f0 00000000 00000000 00000000 00000000  ................
10286100 00286e6f 6e652900 00000000 00000000  .(none).........
10286110 00000000 00000000 00000000 00000000  ................
10286120 00000000 00000000 00000000 00000000  ................
10286130 00000000 00000000 00000000 00000000  ................
10286140 0000322e 342e3137 2d706131 31000000  ..2.4.17-pa11...
10286150 00000000 00000000 00000000 00000000  ................
10286160 00000000 00000000 00000000 00000000  ................
10286170 00000000 00000000 00000000 00000000  ................
10286180 00000023 3134204d 6f6e204a 616e2032  ...#14 Mon Jan 2
10286190 31203230 3a34323a 33352043 45542032  1 20:42:35 CET 2
102861a0 30303200 00000000 00000000 00000000  002.............
...

Using libbfd it should be feasible to read a "struct new_utsname"
from the binaries. Sorry, but don't have the time for a better
proof-of-concept than using objdump today.

Enrik
-- 
Enrik Berkhan                                         plan b. GmbH
                                                      Rüppurrer Straße 4
+49-721-388582 (voice)                                76137 Karlsruhe
+49-721-388581 (fax)                                  Germany

Re: [parisc-linux] vmlinux header for savecrash.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

	Hi
I think that Enrik has a good starting point, where can I find
a good how-to about libbfd ? there is nothing under /usr/share/doc ?
A web page ?

	Thanks.

ps: I don't like any solution based on the dmesg, because by
definition it is volatile (even files under /var/log). For
example a server running since a long time, has always
nfs file handle, or file system full, etc.... so you cannot
be sure that your palo string will be there. So I greatly
prefer a solution based on bfd and look under /boot (or
any other directory found on palo line option)

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] vmlinux header for savecrash.

[Enrik Berkhan]

Bruno,

On Tue, Jan 22, 2002 at 01:25:42PM +0100, Bruno Vidal wrote:
> I think that Enrik has a good starting point, where can I find
> a good how-to about libbfd ? there is nothing under /usr/share/doc ?
> A web page ?

(assuming debian) you can install `bintutils-doc´ and will be
able to do `info bfd´ afterwards. But it´s far from a tutorial ...

Enrik
-- 
Enrik Berkhan                                         plan b. GmbH
                                                      Rüppurrer Straße 4
+49-721-388582 (voice)                                76137 Karlsruhe
+49-721-388581 (fax)                                  Germany

Re: [parisc-linux] vmlinux header for savecrash.

[Matthew Wilcox]

On Tue, Jan 22, 2002 at 01:25:42PM +0100, Bruno Vidal wrote:
> 	Hi
> I think that Enrik has a good starting point, where can I find
> a good how-to about libbfd ? there is nothing under /usr/share/doc ?
> A web page ?

apt-get install binutils-doc
info bfd

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] vmlinux header for savecrash.

[James P. Kinney III]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Tue, 2002-01-22 at 04:20, Bruno Vidal wrote:
> 	Sorry, but on my system, fgrep gives nothing
> (and by using strings, I found nothing also). And I
> can't use dmesg buffer, because by definition it is a buffer,
> so after running sometime, the palo boot strings is not
> in the buffer anymore. Some new ideas ?
> 

I'm not at my PaLinux box, but my intel linux has a dmesg file in
/var/log. I seem to recall that HPUX uses a buffer for dmesg. I'll check
the PaLinux shortly.

-- 
James P. Kinney III   \Changing the mobile computing world/
President and COO      \          one Linux user         /
Local Net Solutions,LLC \           at a time.          /
770-493-8244             \.___________________________./

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney@localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] vmlinux header for savecrash.

[Grant Grundler]

Bruno Vidal wrote:
> 	Sorry, but on my system, fgrep gives nothing
> (and by using strings, I found nothing also).

grundler@gsyprf11:~$ uname -a
Linux gsyprf11.external.hp.com 2.4.17-pa11 #3 SMP Fri Jan 18 23:32:06 PST 2002 parisc64 unknown
grundler@gsyprf11:~$ strings /boot/vmlinux | fgrep 2.4.17
Linux version 2.4.17-pa11 (grundler@gsyprf10) (gcc version 3.0.3) #3 SMP Fri Jan 18 23:32:06 PST 2002
Linux 2.4.17-pa11
2.4.17-pa11
grundler@gsyprf11:~$ 

Perhaps a simple fgrep isn't sufficient for what you have.
You might need to pick out certain fields.

> And I
> can't use dmesg buffer, because by definition it is a buffer,
> so after running sometime, the palo boot strings is not
> in the buffer anymore.

right. They should be in the /var/log/messages if they are no longer
in the dmesg buffer.

> Some new ideas ?

Randolph Chung and I were wondering if dump driver could save a
parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
I haven't checked if something like that already exists.

grant

Re: [parisc-linux] vmlinux header for savecrash.

[Randolph Chung]

> Randolph Chung and I were wondering if dump driver could save a
> parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
> I haven't checked if something like that already exists.

Is this really an arch-dependent problem? How do other architectures (I
think lkcd works on i386 and alpha?) do this?

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] vmlinux header for savecrash.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

lkcd is really simple, it takes /boot/vmlinux, /boot/kerntype, 
and /boot/System.map. It don't take care about that, it is the 
user problem :-(, I want to be a little more user friendly.

Randolph Chung wrote:
> 
> > Randolph Chung and I were wondering if dump driver could save a
> > parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
> > I haven't checked if something like that already exists.
> 
> Is this really an arch-dependent problem? How do other architectures (I
> think lkcd works on i386 and alpha?) do this?
> 
> randolph
> --
>    @..@                                         http://www.TauSq.org/
>   (----)
>  ( >__< )
>  ^^ ~~ ^^

-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] vmlinux header for savecrash.

[Bruno Vidal]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

	Hi
I don't know how to retrieve option pass to the kernel,
but give me some clue, and I'll add this information in
the dump header asap, because it is a really good idea :-)

Grant Grundler wrote:
> 
> Randolph Chung and I were wondering if dump driver could save a
> parameter passed in by palo: eg "boot_kernel=/boot/vmlinux-pa11".
> I haven't checked if something like that already exists.
> 
> grant



-- 
	Vidal Bruno, (770-4271)
        SSD-HA Team, HP-UX & LINUX Support
	bruno_vidal@admin.france.hp.com

[-- Attachment #2: Card for Bruno Vidal --]
[-- Type: text/x-vcard, Size: 386 bytes --]

begin:vcard 
n:Bruno;VIDAL
tel;fax:01-69-82-60-14
tel;work:01-69-29-42-71
x-mozilla-html:TRUE
url:www.france.hp.com
org:Solution Center
version:2.1
email;internet:bruno_vidal@hp.com
title:Expert Logiciel Environnement Haute Disponibilité
adr;quoted-printable:;;HP France=0D=0A;Z.A de Courtaboeuf;1 Av. du Canada;91947 Les Ulis cedex;France
x-mozilla-cpt:;26208
fn:VIDAL Bruno
end:vcard

Re: [parisc-linux] vmlinux header for savecrash.

[Randolph Chung]

In reference to a message from Bruno Vidal, dated Jan 22:
> 	Hi
> I don't know how to retrieve option pass to the kernel,
> but give me some clue, and I'll add this information in
> the dump header asap, because it is a really good idea :-)

static char *boot_kernel = "/boot/vmlinux";
MODULE_PARM(boot_kernel, "s")
MODULE_PARM_DESC(boot_kernel, "Boot kernel path")

then i guess somehwere in your dump code strcpy boot_kernel to a known
location in the dump.

of course we still need to change palo to do this (pass the
parameter)... paul, any comments?

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

Re: [parisc-linux] vmlinux header for savecrash.

[Grant Grundler]

Bruno Vidal wrote:
> 	Hi
> I don't know how to retrieve option pass to the kernel,
> but give me some clue, and I'll add this information in
> the dump header asap, because it is a really good idea :-)

(credit: Randolph brought it up first)

Look at arch/parisc/kernel/setup.c:setup_cmdline().
We can add pretty much anything we need here.

It just occurred to me that the source media (ie network, disk)
needs to be identified as well.
Is the vmlinux/System.map required to be on the root file system?
Would it be reasonble if savecrash told the user that /boot/vmlinux
wasn't the matching kernel and where to put the right vmlinux/System.map?

Allowing users to drop the right kernel in place *after* the
crash dump was recovered seems reasonable thing to do.
Someone might want to move the crash dump to a bigger/faster
system to do the actual analysis.

grant

Re: [parisc-linux] vmlinux header for savecrash.

[James P. Kinney III]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

I think the palo command line is listed in dmesg. That will tell exactly
which kernel was booted.

On Mon, 2002-01-21 at 12:45, Bruno Vidal wrote:
> 	Hi
> As I said few days ago, I've a dump driver ready.
> Now I'm working on a savecrash command. It works fine
> for the dump, but I need to save with the dump some
> informations like the running kernel at dump time.
> So in the dump I've got this informations:
> utsname_release and utsname_version. Now, how can
> I found the right kernel in /boot ? In other
> word, how can I retrieve utsname informations in a
> binary file (without system.map and gdb) ?
> 
> 	Thanks.
> 
> -- 
> 	Vidal Bruno, (770-4271)
>         SSD-HA Team, HP-UX & LINUX Support
> 	bruno_vidal@admin.france.hp.com
-- 
James P. Kinney III   \Changing the mobile computing world/
President and COO      \          one Linux user         /
Local Net Solutions,LLC \           at a time.          /
770-493-8244             \.___________________________./

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney@localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

[parisc-linux] installation problems on an A500

[Matthias Klose]

Trying to install Debian on the machine:

- trying to boot from the network, I get:

Main Menu: Enter command or menu > bo pri
Interact with IPL (Y, N, or Cancel)?> y

Booting... 
Network Station Address 00306e-132574
System IP Address 192.168.42.183
Server IP Address 192.168.42.5

Boot IO Dependent Code (IODC) revision 2

IPL error: bad LIF magic.

************* SYSTEM ALERT **************
SYSTEM NAME: gsphppa
DATE: 01/07/2002 TIME: 02:24:50
ALERT LEVEL: 6 = Boot possible, pending failure - action required

REASON FOR ALERT
SOURCE: 8 = I/O 
SOURCE DETAIL: 6 = disk   SOURCE ID: 0
PROBLEM DETAIL: 0 = no problem detail

LEDs:  RUN      ATTENTION     FAULT     REMOTE     POWER
       FLASH    FLASH         ON        ON         ON
LED State: Boot Failed.  Running non-OS code.  Non-critical error detected.
Check Chassis and Console Logs for error messages.

0x00000060860010C0 00000000 00000000 - type  0 = Data Field Unused
0x58000860860010C0 00006600 07021832 - type 11 = Timestamp 01/07/2002 02:24:50
A: ack read of this entry - X: Disable all future alert messages

the changelog on the bootp/tftpboot server shows:

Jan  7 03:26:00 gate bootpd[25080]: recvd pkt from IP addr 0.0.0.0
Jan  7 03:26:00 gate bootpd[25080]: bootptab mtime: Mon Jan  7 03:25:27 2002
Jan  7 03:26:00 gate bootpd[25080]: reading new "/etc/bootptab"
Jan  7 03:26:00 gate bootpd[25080]: read 2 entries (2 hosts) from "/etc/bootptab"
Jan  7 03:26:00 gate bootpd[25080]: request from Ethernet address 00:30:6E:13:25:74
Jan  7 03:26:00 gate bootpd[25080]: found 192.168.42.183 (hppa)
Jan  7 03:26:00 gate bootpd[25080]: bootfile="/tftpboot/palinux"
Jan  7 03:26:00 gate bootpd[25080]: vendor magic field is 99.130.83.99
Jan  7 03:26:00 gate bootpd[25080]: sending reply (with RFC1048 options)
Jan  7 03:26:00 gate bootpd[25080]: setarp 192.168.42.183 - 00:30:6E:13:25:74
Jan  7 03:26:02 gate in.tftpd[28213]: connect from hppa.local
Jan  7 03:26:02 gate tftpd[28214]: tftpd: trying to get file: /tftpboot/palinux 

Tried this with the lifimage from woody/main (2001-12-19) and the
lifimage from parisc-linux.org (2001-12-26), checked md5sums after
downloading.

Yesterday, I borrowed an external CD-ROM and tried to boot from a
CD-ROM (burnt the ISO image). Now getting:

bo 0/0/2/0.3
Interact with IPL (Y, N, or Cancel)?> y

Booting... 
Failed to initialize.

ENTRY_INIT 
Status = -3

00000000 FFFFFFFD 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000012 00000000 00000000 00000000 00000000 
00000000 454E4841 00000000 00000000 00000000 00000000 00000000 454E4841 
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000400 00000000 00000000 00000000 00000000 00000000 00000000 

Failed to initialize.


Any hints how to start/continue?

Thanks, Matthias

Re: [parisc-linux] installation problems on an A500

[Grant Grundler]

Matthias Klose wrote:
> Main Menu: Enter command or menu > bo pri
> Interact with IPL (Y, N, or Cancel)?> y
> 
> Booting... 
> Network Station Address 00306e-132574
> System IP Address 192.168.42.183
> Server IP Address 192.168.42.5

bootp is working.

> Boot IO Dependent Code (IODC) revision 2
> 
> IPL error: bad LIF magic.

The image bootp got was not a LIF image.

The easiest way to build a bootable LIF image is to
have both linux/ and palo/ source trees from parisc-linux CVS.
(or ftp site). Then "make palo" from linux source tree.
Resulting LIF image is in palo/lifimage.

I don't think we have any lifimages on the ftp site
with recent kernels.

grant

Re: [parisc-linux] vmlinux header for savecrash.

[Paul Bame]

palo removes the "3/vmlinux" parameter (and the initrd= one too) before
passing command line to the kernel which is consistent with x86 I think.
Would it be helpful to add a kernel parameter like "palo_kernel=3/vmlinux"
which you could then retrieve from /proc/cmdline?  I know it's a pain
to turn 3/vmlinux into /boot/vmlinux but 3/vmlinux is all palo knows.

	-P

Re: [parisc-linux] vmlinux header for savecrash.

[Grant Grundler]

Paul Bame wrote:
> 
> palo removes the "3/vmlinux" parameter (and the initrd= one too) before
> passing command line to the kernel which is consistent with x86 I think.
> Would it be helpful to add a kernel parameter like "palo_kernel=3/vmlinux"
> which you could then retrieve from /proc/cmdline?

Sort of. Actually, I was thinking the dump driver could use "palo_kernel"
global to save off the file name of the vmlinux which crashed.
setup_cmdline could parse/squirrel away the palo_kernel parameter.

> I know it's a pain
> to turn 3/vmlinux into /boot/vmlinux but 3/vmlinux is all palo knows.

Isn't /vmlinux a symlink to /boot/vmlinux?
ie the file palo loaded is whatever the symlink points to.

BTW, I explicitly specify /boot/vmlinux in my palo.conf files
and see 3/boot/vmlinux in my palo command line.

thanks,
grant

Re: [parisc-linux] vmlinux header for savecrash.

[Andreas Deresch]

> > I know it's a pain
> > to turn 3/vmlinux into /boot/vmlinux but 3/vmlinux is all palo knows.
>
> Isn't /vmlinux a symlink to /boot/vmlinux?
> ie the file palo loaded is whatever the symlink points to.
Can you guarantee, that everybody will have this link?
(I for example don't right now - I always thought, this is just for
historical reasons)

> BTW, I explicitly specify /boot/vmlinux in my palo.conf files
> and see 3/boot/vmlinux in my palo command line.
Which means, /boot is not a separate partition as some people like to keep
it. So you can't count on that either.

ad

Re: [parisc-linux] vmlinux header for savecrash.

[Grant Grundler]

Andreas Deresch wrote:
> > Isn't /vmlinux a symlink to /boot/vmlinux?
> > ie the file palo loaded is whatever the symlink points to.
> Can you guarantee, that everybody will have this link?

Of course not. I'm refering to a default installation.
I delete that link and replace /etc/palo.conf with my own.
But I'm hardly a "regular" user.

> (I for example don't right now - I always thought, this is just for
> historical reasons)


> > BTW, I explicitly specify /boot/vmlinux in my palo.conf files
> > and see 3/boot/vmlinux in my palo command line.
> Which means, /boot is not a separate partition as some people like to keep
> it. So you can't count on that either.

Right. I like to have lots of room for kernels. :^)
And if one wanted to have / as an ext3, it would make
sense to have /boot as an ext2 for loading kernels and then
the / could be the rest of the disk (ignoring the 2GB
IODC limitation).

grant

Re: [parisc-linux] vmlinux header for savecrash.

[Enrik Berkhan]

On Tue, Jan 22, 2002 at 12:59:03PM -0700, Paul Bame wrote:
> palo removes the "3/vmlinux" parameter (and the initrd= one too) before
> passing command line to the kernel which is consistent with x86 I think.
> Would it be helpful to add a kernel parameter like "palo_kernel=3/vmlinux"
> which you could then retrieve from /proc/cmdline?  I know it's a pain
> to turn 3/vmlinux into /boot/vmlinux but 3/vmlinux is all palo knows.

Hmm, so why don't let palo calculate a CRC32 or MD5 (if affordable)
over the image it is about to boot and pass this as parameter that will
be saved in the dump? This would be very independent of filesystem
changes in the time between boot and crash (e.g. installing a new kernel
moving everything around in /boot). This could also be done for an
initrd image if used. And it still works if you have more than one
kernel image with the same "version" lying around.

Enrik
-- 
Enrik Berkhan                                         plan b. GmbH
                                                      Rüppurrer Straße 4
+49-721-388582 (voice)                                76137 Karlsruhe
+49-721-388581 (fax)                                  Germany

Re: [parisc-linux] vmlinux header for savecrash.

[phi 4369]

> Hmm, so why don't let palo calculate a CRC32 or MD5 (if affordable)
> over the image it is about to boot and pass this as parameter that will
> be saved in the dump? This would be very independent of filesystem
> changes in the time between boot and crash (e.g. installing a new kernel
> moving everything around in /boot). This could also be done for an
> initrd image if used. And it still works if you have more than one
> kernel image with the same "version" lying around.
> 

Having the CRC at dump time doesn't add more than just the utsname (i.e the
uname -a if you wish) as the utsname does have the uniq signature of the os
version PLUS the build time. So it is not possible to have 2 kernel with the
exact same version AND the same build time if they are different, or not only
different but compiled at different time.

The problem afterward at next reboot (while the dump seat in the dump area,
often the swap area) and while sometime rebooting a recovery kernel, i.e not
the one that just dumped, is to run savescrah, and have savecrash placing the
core along with its accompagnying kernel (and the loaded module too, more on
that later).

Finding the kernel who crash assuming a signature, mean then a scan of all the
kernel we could find on the machime, with simple heuristic we could reduce
this to / and /boot, then compare the utsname (version build time) for each.
This is rather brute force and it will be our 1st implementation, until we can
find the boot kernel path probably given by palo as palo is the one that can
get interactivly any kernel path....

Ultimatly if we can't figure out what was the kernel who crashed, we can ask
interactivly :-(

Cheers,
Phi




--
mailto:Philippe_Benard@hp.com
WTEC HP-UX kernel debugging tools