Difference between revisions of "Tonys Mac Journal"

From FreekiWiki
Jump to navigation Jump to search
(→‎9feb07: more afterthought)
(redirect)
 
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
==4jan07==
+
#REDIRECT [[User:Tonyr/Journal]]
I'm going to try to record my experience working with the Macs at FreeGeek.  This will be mostly subjective
 
train of thought, first impressions,  immediate reactions, that sort of thing.  This first few entries will be
 
a recap of the things I can remember from that past couple of weeks.
 
 
 
''Audio Skipping''<br>
 
iMacs/PowerMacs with CPU speeds less that 450MHz seem to have problems playing CDs using '''SoundJuicer''' and '''RythmBox''', the CD ripper and CD player installed with Ubuntu.  Playback audio will 'skip', producing gaps of a few seconds, and may even cease altogether.  Loren has been able to solve this by replacing CD drives in slot loading iMacs and PowerMac Towers.  I have solved it by installing '''gxine''' and manipulating its configuration parameters, specifically the increasing the number of buffer blocks and increasing the value of media.audio_cd.drive_slowdown in the xine configuration.  The xine configuration file usually shows up in the users home directory as .xine/xine_config.  '''gxine''' provides access to most of the configuration parameters through Preferences in its menu.  There are several levels of parameter control in Preferences.  The level named '''Master of the Universe''' allows a the most access.  I have been increasing the slowdown parameter from 4 to 12, and increasing the number of buffer blocks from 230 to 500.  Both of those were guesses on my part.  Increasing the number of buffer blocks may not be necessary.
 
 
 
I don't know exactly why either of the solutions works. Some of the CD drives Loren has been using as replacements are much newer drives, and probably offer better performance features.  The fact that there appears to be a configuration solution makes me think that the existing CD drives are not bad, but have lower performance that needs help in software.  There are several different models of CD drive use in the iMacs
 
 
 
There are several problems with the '''gxine''' solution with the lower CPU speed Macs (233-400MHz).  '''gxine''' has a visualization feature that competes with audio for CPU cycles.  Turning the visualization off reduces
 
or eliminates the 'skip' problem.  Visualzation control is under the '''View''' drop down menu, but changes there do not persist across '''gxine''' restarts.  I haven't found a way to make the visualization change permanent.
 
 
 
 
 
==5jan07==
 
''iMac G4/700 Flat Panel''
 
It's that half-basketball-long-neck thing with the flat-panel display on the top of the neck.  It came in on 29Dec06.  70MHz PPC, 40G hard drive, 256 MB, DVD/CD.  Runs Mac OS X just fine, but refused to
 
boot the Ubuntu 6.10 installation CD.  Yesterday and today Loren swapped out the hard drive for a wiped drive from the store.  He also (miraculously) found a 256MB SODIMM to upgrade it's memory, with the
 
goal of creating a very nice high end PPC machine.
 
 
 
