[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#260433: marked as done (Power4 fails to boot install kernel)



Your message dated Wed, 08 Sep 2010 03:58:41 +0000
with message-id <E1OtBo1-00067h-DU@ravel.debian.org>
and subject line Closing old installation report #260433
has caused the Debian Bug report #260433,
regarding Power4 fails to boot install kernel
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
260433: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=260433
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports
Version: sarge-netinstall powerpc 20040718

architecture:  powerpc 
model:         JS20 Blade
memory:        2 Gig
scsi:          none
cd-rom:        USB over ISD200
network card:  broadcom 5704
pcmcia:        none

I tried using the sarge netinstall for powerpc on a Power 4 box and ran
into a number of problems.  If you want me to break these into separate
bug reports, I can.  It's just a hassle.

- yaboot.conf is not located at /etc/yaboot.conf.  If you are booting a
chrp box, yaboot expects yaboot.conf to be at /etc/yaboot.conf.  I got
around this problem by doing a hardlink.

- The device in yaboot.conf is set to 'cd' and newer versions of
firmware for ppc64 RS6000 have the name 'cdrom', thus it couldn't find
any of the kernels or boot.msg files on the disc image.

- The power4 kernels will cause a default catch in open firmware when
booted.  I'm not sure exactly how the power4 kernels are being built,
but every ppc64 box I tried they failed to boot.

I also looked at the compressed kernels w/ the initrd attached without
luck.  When I did a hexdump on them, the headers looked much different
from a kernel image that I got booting w/ the debian intaller attached.


Here is a non-bootable image that is currently being built:

	# objdump -h vmlinuz-chrp.initrd
 
	vmlinuz-chrp.initrd:     file format elf32-big
 
	Sections:
	Idx Name          Size      VMA       LMA       File off  Algn
	  0 .text         00005a0c  00800000  00800000  00010000  2**2
	                  CONTENTS, ALLOC, LOAD, READONLY, CODE
	  1 .data         00463000  00806000  00806000  00016000  2**2
	                  CONTENTS, ALLOC, LOAD, DATA
	  2 .bss          000215e0  00c69000  00c69000  00479000  2**2
	                  ALLOC
	  3 .note.GNU-stack 00000000  00000000  00000000  00479000  2**0
	                  CONTENTS, READONLY


Here is a version I built that works:

	# objdump -h debian-install-2.6.5
 
	debian-install-2.6.5:     file format elf32-big
	 
	Sections:
	Idx Name          Size      VMA       LMA       File off  Algn
	  0 .text         00004dc4  00400000  00400000  00010000  2**2
	                  CONTENTS, ALLOC, LOAD, READONLY, CODE
	  1 .rodata       000006c8  00405000  00405000  00015000  2**2
	                  CONTENTS, ALLOC, LOAD, READONLY, DATA
	  2 .data         000003e0  00406000  00406000  00016000  2**2
	                  CONTENTS, ALLOC, LOAD, DATA
	  3 .kernel:vmlinux 002d32b8  00407000  00407000  00017000  2**0
	                  CONTENTS, ALLOC, LOAD, READONLY, DATA
	  4 .kernel:.config 00001d31  006db000  006db000  002eb000  2**0
	                  CONTENTS, ALLOC, LOAD, READONLY, DATA
	  5 .kernel:System.map 0005e5b4  006dd000  006dd000  002ed000  2**0
	                  CONTENTS, ALLOC, LOAD, READONLY, DATA
	  6 .kernel:initrd 00337feb  0073c000  0073c000  0034c000  2**0
	                  CONTENTS, ALLOC, LOAD, READONLY, DATA
	  7 .bss          000215d8  00a74000  00a74000  00684000  2**2
	                  ALLOC
	  8 .comment      00000090  00000000  00000000  00684000  2**0
	                  CONTENTS, READONLY




--- End Message ---
--- Begin Message ---
We are closing this installation report for one of the following
reasons:
- it was reported with a pre-lenny version of Debian
  Installer.
- indications in the installation report give the feeling that
  the reported problem waslying in another software, unrelated to
  D-I, which we can't easily identify.
- indications in the installation report suggest that it may have been
  fixed in a more recent version of a D-I component
- it was successful and we forgot closing it..:-)
- it has no information we consider useful


The D-I team is currently in the process of cleaning out the old spool
of installation reports that haven't bene processed yet. 

In case you think that the problem you reported has chances to be
still present, please reiterate your installation test with
a more recent image of D-I, if you're in position of doing this.

You'll find daily builds at
http://www.debian.org/devel/debian-installer. We recommend you choose
the netboot image, in the "daily builds section", then choose to
install "squeeze" when prompted.

If some problems are found, please report them with a new bug sent
against installation-reports.

Many thanks for your understanding and your help improving Debian,
past and present.



--- End Message ---

Reply to: