Seeking clarification
Please add to the opening question a note of whether the panic occurs during:
a) the preparation stage of installation (before the first automated restart of the system)
or
b) post-preparation, the installation stage (between the first and second automated restarts).
Logging the preparation and installation stages of installation
Screenshots at http://www.wuala.com/grahamperrin/public/2011/08/01/a/?mode=gallery demonstrate the Installer Log window in foreground whilst Mac OS X Installer runs — the installation stage.
During either stage (preparation or installation) you can present a log window by keying:
With luck, you might see — possibly greyed-out beneath the foreground detail of the panic — the point at which panic occurs.
At the root of the volume to which installation is attempted: if installation fails you may find a directory:
Mac OS X Install Data
Within that directory, a log. If present, that log may be informative to you, but not as useful (to readers here) as the .panic file.
PRAM, kernel panic information and the .panic file
Apple's Mac OS X: What's stored in PRAM tells us that recent kernel panic information is stored in PRAM. If the first normal start following a panic does not present the customary dialogue, you should wonder whether/how that information was lost from PRAM.
If the kernel panic occurs during the installation stage — and if the subsequent start defaults to attempt continuation of the installation, or Mac OS X Utilities (not a normal start) — and if you are without an obvious interface to kernel panic information — then my hunch would be that whilst started in that special mode, the path to which a .panic file might normally be written is read-only …
… if that's the case and if you're comfortable at the command line, maybe start in single user mode following the panic then use the following command to see whether panic information is legible on screen:
nvram -p
(For the number of ifs above, apologies!)
Mac OS X defragments small files on the go, and has a hot file optimization zone where medium sized and frequently accessed files get ordered on the fast part of a hard drive.
If a tool does a block copy of the drive - fragmentation of files and directories gets moved to the copy destination. When you create a CCC clone, you are not copying the fragmentation state of each file--each file gets written as a single extent on disk. Likewise when you restore from the clone. So if you just wiped and restored from the clone, you'd be starting clean right there.
The apple Disk Utility can be told to do a file level copy or a block level copy - so for a one time copy - it's about as capable as CCC and SuperDuper.
If you're at 95%, it seems to me that a bigger problem is that the operating system can't allocate as much virtual memory as it would want, which would result in a lot of disk thrashing as it constantly clears out the limited VM space it has, which would be consistent with the problems you are reporting. Solution: bigger or emptier hard drive.
Best Answer
If you have the latest "Install Mac OS X Lion.app" procured from the App Store, then you could use the InstallESD.dmg within that to make a universal installer (described elsewhere) -- it will have all the drivers needed for any/all Macintosh machines that meet its hardware requirements. Note if you're handy with SSH, ARD or other methods to remotely control the machine in question, the upgrade/installation could be entirely remotely.