It turns out this is a very weird machine, even for an iMac.  The system memory is a SDRAM DIMM (regular PC memory). The expansion memory is SODIMM (laptop style). The expansion memory and wireless network card (airport) are underneath the bottom cover plate, which is easily removed.  The drives and system memory are underneath a second bottom plate below the first one, and is much harder to remove and requires application of thermal paste to a thermal transfer plate when re-attaching it. The graphics controller is an nVidia GeForce 2 400 MX, which the Ubuntu PPC install CD apparently doesn't know how to deal with. The CD  starts to boot normally, gets to the part that says '''loading ramdisk''' and then hangs indefinitely. 
 
 
 
This version of the iMac was not in production very long.  I'm thinking we won't see very many of them, and should probably not spend a lot of resource trying to solve this.  It's more of a 'special project'.  There may be a way to solve it, but it might involve detailed knowledge of the Ubuntu PPC boot process and maybe even some knowledge about how to manipulate OpenFirmware.
 
 
 
As is mentioned below in ''Deviant ATI video controller'', there are some G4 Towers that also use nVidia controllers.  It will be interesting to see how Ubuntu installation goes on those machines, should we ever get any.
 
 
 
 
 
''The Cube''<br>
 
The pre-cursor to the Mac Mini.  The monitor is separate, and the video connector on the Cube is a special Apple type called [[Wikipedia:Apple_Display_Connector|ADC]] that combines USB, power and          [[Wikipedia:DVI|DVI]].  There are three Cubes in limbo in the Mac triage area.  The newest arrived yesterday, and came with an almost complete package: the Cube, Apple Studio Display 15in (LCD/ADC), power adapter, speakers, keyboard, ADC to VGA adapter (no mouse).  I found a few similar packages on '''ebay''' for $400-$500.  The speakers are USB.  There is no hardware audio controller.  I'm not certain that there is an internal speaker.  I never heard a power-on chime.  The standard Ubuntu installation sure would like to see some audio hardware.  There is support for USB audio in Linux, but taking advantage of it does not seem to be straightforward.  A ''Google'' search turned up one article that suggested installing '''xmms''' and using its ''Preferences'' to select the USB speakers.  I did that, but the speakers still didn't work.  USB audio can probably be made to work, but I think it is another 'special project'
 
 
 
 
 
''Macs That Resist Ubuntu Installation''<br>
 
The ''G4/700 iMac'' and ''The Cube'' raise the question of what to do with nice iMac systems that require undiscovered contortions to get Ubuntu to install with incomplete functionality, or not at all.  The two obvious  suggestions are 1) let MacRenewal have then, and 2) sell them in the store at a discount with labelling that indicates no OS or missing functionality.  A third possibility is to keep them in limbo in hopes (that Saint Nicholas soon would appear, but I digress) that there migh be resource at some point to explore for solutions.
 
 
 
 
 
''Deviant ATI video controller''<br>
 
Almost all of the iMac machines use ATI controllers. The half-basketball machine mentioned earlier and some higher end G4 PowerMac Towers use nVidia controllers.  Other High end G4 Towers use Radeon controllers (which are also ATI, I believe).  The older iMacs use ATI Rage controllers.  There are many, many variations of the ATI Rage contoller.  The list can be found in the log file produced when the Ubuntu desktop start up, '''/var/log/Xorg.0.log'''.  All of the iMacs I have worked on so far have installed Ubuntu with working video, with the exception of the one I worked on today.  This was a 500MHZ 'bubble' iMac.  The video controller was an '''ATI Rage 128 Pro Ultra TR'''.  After installation, Ubuntu was extremely sluggish, and any event (mouse, keyboard) that required video reaction would produce a hang of many seconds, on the order of 30-60.  The best way I could find to solve this problem was to remove the '''glx''' module from the xorg startup configuration.  I did it by running '''dpkg-reconfigure xserver-xorg''' and unchecking the '''glx''' module when it asked which modules to include.  Removing
 
the '''glx''' module takes away the high performance features of the controller, but does allow reasonable behavior under normal circumstances.
 
 
 
Moral:  Watch out for the '''ATI Rage 128 Pro Ultra''' video controller!
 
 
 
 
 
 
 
==6jan07==
 
I'm still thinking about the Triage/Eval/Rebuild flow.  I decided to write down a step-by-step
 
of what I do at that Mac rebuild bench.  It still doesn't cover everything, and a lot of detail
 
is missing, but it's not bad.  I will probably incorporate it into the diagrams somehow.
 
 
 
''What do I really do with Macs right now?''<br> 
 
The definitions of triage and build are different
 
for Macs.  Triage is mainly separation of received Apple equipment into
 
FreeGeek stuff, MacRenewal stuff, and FreeGeek recycle stuff.  Mac Rebuild
 
is really a combination of Eval and Build, with the result being either
 
resale-system or mine-and-recycle.
 
 
 
#Examine the case for damage
 
#*major case damage is a straight mining/recycle sign.
 
#Open it up, examine logic board for damage, blown caps. 
 
#*Damage might be fixed by replacement, but may also indicate mining/recycle.
 
#Remove HD and memory, send them to eval for collection/testing.
 
#Remove and test the battery.
 
#Replace memory, HD, and battery if necessary. 
 
#*If replacing battery, reset PMU.  Memory should be 256MB, HD should be 10-15GB. If 256MB is not available, consider 192MB and Xubuntu installation.  If 192MB is not available, don't install anything, wait for memory (or else deconstruct and return to MacRenewal Pile?)
 
#Close it up.
 
#Connect power, kbd and mouse.
 
#Power it up, boot to OpenFirmware ('''Command+Option+O+F''').
 
#*If OpenFirmware is not reachable, remove power, open up the box, remove battery, leave it for 15min to half-hour. Press PMU for 5sec, press power for 5sec, replace battery, close it up, power-up with PRAM reset '''Command+Option+P+R''', wait three chimes).  Let boot proceed as far as it will. Power down, try OpenFirmware again. Record OpenFirmware version.
 
#Insert Finnix CD, note if insert mechanics seem sluggish. Boot Finnix CD from OF with 'boot cd:,\\yaboot', or power-cycle and boot CD by pressing C key right after power up and holding till bright white screen (white screen after dim white screen).
 
#Observe memory size and CPU speed from finnix boot messages. Record those.
 
#Display HD type and CD (DVD) type. hda is hard drive, hdb is CD.
 
#*cat /proc/ide/hda/model
 
#*cat /proc/ide/hda/capacity
 
#*cat /proc/ide/hdb/model
 
#Record HD and CD(DVD) info.
 
#Use 'lspci' to to display video controller model.  The appropriate line will have 'VGA' in it.  Record that.
 
#Set hardware (CMOS) clock to current UTC (GMT) time
 
#*date -u MMDDHHSSCCYY
 
#*clock -uw
 
#Shutdown with '''shutdown -h now'''.  CD should be ejected; observe if ejection is sluggish.
 
#If insertion and/or ejection is sluggish, CD(DVD) drive is a candidate for replacement.  This depends on availability.  Replace if possible with a newer model.  Do '''not''' replace with '''CR-1750''' (oldest known slot loader).
 
#Install Ubuntu-ppc (or Xubuntu if memory is 192MB).  Machine will eject CD and reboot when done.
 
#If video controller is '''ATI Rage 128 Pro Ultra''', Ubuntu boot might be really slow, mouse and keyboard unresponsive.  Drop to CLI terminal with '''CTL+ALT+F1''' (you may have to wait for it, due to slow operation) and remove glx module from xorg configuration, either with '''dpkg-reconfigure xserver-xorg''' or by  editting '''/etc/X11/xorg.conf''' directly.  (need explicit step-by-step here for restarting the desktop)
 
#Update software using '''Synaptic Package manager'''.
 
#Test sound.  Slower machines with older CD drives may exhibit 'skipping' behavior.  Two possible solutions:  replace CD drive with a newer one, or install '''gxine''' and set media.audio_cd.slowdown parameter to 12, and increase buffer count.  Probably choose replacement first; choose '''gxine''' if replacement is not available.
 
#Wipe down case and screen; clean keyboard and mouse if necessary.  Choose a 3-button or 2-button USB mouse if available, else use a standard Apple 1-button mouse.
 
#Fill out green configuration sheet, note any blemishes or other exceptions, set the price, tape form to case, attach a power cord.  Take the bundle to the store.  (need some suggested pricing guidelines here; Loren's pricing instinct is good, Macs in the store are selling, and his suggestions should be used to set up a pricing schedule as a guide.)
 
 
 
 
 
This procedure does not address failure of the system to power-up.  Such a failure could be due to physical power supply problems or PRAM problems.  Testing the power supply is currently beyond the scope of  Mac Triage/Eval/Rebuild. Resetting the PRAM is described in sthe step about OpenFirmeware. There may need ot be some reorganization.
 
 
 
==7jan07==
 
Sometimes iMacs come in with OS X installed with high security settings.  OS X usually requires a user login with password, which of course is not known.  There might also be  another level of security at the OpenFirmware level, implemented as an OpenFirmware password.  This is similar to the BIOS admin password that is sometimes present in x86 (PC) machines.  It is also possible to set parameters in OpenFirmware that lock out the keyboard, and /or restrict which drives can be used as boot devices.  In some cases there is another layer of security implemented by a third party software package that sits between OpenFirmware and OS X, with it's own password protection.
 
 
 
The OpenFirmware password feature is only available, I think, with versions of OpenFirmware starting with 4.  Installation of OS X requires, I believe, a firmware upgrade to some 4+ version. 
 
 
 
Without the OpenFirmware password feature, Mac OS X login supposedly can be defeated by booting into single-user mode at power-up with the Command+S keyboard combination.  The object for Freegeek MacBuild is really to be able to boot an install or rescue CD.  If the keyboard is locked out at the firmware level, the only way I know at this point to defeat the protection is to completely drain the logic board of any residual charge and press the PMU button, which does something to the PRAM that resets it (if
 
I understand the procedure correctly).  The steps are described in the step-by-step i the 6jan07 entry under item 8.
 
 
 
==11jan07==
 
''B&W Ge Tower, SCSI drives, OSX/OF Security''
 
Worked on a G3 B&W Tower today.  It had OSX 10.3.3 installed with high security (kbd lockout).  I defeated it by reinstalling OS X (10.0) and resetting the CUDA/PMU.  This model has two buttons that look  like the CUDA/PMU button, near the battery and PCI slots.  I think the left one (me facing the front of the box with the side panel open) is the Power button and the right one is the PMU/CUDA. I'm not sure what the Power button does.  The bit about installing Mac OSX might not be necessary.  Before pushing the PMU/CUDA button, I removed and replaced the PRAM battery.  A good PRAM/NVRAM references is [http://www.geocities.com/texas_macman/pram.html here].
 
 
 
This particular box is one of the earliest B&W Towers, and uses SCSI drives. It has and Adaptec AHA-2940 controller (I think).  The instructions for removing the SCSI drives are [http://docs.info.apple.com/article.html?artnum=111769 here].  There are 2 SCSI drives, a 9GB (the original, I believe), and an additional 4GB drive.  Dave found a pair of 18GB drives to replace them with.
 
 
 
The information about defeating security should go in the Triage/Rebuild graph.  It's included in my step-by-step description as item 8 in the [[#6jan07]] entry.
 
 
 
==12jan07==
 
There are actually two G3 B&W Towers on the work bench.  The second one is more conventional, with a single IDE hard drive.  The video contollers in the two boxen are the same: ATI Rage 128 RE/SG (PCI).  I got as far as installing Ubuntu on the IDE box, but the installation would hang at random places, hang so bad that keyboard and mouse events were ignored. I remembered that this IDE box had not powered up at first, and since I had to install memory (there was none in it) the only other thing to reseat was the video card, so I had done that. Because of that I suspected that the video card might be involved.  I swapped the video cards between the IDE box and the SCSI box.  The hang symptom disappeared from the IDE box, and the installation and sale prep were successfully completed.  Not surprisingly, the hang symptom appeared in the SCSI box.  In addition, Ubuntu installation on the SCSI box reported many many package retrieval failures (CD read failures).  That particular Ubuntu CD has been used many times with no problems.  That is not to say that the CD is not damaged; it could be, and I will need to check that. 
 
 
 
A more hopeful assumption is that the video card is really screwed up and causing lots o' problems.  In order to test that, I would need another video card, the same kind.  As far as I know, that means taking one out of another G3 B&W Tower. That Tower would become either a zombie, waiting around for a spare video card to turn up, or a mining source.
 
 
 
==19jan07==
 
The flaky video g3/tower went on the "wait-shelf".  The other one went to the store. 
 
Several things go on the "wait-shelf".  Right now there are systems that are "in the queue", systems that are waiting for parts, systems that have been partially cannibalized, and systems that have problems that we would like to solve.  I'm using quotes in some places because none of these things are formalized, and I'm making up names as I go along. Systems "in the queue" are candidates that have not been evaluated yet.
 
 
 
I looked at a couple of G4 Towers that are on the "wait-shelf".  Loren had done a preliminary triage on them. One is a 1GHz dual processor system, and the other is an 867MHz dual processor system.  One of the processors in the 867 system (both processors are on one board) appears to be fried, and the system will not power up.  The 1GHz system also does not power up, but the fans start up.  I think the hard drive spins up, too, although I'm not certain about that.  So what should we do about these systems?
 
 
 
The 867 with the fried processor is not recoverable without a replacement processor board.  We can keep it for awhile and hope that a replacement shoes up.  We could mine it for battery/memory/hard-drive and put it back in the Mac Pile for MacRenewal to take away. We could mine it and recycle it locally.  Towers can be dismantled and recycled since they have no integrated display.
 
 
 
The issue of whether or not we recycle any Towers should be discussed with MacRenewal.  Do they want mined systems?
 
 
 
Since this is the process definition stage, we should be making decisions about what kind of problems can be solved and what cannot.  Systems with problems that cannot be easily solved should be cycled out, either by returning them ot the MacPile or recycling them locally.  I guess that is part of the established eval/triage phase.
 
 
 
==23jan07==
 
''Macs that Resist Ubuntu Installation, Revisited'' (see [[#5jan07]] entry)<br>
 
The G4/700 Flast Panel half-dome CD boot problem is apparently a weakness in the Dapper and Edgy installation CDs.  Both Breezy (5.10) and Feisty (7.04 alpha) installation CDs boot in the G4/700 just fine.  The Breezy CD uses a less than perfect video interface, but it works.  The Feisty CD apparently solves the video problem for nVidia controllers; unfortunately, it seems to have forgotten how to handle ATI controllers in G3 machines.  It boots in a G3 'bubble' iMac (at least it gets to the login sound report) but without video.
 
 
 
==3feb07==
 
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]]).  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" 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 ow 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, althoug 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]])?  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)
 
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  G# 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)
 
## '''c''' command to create a linux  partition: start=2018, length=(freespace - 1494839), name=untitled
 
## '''c''' command to create a linux swap partition: start=2018+linuxPartitionLength), length=1494839, 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'''
 
#* 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.
 
* 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, '''\\:txbi'''.  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 environement variable.
 
* 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.
 

Latest revision as of 20:51, 23 March 2007

Redirect to: