Problem with 'optimising the system'

Kinniken

Registered
Everytime I try to install a new upgrade (like 4L7) via the installer, 'optimising the system' get stuck at 20% or so. OK, its not a crash, but as I cant do anything bar watching a spinning CD, I have no choice but to restart it. Not sure its too good for the OS either, restarting while updating things like that...
I tried doing it via the terminal, as shown on mosr.com, and I get the same thing... stuck after a min.
Any help, anyone?

Kinniken
 
Got a similar freeze when running the command from MOSR about prebinding for optimization purposes... Mine ended up in kernel panic. Let me know if you want specifics.
 
OK I tried this again, I knew better, and OS X told me I should have listened to myself and then it threw up on my nice new tie. I was denied access to applications, folders, and partitions with what seemed to be no pattern at all. Booted into single user mode (option+s, right?) and noticed there was a message: "to use update _prebinding run fsck -r and then run update_prebinding or redo_prebinding" or something like that. So I followed the instructions and ended up getting the same message I recieved last time: "WARNING: No physical memory suitable for paging or swap available, temporarily disabling [something]..."

My apologies that the error messages are neither verbatim nor complete, I thought I could fix it all {grinning sheepishly}. So I called Apple at this point and tried working a few things out but nothing wanted to work so they had me re-install OS X over the copy I had on the drive; they said it was like a "Restore-in-Place." That didn't work either so I said "fuggeddabaudit," booted into OS 9.1 on seprate partition and erased "Ecks," my OS X partition.

Better luck to all.
 
Me Too!
(like some brain-dead AOL-er)

I also got the freeze, spinning rainbow and everything's inaccessible, from the Dev Tools Installer, the MOSR command, and a GUI app that as far as I can tell just executes the same command. I'm installing the 10.0.1 update when I go home today, I'll see if that fixes this.
 
I've now tried the update_prebinding again in single-user mode(after installing 10.0.1), received the error someone mentioned above...

No default memory manager found
Warning: no physical memory suitable for pageout or reclaiming, pageout thread temporarily going to sleep
Warning: no physical memory suitable for pageout or reclaiming, pageout thread temporarily going to sleep
Warning: no physical memory suitable for pageout or reclaiming, pageout thread temporarily going to sleep
etc....

SO... tried again using my mac's original 128MB stick, (3rd-party chip out of machine), and got the same result.

so no answer, just more things it's not
 
This may turn out to be useless, but the update_prebinding command has a debug switch (-debug). Anything useful come from running update_prebinding again with -debug?
 
Originally posted by kentj01

No default memory manager found
Warning: no physical memory suitable for pageout or reclaiming, pageout thread temporarily going to sleep
etc....

That is EXACTLY what I got. {grin} I think. {/grin}
 
I have the same problem every time! I heard somewhere you need about 256 ram, and a lot of hd space. Maybe someone who actually has it working could post their system specs.....
I really wanna update_prebinding cuz os x is very slow
 
I am running as follows:

G4 450 DP/MP
448 MB RAM
3+ GB Free space on OS X partition.

Does this qualify as "about 256 ram, and a lot of hd space"?
 
Does everyone that is having this problem have OS 9.1 on the same partition as OS X? Maybe that could be our problem.....
 
I just want to report that on my G4 450 w/256MB RAM prebinding worked but took like an hour (for the last 10 pixels on the progress bar). It looked frozen but I just let it run.
 
He must have used X Optimize or maybe he is talking about the optimization after an installation. They are both the same thing as the command line tool
By the way, I was wondering if there is any way to optimize directories one by one instead of optimizing the whole system which is obviously taking a s**t load of ram and virtual memory. Could having OS 9.1 be our culprit?
 
I am also on a single partition, this could very well be the cause... if anyone's getting this problem on a multi-partition system please speak up as a counterexample, otherwise I'm running with this idea and reformatting.

I really don't want to do this so _please_ speak up if that's you :)
 
To run on just a single directory heirarchy, instead of all of / (ie, just /System) try changing the '-root /' to '-root /System'. See the manpage for that argument and others...
 
I found the problem! Its a little file created by Stuffit in the system folder. Boot into OS 9 and use a tool such as resedit to unhide a file named " Aladdin Transaction Info ". Once you have done this, go into your system folder and throw that stupid file in the trash and empty it. Now you can go back into OS X and run X Optimize or 'update_prebinding'. If all went well, you will not get any more error messages and the optimization will not loop for hours and hours. If it still does not work, follow these instructions from febo:

Hi all,

I just found a solution to the 'out of memory' problem when using update_prebinding.

I used the command 'fs_usage' to monitor the disk activity of update_prebinding.
It turned out that there was a file with rather exotic characters in it's filename in my OS 9 Systemfolder. When update_prebinding visited that folder it reread it's contents again and again... until it ran out of memory. I deleted that file, reran update_prebinding and it worked just fine :)

So here is what I did:
1. open two Terminal Windows
2. become root in both windows using 'su'
3. run 'update_prebinding -verbose -root /' in one window
4. run 'ps aux | grep update_prebinding' in the other
5. look at the line that does _not_ have the word 'grep' in it; note the number in the second column. This is update_prebinding's process ID. Lets assume it's 208.
6. run 'fs_usage -w 208' where 208 is of course the process ID you found in step 5.
7. wait until the point you remember update_prebinding stopped to make any progress.
8. Watch the output of fs_usage closely. When it starts to show only blanks where previously filename fragments where shown it's time to...
9. press ctrl-c in both the update_prebinding and the fs_usage window
10. scroll up in the fs_usage window until you see the last file or folder name in the middle column (it may be only a fragment, as fs_usage only displays the last 28 characters)
11. Go to that folder and examine it closely. The file that I had problems with didn't show up in the Finder but in the Terminal using 'ls -la'. Except for some questionmarks in the filename it also contained the String 'Aladdin'....
12. Now comes the tricky part: get rid of the file. I managed to remove it by using a visual ftp client, logging in on my own machine and hitting delete. I guess there are better ways - but I couldn't explain to Terminal (or 'tcsh' to be precise) what file I wanted to delete. Be careful: the file might be vital to your system. So you might just want to rename it instead. Or not even touch it at all. But this is for you to decide. Don't blame me!
13. run 'update_prebinding -verbose -root /' again.

Good Luck!
 
reformatted with two partitions, optimizing went seamlessly from the 10.0.1 installer. don't know if the single partition was indeed the culprit but it is indeed one possibility to seriously consider now
 
That Aladdin file is the culprit... I had the problem everytime I tried to optimise, so I stopped trying.
Later, I ran Disk Doctor from my OS9 partition on my OSX one and it did complain about that Aladin file, saying it contained characters (NUL ASCII value if you want to know) allowed under OS9 but not under OSX. It renamed the file.
Yet later, I tried optimising again (im stuborn) and found it worked... was even pretty fast. Just made the link between the two things now...

Kinniken

PS: prebiding didnt change much to my comp's speed though =( OSX is cool, but so SLOW... I'll just have to buy a two-processor G4, like Apple wants all OSX users to.
 
Back
Top