@@ Line 1: / Line 1: @@
-==3feb07==
+#REDIRECT [[User:Tonyr/Journal/Feb07]]
-The flakey G3 B&W tower problem turned out to be a bad system board, solved by replacement.  The bad board went into the cannibalized system, which was tagged and put back on the Mac Pile.  The SCSI G3 B&W tower was bundled with a 17" Apple Studio display, speakers, and an external floppy and sent to the store with a price of $100. As it happened, a customer in the store bought it right away.  I talked a little about pricing earlier ([[#6jan07|6jan07]]).  It seems to me that there is a general price guide shaping up.  I would  suggest that there is a standard base configuration for a slot loader iMac, and a standard base configuration for a tower, each with a standard price.  Then there would be a standard schedule for price variations based on differences in HD type/size, memory size, CD/DVD type, processor speed, and bundle configuration.  We seem to be accumulating 17" (CRT) Apple Studio Displays, which go on ebay for about $20.  Since Ubuntu installation detects monitor type and configures xorg acccordingly,  a question arises what the guidelines should be for monitor configuration during Ubuntu installation on towers.  The information about xorg/monitor assumptions should be published for customers.
-Ubuntu installation in MacRebuild should be via network, as it is in PC build.  That means that the MacBuild area should have network cabling for however many build seats there will be in the new MacRebuild area. The build servers will need to have Ubuntu-ppc support, and the process for ppc netboot will need to be documented. I'm working on that.
-==6feb07==
-''Network install''<br>
-I haven't been able to establish that network install on Ubuntu 7.04 works for powerpc.  That is not to say that it doesn't, I just haven't been able to discover whether 1) it is possible at all, and 2) if it is possible, just how in the heck it is spoze to work.  The 7.04 netboot files fail to do ramdisk (initrd) loading, and I haven't looked at dapper yet (the netboot files appear to be the same set in 6.10dapper an 7.04feisty). Feisty may not be a good example since it is still in alpha.  Using the boot files from the feisty alternate cd as a starting place, configuring a tftp server and using booting an iMac using enet: in OpenFirmware actually gets the install started, but it gets confused when there is no CD in the drive.  The yaboot.conf file has a comment that says something like "This is for CD install only, and should not be used as a general example", so I'm not really surprised that it doesn't work.  There is another approach using package tftfd-hpa instead of tftpd, and having the host be a server for dhcp, tftp and http, and access the alternate cd files via http. Maybe I'll give that a shot.
-''hda/hdc device assignment swap on B&W G3''<br>
-There is a known (in the Ubuntu community) issue about storage devices being discovered in a different order on B&W G3 powermacs.  The main symptom is that the CD-ROM device is assigned as hda, and the hard drive is assigned as hdc.  This is documented at the Ubuntu bug site, Launchpad, as [https://launchpad.net/ubuntu/+source/initrd-tools/+bug/7256 bug number 7256].  The problem is related to the order in which modules are loaded at install time.  The solution is to modify the installed initrd image. I'm not sure that is something that we want to do, since it requires some advanced linux admin/hacking knowledge, is non-standard with respect to build process, and would re-appear if a customer were to try to re-install Ubuntu.   It also seems to affect the ability of OpenFirmware to boot the CD from the keyboard with the C key, although I'm not convinced at this point that this is a related phenomenon.  (There are some comments in related  bugs at Launchpad that indicate that sometimes the USB mouse and keyboard do not appear to be working.) I'm more inclined to reject these from MacBuild.
-==8feb07==
-''hda/hdc device assignment swap on B&W G3''<br>
-There is a second B&W G3 tower now on the bench, that also assigns the CD as hda and the hard drive as hdc, but this one boots the CD just fine.  So what is the CD boot problem with the other one ([[#6feb07|6jan07]])?  Meanwhile the suspect tower is being used as a HD wipe and memory test station.
-''Duplicating Ubuntu/PPC hard drives''<br>
-There was a discussion today (and yesterday) in the Mac corner about duplicating Ubuntu hard drives for the Macs instead of doing a CD based installation every time. Martin and Jeff talked about setting up a network install via DHCP/TFTP.   Dave and Matteo talked about duplicating a standard installation hard drive.  Today Matteo and Loren were working on a manual process for doing that. Here is my take on that process.
-The source hd cannot be the booted drive, because several many files will be open and active.  A rescue CD booted from the CD drive will do.  That way both the source and target hard drives can be passively mounted.
-The source and target drives are almost guaranteed to be different (mfg and/or size), so a straight cloning is out of the question.  That means either creating the partition table manually, or using the  alternate install CD in (in expert mode?) to partition the hard drive.
-The powerpc install process creates four partitions:
-# a partition table partition
-# a boot partition
-# a Linux partition (for the OS)
-# a swap partition
-The size of the partition table and the size of the boot partition are the same no matter what the size
-of the hard drive.  The swap partition size is based on the size of installed memory.  For a standard memory  configuration the size of the swap partition will always be the same.  The size of the linux partition can be calculated as
-* DiskSize - (PartitionTableSize + BootPartitionSize + SwapPartitionSize + 1)
-The extra 1 accounts for the first sector on the drive (block 0) not being used.  It is probably easiest to let the alternate install CD do the partitioning.  If the duplication process is going to be automated, the Linux and Swap partition sizes will need to be calculated.
-Matteo rightly pointed out that if the swap partition were created before the linux native partition, then
-the calculation step would not be needed.
-Manual creation of the partitions can be accomplished with '''fdisk''', which should be available on any rescue CD.  The ppc version of fdisk has specific commands for creating the partition table and boot partition.
-The Linux and Swap partitions are both created as standard linux partitions.
-Once the partitions are created on the target drive, the duplication process is fairly straightforward:
-# create an ext3 filesystem on the Linux partition using '''mke2fs -J'''
-# create a mount directory for the linux partition of target drive in the /mnt directory; a mount directory for the source drive should already exist.
-# mount the source and target linux partitions on the appropriate mount points in /mnt
-# use 'dd' to copy the boot partition directly
-# use rsync to copy the installed linux partition to the target drive linux partition
-There is one possible problem with this duplication process that must be corrected by hand.  On most Macs the hard drive is assigned as device '''hda''' and the CD drive is assigned as '''hdc'''; on some, particularly B&W G3 towers, the assignment is reversed.  This assignment is used in /etc/fstab to define mount points.  The '''fstab''' file on the duplicated hard drive must match the actual device assignments on the machine into which it is placed.  Either different source drives must be created, one for each of the possible device assignment combinations, or a duplicated hard drive may need to have its '''/etc/fstab''' file modified to match the target machine.
-==9feb07==
-Here are the steps we used today to replicate a powerpc linux-installed hard drive to a wiped hard drive in a  G3 B&W tower.  Note that in this exercise, the hard drives are recognized as hdc(master) and hdd(slave).
-# jumper the source drive as master; jumper the target drive as slave.
-# boot from '''finnix''' CD
-# create the partitions on the target disk using '''fdisk /dev/hdd'''
-## '''i''' command to create/initialize that partition map
-## '''C''' command to create a boot partition: start=64, length=1954, type=Apple_Bootstrap, name=untitled
-##* (yes, capital C)
-## '''p''' command to see '''freespace''' (unused disk blocks)
-## '''c''' command to create a linux  partition: start=2018, length=(freespace - 1494848), name=untitled
-## '''c''' command to create a linux swap partition: start=2018+linuxPartitionLength), length=1494848, name=swap
-## '''w''' command to write the partition table to the hard drive
-## '''q''' command to quit '''fdisk'''
-# create an ext3 file system on the linux partition
-#* mkfs.ext3 /dev/hdd3
-# create a mount directory hdd3 in /mnt (directory hdc3 should already exist there)
-#* mkdir /mnt/hdd3
-# mount the source and target linux partitions
-#* mount -t ext3 /dev/hdc3 /mnt/hdc3
-#* mount -t ext3 /dev/hdd3 /mnt/hdd3
-# copy the boot partition using '''dd''' (see [[#10feb07|10feb07]])
-#* dd if=/dev/hdc2 /dev/hdd2
-# copy the linux partition using '''rsync'''; note that the trailing '/' is required for proper results.
-#* rsync -av /mnt/hdc3/ /mnt/hdd3/
-There are some issues concerning the process as described here.
-* The boot partition is copied with '''dd''' instead of '''rsync'''.  I does appear posible to use '''rsync''' if the boot partition is created as an '''hfs''' filesystem.  It is NOT clear at this time that the fdisk command to create the partition provides the file system as well, and the '''hfs''' utilities are not included on the '''finnix''' CD.  We could create a modified '''finnix''' CD with this utilities added, if necessary.  Using '''rsync''' would then require the explicit creation of an '''hfs''' filesystem  on hdd2, the creation of a /mnt/hdd2 directory on which to mount the partition, anth rsync step to copy /mnt/hdc2 to /mnt/hdd2. (see [[#10feb07|10feb07]])
-* The replicated drive boots, but in a strange way.  It seems to not find the boot file at first, showing the folder-with-questionmark icon for a few seconds before booting the yaboot image.  I'm not sure why that is.  OpenFirmware has an environment variable '''boot-device''' whose value is a space separated list of boot file candidates.  The default value uses an '''hfs''' file type specifier, '''\\:tbxi'''.  I think the file type is in the files resource fork, which makes me think that the resource fork exists in the partition created by the Ubuntu installation process, but not in the copy created with '''rsync'''.  I could be wrong.   I tried several things when the folder-with-questionmark first appeared,
-*I rebooted into OpenFirmware and selected the bootfile explicitly as with '''boot hd:2,\\yaboot''', meaning boot using the file named yaboot on the second partition of the default hard drive.  That worked right away. **I added that boot file specifier to the '''boot-device''' environment variable.  That seemed to work, too.  That made me start to think that maybe the first time I saw the boot failure, it really was a boot failure.  The added boot specifier was in the second position in the list, and the boot failure icon behavior is consistent with trying the first boot specifier and failing before the second specifier is used.  This needs to be tried with the new boot file specifier in the first position.
-* If the resource fork files are actually in the boot partition,  then the '''dd''' method of copying the partition should get them.  I tried that, too, and the boot failure icon still appeared, but the boot eventually succeeded, as before.  This also could be tested with the file order modification in the environment variable. (see [[#10feb07|10feb07]])
-* The calculation of the linux partition size could be avoided if the order of the partitions is changed by swapping the linux partition and the swap partition.  The numbers needed for partition start can be read right off the partition creation information.  This invalidates the information in the '''yaboot.conf''' file in the boot partition, which has partition information created by the Ubuntu installation process.  Swapping the partition order means that the linux boot images wiil be on partition 4 (hdd4), but the '''yaboot.conf''' file says that they are in partition 3 (hdd3), so the boot would fail.  It is possible to edit the file and make the appropriate changes.  So the question is which is a '''better''' solution, calculating the partition start and length numbers, or editting the '''yaboot.conf''' file.  In addition, the file '''/etgc/fstab''' is created believing that the root device is partition 3.  It would need to be edited also to reflect the new partitions.
-* Some Mac computers, as mentioned earlier, designate the hard drive as hda and the CD rom as hdb.  The towers that we are using to develop this process designate the CD as hda and the first hard drive as hdc.
-This means that either there will need to be separate master hard drives for each device configuration, or the '''fstab''' file will need to be edited to reflect the partition changes.
-''Afterthoughts''<br>
-If the order of the devices in linux is determined by driver loading order at boot time, then the order (hda vs hdc) assigned by '''finnix''' may be different from the order assigned by Ubuntu.  This needs to be checked and verified as so or not-so.
-Michael (tech support) told us a couple of days ago that he wasn't prepared to support Macs, let alone Macs with Rdgy installed, and asked if he could route technical support questions to us.  That's fine.  Maybe we chould give him a Mac with edgy installed for the tech support area.  I sent a note to the reuse mailing list to that effect.
-==10feb07==
-''HD replication''<br>
-Replicating the boot partition apparently requires the '''dd''' method.  I tried it both ways ('''rsync''' and '''dd'''), and only the '''dd''' method made the boot work correctly.
-Creating a boot partition with type Apple_Bootstrap apparently DOES create the '''hfs''' filesystem on the partition.  I verified it by creating a boot partition on a wiped drive and mounting the boot partition with type '''hfs'''.  It makes no difference to the process, however, since the resource fork issue requires the use of '''dd''' to copy the partition anyway.
-I can write a script that generates the lengths of the '''start''' and '''length''' values of the linux and swap partitions and puts them in a script that can be fed to fdisk.  Here is, generally, is what such an fdisk script would look like, without the comments:
- i                # initialize the partition map
-                  # blank response to init disk size query
- p                # print empty partition table
- C                # (capital C) create a (boot) partition using types
-               # start block
-             # length
- untitled         # name
- Apple_Bootstrap  # boot partition type
- p                # print modified partition table
- c                # create normal (linux native) partition
- <number>         # start block
- <number>         # partition length
- untitled         # name
- p                # print modified partition table
- c                # create swap partition
- <number>         # start block
- <number>         # length
- swap             # name
- p                # print final partition table
- w                # write partition map to disk
- y                # confirm write to disk
- q                # quit
-The <number> things will be calculated based on the disk size and put in the shell script that generates the fdisk script.
-'''PROBLEM''': Ubuntu is mounting by UUID in '''/etc/fstab''' these days.  The UUID of the replicated drive will not match the UUID in '''/etc/fstab''' after replication.  So '''fstab''' will have to be modified by the replication process to use the new UUID for the root and swap partitions.
-The UUIDs are found in directory '''/dev/disk/by-uuid''' as links to the referenced partition.
-''Other stuff''<br>
-We had a first inquiry today about helping with Mac rebuild from Gary with son Michael.  I asked him to talk to Dave or Matteo.
-==12feb07==
-''smartmon''<br>
-Dave suggested looking into a utility called '''smartmon''' to reduce the time required for wiping hard drives and forcing reallocation of bad sectors.  The Ubuntu package is actually '''smartmontools''', its homepage is [http://smartmontools.sourceforge.net smartmontools.sourceforge.net], and a writeup about using it to deal with bad blocks can be found [http://smartmontools.sourceforge.net/badblockhowto.html here].  The package is not normally installed with Ubuntu (I didn't see it in my Edgy installation).  I haven't looked at the LiveCDs yet (x86 or powerpc), but it is on the '''finnix''' powerpc rescue CD that I have been using.  A dedicated station with an Ubuntu installation would need to have the '''smartmontools''' package installed.
-==13feb07==
-Today I asked the question "What is the wipe and test process for hard drives?", trying to find out what I should be looking at for doing wipe/test in on the Mac side.  It should be noted that there is a side goal of trying to reduce hard drive wipe and test time in general.  My starting point was my infant process of using '''smartctl -t <test>''' to identify bad blocks, and then using '''dd''' to write zeros to the entire hard drive.
-One person answered that '''badblocks''' was the current solution.  One person thought writing zeros and then ones to the whole drive would be sufficient to wipe the drive.  I explained to Martin what I was doing, and he asked if '''smartctl''' was doing a destructive test (write-then-read).
-From what I understand about '''smartctl''', there is no mode in which it does a destructive test.  Its purpose seems to be to monitor read failures on a drive, with the goal of predicting disk failure.  The idea is that once blocks start to go bad, other block failures will surely follow as the night follows the day (or ''vice versa'' if you prefer).  There is a suggested method for reallocating blocks to replace the failing blocks, but only as a stop-gap while the failing disk is backed up and a replacement can be installed.
-I found out some other things.  The in-place wipe/test policy is that the discovery of ANY bad blocks on a hard drive requires that the drive be rejected.  All that '''smartctl''' can do is report that there were bad blocks found.  My reading of the '''smartmontools''' documentation leads me to believe that a '''smartctl extended self-test''' is required to exhaustively search for a read failure on the drive. Such a test could take an hour or more.  The information I don't have is what the disk-size vs time graph looks like for '''badblocks'''. Writing zeros to a 20GB hard drive took about 20 minutes on a 350MHz G3 PowerMac.  Twp passes would take about forty minutes. Four passes would take about 1hr 20min.  If I took a wild guess and said that a '''smartctl/raw-write''' solution takes 2hr 20min and a '''badblocks''' solution takes three hours, the savings is not enough to warrant the change in methods.  I'd have to see what happens for larger drives.
-I noticed that the numbers for the partition block lengths didn't add up to the total block size of the hard drive in my partitioning process.  My assumption that the block numbering started at 1 (start of partition map) is wrong: numbering starts at zero.  I'll go back and modify the description of the arithmetic. (Done 14feb07)
-==15feb07==
-''Auto-restart problem''<br>
-Loren marked one of the iMacs in the warehouse as automatically restarting after shutdown.  I googled for references to this problem, and found a couple. This [http://docs.info.apple.com/article.html?artnum=58171 Apple Developer Article] acknowledges the problem and indicates that USB devices may be involved.  The writer of this [http://www.macworld.com/forums/ubbthreads/showthreaded.php?Number=217805 MacWorld Forum thread] found that the USB keyboard/mouse combo appeared to be the cause of his problem.  This suggests a line if investigation:
-* try hard powerdown with just the power button (power button may be stuck/defective)
-* try unplugging the keyboard right after software shutdown
-* try mouse and keyboard on separate USB ports, and try other keyboard/mouse with this arrangement
-* replace USB controller on the system board (I'm not certain that his is possible on an iMac), or...
-* replace the system board
-''Mac build scripts''<br>
-I created a [[Mac Build Scripts]] page to hold the Mac disk replication scripts I am working on.  I guess any other scripts related to Mac Rebuild will get put here, too.
-==16feb07==
-Rejected one G3/333MHz Powerbook with a bad keyboard.  Started eval on a G4/800MHz Powerbook Titanium. Specs I have seen indicate that there should be an Airport card in it, but I haven't verified that yet. The owner could have removed it. There is a disassembly/fixit guide [http://www.ifixit.com/Guide/33.0.0.html here].
-Pricing research for the G4 Powerbook at ebay:
- CPU     MEM     HD	DPY	RMV		$		date
-MHz 	256M	10GB	15	DVD/CDRW	530+29(559)	15feb07
-MHz 	256M	30GB	15	DVD/CDRW	500+33(533)	16feb07
-MHz 	640M	40GB	15	DVD/CDRW	545+37(581)	16feb07 refurb
-MHz 	256M	40GB	15	DVD/CDRW	550+30(580)	14feb07
-MHz 	256M	40GB	15	DVD/CDRW	439+29(469)	14feb07 refurb
-MHz 	256M	40GB	15	DVD/CDRW	478+96(574)	14feb07
-MHz 	256M	20GB	15	DVD/CDRW	625+29(654)	13feb07
-MHz 	256M	30GB	15	DVD/CDRW	480+35(515)	14feb07
-MHz 	384M	20GB	15	DVD/CDRW	450+28(478)	13feb07
-MHz	512M	60GB	15	DVD/CDRW	775+30(805)	13feb07
-MHz	512M	60GB	15	DVD/CDRW	630+29(659)	13feb07
-MHz 	512M	80GB	15	DVD/CDRW	450+25(475)	12feb07
-MHz 	256M	40GB	15	DVD/CDRW	499+29(528)	11feb07
-MHz	512M	60GB	15	DVD/CDRW	658+95(743)	11feb07
-MHz 	512M	80GB	15	DVD/CDRW	421+15(436)	11feb07 problems
-MHz 	384M	10GB	15	DVD/CDRW	580+30(610)	11feb07
-MHz 	256M	40GB	15	DVD/CDRW	439+29(469)	11feb07 refurb, no wifi
-MHz 	1000M	20GB	15	DVD/CDRW	710+17(727)	14feb07
-MHz 	1000M	80GB	15	DVD/CDRW	649+35(684)	09feb07
-MHz 	256M	40GB	15	DVD/CDRW	490+40(530)	09feb07 no wifi
-An Airport card (original, not Extreme) at ebay has a price range of about $50-$80.
-''Memory Testing''<br>
-There is a '''memtest''' program for PPC machines, and it is included on the '''finnix''' CD.  It does not test all of installed memory, however, and I haven't figured out exactly what's going on there.  It runs in a booted system ( I haven't seen a boot standalone version yet), so it obviously doesn't do the 'copy myself around so that I can test the whole physical memory space' thing.  It offers options to select memory ranges, so one strategy would be to leave a tested memory stick in a test system all the time, and add sticks to be tested in slots that represent physicla memory addresses that are available for testing.  I assume that this is possible to do since I see the memory-stick/address assignments in the /memory device reported by OpenFirmware.  I also assume that a faster processor will test memory faster, so a higher end machine would be a good candidate for testing.
-Needless to say, this is partially a moot point because standard PC-100 and PC-133 is used in most of the Macs we are working with, and is tested in Advanced testing already.
-==17feb07==
-''G4 Powerbook''<br>
-The airport card is there.  The memory is 512MB (2x256 SODIMM PC-133).  I tried to run '''memtest''' in place from '''finnix'''.  The test got through step 11 and seemed to hang at step 12.  On reboot the video was hosed. It is possible that '''memtest''' wrote  to places it shouldn't have.  It is also possible that overheating caused problems (the machine had been on for ~24 hours.  I repeated Jeff's exercise, which was to reseat the display connector, and I reseated the memory, too.  After that the video problem went away...'''finnix''' booted, and the alternate Ubuntu install CD booted.  This sounds like a repetition of the sequence of events that brought the laptop top to FreeGeek in the first place.  On the other hand, the alternate install process completed successfully without interruption.
-The memory still needs a complete '''memtest'''.  Jeff suggested that laptops (black hole) might be able to provide an x86 unit for testing SODIMMs with a bootable '''memtest86''' image.  The battery needs a time eval.
-The current build sheet calls for a PRAM battery check.  Getting at the PRAM battery is not difficult, but neither is it trivial.  It requires removing the  DVD drive, a few small pieces and the tape holding in the battery.  There is a step-by-step guide [http://www.newertech.com/tech_support/images/NWTMANTIPRAM.pdf here]
-''Network Install'' (see [[#6feb07|6feb07]])<br>
-The newest '''finnix''' release, 89.0, is reported to have a netboot feature.  I haven't played with that yet. It's still an option I guess, but the HD replication approach is probably better.  I think I mentioned this before:  There should be a separate HD for each possible basic arrangement of device assignments.  It is also possible, but a little riskier, to modify the relevant files. I know about '''fstab''' and '''yaboot.conf'''.  Are there others?
-==19feb07==
-Thinking about a dedicated machine for Ubuntu ppc disk replication.
-* It must support at least two IDE drives.
-* It should support at least one SCSI drive.
-* A copy of the entire linux installation can reside on the boot drive, in a directory and/or in its own partition.
-* The boot drive should have a separate partition with an image of a generic boot partition
-Putting the linux installation image in its own partition offers the opportunity to offer it as a boot alternative.  That would in turn allow the image to be updated regularly from the network, reducing the update time associated with the Mac Build process.
-A generic boot partition would preserve the original boot partition contents.  The real boot partition on the boot drive will have specialized content if there is more than one boot image. I'm not sure that is so important, since the only file in the boot partition that would change is '''yaboot.conf''', and that will most likely need to be changed anyway.
-It would still be necessary to maintain unique versions of '''yaboot.conf''' for machines with different '''hda/hdb/hdc''' assignments.  Note that the ppc-linux command '''mkofboot''' will
-''do the right thing'' to create a boot partition on a target drive.  I will need to experiment with this some to verify that it does, indeed, ''do the right thing''.
-'''/etc/fstab''' modifications are:
-* substitute the correct UUIDs for the linux and swap partitions.  A partition UUID can be discovered with '''tune2fs -l <partition-spec> | grep -i uuid"
-* substitute the correct device for the cdrom, if there is one.
-Here's a couple of trailing thoughts.  Most of the Macs we've been working on have ATI video controllers.  Some of the newer ones have nVidia controllers.  The '''/etc/X11/xorg.conf''' file would need to be modified accordingly, or such machines would need to have a regular alternate-CD-install applied.  There are also SCSI based systems.  We built one a couple of weeks ago that had two SCSI drives in it.  That kind of configuration might need a custom install, also.
-==20feb07==
-''G4 Powerbook''<br>
-It has a loose-connection/power problem at least.  The power connector changes from green to amber just by applying pressureto the case above the connection point, or sometimes just goes out if the wire is wiggled.  The battery may be bad, too.  The power connector turned green after about an hour of charging , indicating a full charge, but on power-up the battery reported a power level of 3%, and the box immediately went to sleep.  After two more hours of charging the same thing happened.
-The display occasionally has  what looks to be a sync failure, with ghost images and wrapped scan lines.  Maybe this guy was dropped at some point and there were connection/cable ramifications.
-The Powerbook goes to the lockup at night and overweekends (or when nobody is in the Mac Build area for an extended period).
-''New G4 tower''<br>
-MHz, 20G HD + 80G HD, 1GB Ram (51+2*256+128+128), AGP video, PCI video, (yeah, two of 'em), SCSI controller. The AGP video card seems to be dead, no initial signal to the monitor.   The PCI video card is alive and works.   Through some sequence of events and reasoning that I cannot now completely recall, I connected a hard drive out of an iMac (where HD is device hda and CD is device hdc) to the ide0 cable.  This is actually part of an exercise to figure out what needs to be done to a replicated ppc/linux drive when installing it in another machine.  This configuration did not get past stage1 boot at power up.  Booting into OF ('''Cmd+Option+O+F'''), however,  allowed a direct boot command ('''boot hd:,\\yaboot''') to succeed.  Direct modification of '''yaboot.conf''' in the boot partition (hda2) did not affect the power-up boot failure, but the recommended procedure (modify '''/etc/yaboot.conf''' and run '''ybin''') did
-fix the boot problem.  The modification was to the '''device''' parameter assignment.  In short, the value of that parameter has to match the machine that the hard drive is installed in.
-While the power-up boot worked and got to the login screen,  the actual login failed to start the the X system (xserver and gnome).  I tried reconfiguring the xserver, with the command  '''dpkg-reconfigure xserver-xorg''', but that didn't work either.  Part of that problem was that the '''xserver-xorg''' package was reportedly not completely installed.  It turned out that a lot of things were not completely installed, as the command '''dpkg --configure -a''' showed.  This leads me to believe that the hard drive I used may not have had as complete an installation as I had assumed.  Reconfiguring '''xserver-xorg''' again didn't fix this problem, and the Xorg log ('''/var/log/Xorg.0.log''') reported that it couldn't find a screen.  I assumed that it needed a '''BusID''' added to the video device description in '''/etc/X11/xorg.conf''', but no bus-id value I tried solved that problem.  The reconfiguration process wanted to use '''PCI:17:4:0''', which was correct as far as I could tell, but that didn't work, either.  The only thing that did work was to use an AGP card that did work, borrowed from another machine,
-and reconfiguring again.  The problem with that solution is that the AGP video card has two non-standard video connectors, a DVI and an ADC, and the monitors we have do not use either of those connectors.  I had to use the only DVIto15pin adaptor that we have to get the monitor to work.  I couldn't find another AGP video card with a 15pin connector that worked.
-There may be something that can be done in OF about the PCI bus-id for the pci video card, but I don't know what.
-I'm not sure what else to do with it at this point.  I guess I need to verify that the other AGP cards that didn't seem to work really don't work.  If they DO actually work in another machine, then things only get more confusing.
-==22feb07==

Difference between revisions of "TonysMacJournal Feb07"

Latest revision as of 21:44, 23 March 2007

Navigation menu

Search