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

Bug#247095: marked as done ([powerpc] [beta4] [businesscard] qualified success on iBook G4)

Your message dated Sun, 20 Mar 2011 17:56:56 +0100
with message-id <20110320165656.GY7161@const.famille.thibault.fr>
and subject line Re: Bug#273192: swapped colors with 2.6 kernel
has caused the Debian Bug report #273192,
regarding [powerpc] [beta4] [businesscard] qualified success on iBook G4
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

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

Debian-installer-version: beta 4
uname -a: Linux turnip 2.4.25-powerpc #1 mer avr 14 15:38:38 CEST 2004 ppc GNU/Linux
Date: 1 May 2004
Method: businesscard CD, packages downloaded from FTP mirror

Machine: Apple iBook G4 12"
Processor: 1GHz G4
Memory: 256MB
Root Device: 40G IDE disk
Root Size/partition table: 12G ext3 root partition
Output of lspci:

0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP
0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV250 5c63 [Radeon Mobility 9200 M9+] (rev 01)
0000:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI
0000:10:12.0 Network controller: Broadcom Corporation BCM94306 802.11g (rev 03)
0000:10:17.0 Class ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O
0000:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0000:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0000:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0000:10:1b.0 USB Controller: NEC Corporation USB (rev 43)
0000:10:1b.1 USB Controller: NEC Corporation USB (rev 43)
0000:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
0000:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI
0000:20:0d.0 Class ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100
0000:20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire (rev 81)
0000:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80)

Base System Installation Checklist:

Initial boot worked:    [O]
Configure network HW:   [O]
Config network:         [O]
Detect CD:              [O]
Load installer modules: [O]
Detect hard drives:     [O]
Partition hard drives:  [E]
Create file systems:    [O]
Mount partitions:       [O]
Install base system:    [O]
Install boot loader:    [E]
Reboot:                 [O]
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it


I had to use the 'install-safe' boot option, otherwise the display
didn't work.

When choosing a mirror to download from, I found I had to back out of
the country list before I could choose to use FTP.  I guess this isn't
a problem if you choose a mirror from the list, or (I assume) the 
mirror name begins with 'ftp', but neither of those is true for me.

I chose manual partitioning in order to leave some space for a certain
proprietary operating system.  Partitioning itself worked well, but
when exiting the partitioner, it refused to believe that I'd created
the bootstrap partition.  I messed around with the size a bit, but it 
didn't help. I tried creating the bootstrap partition using mac-fdisk, 
and that didn't work either.  I eventually ignored the warning and 
carried on.  The message I was getting here was 
partman-newworld/no_newworld, not partman-newworld/wrong_size.

I don't know if it's possible to do this check inside the partition 
editor, so you don't need to write the partition table to disk before 
you find out you've got to go back and fix it, but that'd be nice.

When installing the boot loader, the same message appeared.  I started
a shell, chrooted into /target, mounted /proc, ran ybin, and it worked.

Those things aside, everything worked fine.  

In the two installs I've done using d-i now (this one and an earlier
i386 install I don't seem to have bothered reporting on), what's
impressed me most hasn't been how simple it is, but rather how, when
it does break, I can bash it until it works.

--- End Message ---
--- Begin Message ---
We haven't had more reports recently (and some people have reported
it as fixed). I believe this bug has somehow been fixed in the kernel


--- End Message ---

Reply to: