A.receiptdb

Backup your a.receiptdb files (/Macintosh HD/Library/Receipts/db/a.receiptdb) takes a lot of space on the external drive, which uses a TM. Maybe remove them and prohibit further backup?
I doubt they need.

I had tried reinstalling the 10.5.6 combo update and then repairing permissions to see if a.receiptdb would pick up all the other .pkgs & .boms, it didn't: it only had the 10.5.6 update. Repair Permissions took a few seconds, not the minutes it normally does.
AFAIK Disk Utility only reads a.receiptdb. Installer modifies a.receiptdb, adding what it's installing to it. But I've found nothing that will recreate a.receiptdb from the .pkgs & .boms in /Library/Receipts.

Similar Messages

Anyway to manually rebuild /Library/Receipts/db/a.receiptdb?

Some software I installed recently deleted /Library/Receipts/db/a.receiptdb. I found out when Leopard was acting weird and I couldn't repair permissions. I have too many apps & updates to track down what caused this.
I've scoured the web & ADC looking for a way to manually rebuild a.receiptdb, found zip. To get productive quickly, I did a clean install. I now back up /Library/Receipts/db/a.receiptdb nightly JIC.
Two questions:
1) Has anyone figured out if there's a way to rebuild a.receiptdb from the Receipt .pkgs and .boms?
2) Does an Archive & Install with migrating apps work properly if a.receiptdb is missing?
I hate to think OS X is putting all its eggs in one basket like Windows does with the Registry...
TIA,
Sam

I had tried reinstalling the 10.5.6 combo update and then repairing permissions to see if a.receiptdb would pick up all the other .pkgs & .boms, it didn't: it only had the 10.5.6 update. Repair Permissions took a few seconds, not the minutes it normally does.
AFAIK Disk Utility only reads a.receiptdb. Installer modifies a.receiptdb, adding what it's installing to it. But I've found nothing that will recreate a.receiptdb from the .pkgs & .boms in /Library/Receipts.

External Hard drive/Time Machine backup error message

On a sidenote, I posted a question a week ago about what external hard drive would be compatible with my Macbook, and I so happened to get a WD My Passport Studio hard drive as an unsuspecting gift, so I didn't have to buy one.
Anyways, I started the backup on this hard drive and I had an error message: "Unable to complete backup. An error occurred while copying files to the backup volume." I searched this on the Apple Support Communities and found that I wasn't the only one who had this problem. So, I came upon one discussion that suggested downloading Time Machine Buddy (link:http://pondini.org/TM/A1.html) (link that prompted me to download: http://pondini.org/TM/C3.html). I downloaded it and found out that the error was occurring in my Library folder, specifically in the folder entitled "db" in the "Receipts" folder. There's one file in the "db" folder entitled "a.receiptdb" <----can someone please explain what the heck this is??? Lol. Anyways, I decided to exclude the whole "Receipts" folder from being backed up and now my external hard drive is backing up my files fine. My MAIN question is this: What is wrong with my receipts folder that is causing the error?
P.S. here are the error messages in the Time Machine Buddy log:
Error: (-36) SrcErr:YES Copying /Library/Receipts/db/a.receiptdb to (null)
Error: (-36) SrcErr:NO Copying /Library/Receipts/db/a.receiptdb to /Volumes/My Passport Studio/Backups.backupdb/Josh Brew’s MacBook/2012-01-29-162450.inProgress/D9F83053-7FE1-4EBE-991A-F400C35D37CC/Macin tosh HD/Library/Receipts/db
Stopping backup.
Error: (-8062) SrcErr:NO Copying /Library/Receipts/db/a.receiptdb to /Volumes/My Passport Studio/Backups.backupdb/Josh Brew’s MacBook/2012-01-29-162450.inProgress/D9F83053-7FE1-4EBE-991A-F400C35D37CC/Macin tosh HD/Library/Receipts/db
Copied 246 files (277.4 MB) from volume Macintosh HD.
Copy stage failed with error:11
Backup failed with error: 11
As you can see, iy is located in the "db" folder. I have no idea what's wrong. Thank you for your time! It is MUCH appreciated.

The connection to 10.6.7 may just be a coincidence. I had a similar problem with a disk and was about to throw it out but decided to try a different USB cable. That fixed the problem and the drive is still in use.
Try a new cable if you have not already done so.
Dave

Disk Utility won't verify or repair permission

As the title says I am having a problem with Disk Utility. The hard drive is brand new (just replaced by Apple Store) and I wanted to repair permissions after the dock wouldn't unhide (this had fixed it in the past). It starts, and says about 1 minute remaining. Nothing happens, the only text displayed is telling me that it has begun. The status bar doesn't move and then it hangs and i get the spinning wheel.
The same thing happens for verify and repair for permissions and disk.
Any advice would be great.

A quick search in these forums for permissions or *permissions problem* reveals many posts the past four months.
In a nutshell, repairing permissions w/Leopard takes anywhere from 10-40 minutes, depending on what's installed and what's contained in /Library/Receipts/bom/. The repair permissions operation has changed in Leopard. The stalled progress bar is an unresolved bug (they haven't figured out how to make it work whilst it's checking or rebuilding the a.receiptdb, in /Library/Receipts/db/. To see what's really going on, open that folder in a Finder window, select list view, launch Disk Utility, select your boot volume, and click on repair permissions. Watch the Finder window flash files that are being read and checked against the current a.receiptdb file. That's what's taking all the time and freezing the progress bar. Once that's finished, the progress bar starts moving and the permissions are being checked and repaired. Also note, that you won't get any *they were repaired* message back for any that are noted to be incorrect.

Install of OS X leopard on Powerbook G4 stalls each time

Hi - I was wondering if anyone out there could help me - I have a Powerbook G4 15", bought around 2005/6. Great machine, never had any problems... until now... I recently did an apple security update, after that the computer never rebooted, always got hung on the spinning cog thing.
I backed-up the hard disk, then did an erase and install with my OS X install DVD. It all works fine for a while and usually gets to the point where it says "around 1hr 11mins to go". Then it never moves on! I have looked at the log and it seems to be working fine, then stops progressing. I have left it going the last 2 nights, but after 8hrs+, no progress.
If it helps, this is what the last few lines of the 295 line log look like:
Apr 15 01:50:07 localhost installdb[217]: The db cache for '/Volumes/rl/Library/Receipts/db/a.receiptdb' contains: {\n schema = 0;\n sqlite = <01d07510>;\n}
Apr 15 01:50:07 localhost installdb[217]: Initializing database with schema version 17 at '/Volumes/rl/Library/Receipts/db/a.receiptdb'.
Apr 15 01:50:07 localhost payloadExtractor[216]: Extracting...
Apr 15 02:00:50 localhost Unknown[66]: 1976-04-15 02:00 Mac OS X Installer[153] (CarbonCore.framework) FSEventStreamStart: ERROR: FSEvents_connect() => Unknown service name (1102)
Apr 15 02:00:53 localhost OSInstaller[153]: installAutoFSMonitor: open failed
Apr 15 02:01:10 localhost installdb[217]: idle 10 min with 1 open connection.
Apr 15 02:11:11 localhost installdb[217]: idle 20 min with 1 open connection.
Apr 15 02:21:11 localhost installdb[217]: idle 30 min with 1 open connection.
Apr 15 02:31:12 localhost installdb[217]: idle 40 min with 1 open connection.
Apr 15 02:41:12 localhost installdb[217]: idle 50 min with 1 open connection.
Apr 15 02:51:12 localhost installdb[217]: idle 60 min with 1 open connection.
Apr 15 02:51:18 localhost installdb[217]: closing abandoned connection 1
Apr 15 02:51:30 localhost installdb[217]: Closed receipt database on '/Volumes/rl/Library/Receipts/db/a.receiptdb'
Apr 15 02:51:30 localhost installdb[217]: done. (4.391u + 1.672s)
I am really not that techy, and have never done OS installs on macs before until now. I am loathe to bring it to an apple reseller in Dublin as they will charge $$$s just to look at it!
If anyone can help or has experienced something similar and found a solution, I would love to hear from you.
Thanks very much, Sally.

One possibility is there's a problem with the installer DVD. Carefully clean it. Another is a problem with computer's optical drive mechanism. There are laser lens cleaning discs you can purchase to clean the laser, but if the drive is out of alignment that requires a technician to fix. A third possibility is that the hard drive has defects or is failing. You can do the following to see if it fixes the problem:
Extended Hard Drive Preparation
1. Boot from your OS X Installer Disc.
2. After DU loads select your hard drive (this is the entry with the mfgr.'s ID and size) from the left side list. Note the SMART status of the drive in DU's status area. If it does not say "Verified" then the drive is failing or has failed and will need replacing. SMART info will not be reported on external drives. Otherwise, click on the Partition tab in the DU main window.
3. Under the Volume Scheme heading set the number of partitions from the drop down menu to one. Set the format type to Mac OS Extended (Journaled.) Click on the Options button, set the partition scheme to GUID (for Intel Macs) or APM (for PPC Macs) then click on the OK button. Click on the Partition button and wait until the process has completed.
4. Select the volume you just created (this is the sub-entry under the drive entry) from the left side list. Click on the Erase tab in the DU main window.
5. Set the format type to Mac OS Extended (Journaled.) Click on the Options button, check the button for Zero Data and click on OK to return to the Erase window.
6. Click on the Erase button. The format process can take up to several hours depending upon the drive size.
Lastly, there may be memory failure. This may be evidenced if the install fails at random points in the process. However, this is not definitive. Unfortunately, there are no truly reliable tests for RAM except to remove a module and then run the machine to see if the problem ceases.

Can't Verify Disc Permissions in 10.5.2... among other G5 problems

I've been experiencing all kinds of issues with my first release PowerMac G5 (comatose sleep mode, racing cooling fans, video failure after restart, etc.). I've since learned not to be an early-adopter.
I had these problems running on 10.4.10 (had to go back to that after 10.4.11 really screwed up my machine). Issues subsided somewhat for a month or so but ten resurfaced with a vengeance. So, now, I've upgraded up to 10.5.2, reset PMU (yes, PMU, not SMU - early G5, remember), reset the PRAM/NVRAM, etc. without any remedy, so I'm trying to run Disk Utility.
I've restarted from my Leopard install DVD and have been able to successfully run 'Verify Disc' and received the good news that "The Volume X appears to be OK." Now, when I try to run 'Verify Disc Permissions' it starts but then just sits there, no progress bar... no progress. Eventually the screen just goes to sleep and never finalizes (or even starts?) the 'Verify Disc Permissions' process. Have tried multiple times and the only thing I can do is hit the 'Stop Permissions Verify' button, otherwise, if it does sleep the process just freezes and all I can do is hard restart.
Any ideas?

It takes anywhere from 10-40 minutes to repair permissions, depending on what's installed and what's contained in /Library/Receipts/bom/. The repair permissions operation has changed in Leopard. The stalled progress bar is an unresolved bug (they haven't figured out how to make it work whilst it's building the a.receiptdb, in /Library/Receipts/db/. To see what's really going on, open that folder in a Finder window, select list view, launch Disk Utility, select your boot volume, and click on repair permissions. Watch the Finder window flash files that are being read and written to a new a.receiptdb file. That's what's taking all the time and freezing the progress bar. Once that's finished, the progress bar starts moving and the permissions are being checked and repaired. Also note, that you won't get any *they were repaired* message back for any that are noted to be incorrect.
BTW, upgrading/updating when you have a hosed system is never a good move.

OSX Lion Disk Utility won't verify/repair RAID volumes

SInce I upgraded to Lion (now at 10.7.4) I can't use the Disk utility to verify or repair the disk catalog (disk first Aid) on apple soft RAID volumes. These volumes were created in 10.6 use the Apple RAID feature of disk utility.
I have one striped and one concatenated volume - neither will work. Press the button and the progress bar flashes for a fraction of a second, then nothing. no error, no message in the window - just no repsonse. Works fine on non raid volumes in the same disk enclosure -Firmtek Seritek/5PM, with seritek 2ME4-E sata card.
Not sure I really want to recreate and recopy the drives....
Any ideas? Seaches haven't turned up this specific issue.

A quick search in these forums for permissions or *permissions problem* reveals many posts the past four months.
In a nutshell, repairing permissions w/Leopard takes anywhere from 10-40 minutes, depending on what's installed and what's contained in /Library/Receipts/bom/. The repair permissions operation has changed in Leopard. The stalled progress bar is an unresolved bug (they haven't figured out how to make it work whilst it's checking or rebuilding the a.receiptdb, in /Library/Receipts/db/. To see what's really going on, open that folder in a Finder window, select list view, launch Disk Utility, select your boot volume, and click on repair permissions. Watch the Finder window flash files that are being read and checked against the current a.receiptdb file. That's what's taking all the time and freezing the progress bar. Once that's finished, the progress bar starts moving and the permissions are being checked and repaired. Also note, that you won't get any *they were repaired* message back for any that are noted to be incorrect.

Constant permission error

Hello,
I have already been told that it is nothing serious, but if someone could guide me on explaining the reason for the error or message reported, I will appreciate.
When doing a Repair Disk Permissions, I get:
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAg ent" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Reso urces/Locum" has been modified and will not be repaired.
Is there a way to fix this? I have some issues with my computer, and I want to discard that it is not related with the permission errors, therefore I wish to clear them out (by fixing what is causing them).
thanks,

Under SL, with the loss of /Library/Receipts/db/a.receiptdb, for some reason Repair Permissions won't look beyond the original install package to check for possible updates. The problem probably lies with Disk Utility and not the underlying /usr/libexec/repair_packages. The former has access to potential multiple packages via '/usr/sbin/pkgutil --file-info' and the latter has provisions for adding additional packages to the standard list of packages to verify or repair.
That software glitch is probably the cause of those two traditional 10.6.1 Snow Leopard SUID file warnings. If you really want to eliminate those warnings, there is a way but it isn't pretty. The fix involves borrowing the 'PathSHA1Checksums' value from one plist and replacing the 'PathSHA1Checksums' in another plist.
The plist files that need to be changed are found in the /private/var/db/receipts directory. They are in binary format and could be converted to/from text while the changes are made. Or, after navigating there (Finder->Go->Go to folder), the Property List Editor could be employed if Xcode is installed.
Here are the particulars:
1. copy the PathSHA1Checksums value for "Locum" from
/private/var/db/receipts/com.apple.pkg.update.os.10.6.1.plist
and replace the "Locum" checksum in
/private/var/db/receipts/com.apple.pkg.BaseSystem.plist
2. copy the PathSHA1Checksums value for "ARDAgent" from
/private/var/db/receipts/com.apple.pkg.RemoteDesktopClient.plist
and replace the "ARDAgent" entry in
/private/var/db/receipts/com.apple.pkg.Essentials.plist
If you then run Disk Utility Repair Permissions, those two errors should disappear. In my opinion, eliminating these messages isn't worth the trouble or the risk. If you do decide to proceed, good luck…

OK to delete boms for uninstalled printer drivers in /Library/Receipts?

I've trashed a bunch of unnecessary printer drivers from /Library/Printers. Can I trash their related Receipts in /Library/Receipts/boms? Together they are using quite a few MBs. They all start with com.apple.
Another quick question: A 3rd party app called DockDoctor installed a number of Receipts in the same location at boms. I've uninstalled the app, but would like to know if it's OK to trash their Receipts located there. If I do, could that cause some sort of conflict (permissions?) with the a.receiptdb (inside the db folder) which I noticed was changed at the time I installed the app? Thanks

You can delete items from the receipts folder if you really really want to, but I wouldn't recommend it.
- It shouldn't cause problems if the item is definitely removed.
- It could cause problems if the item isn't removed.
In any case, for most people the risk outweighs the benefit. If you're really short on hard drive space, I'd recommend other strategies. It's also generally a good idea to stay out of the /Library folder.

Unable to verify permissions

Hello,
Yesterday I did a combo upgrade to 10.5.4 on a Macbook 3,1. Before doing the upgrade I attempted to verify the permissions on my hard disk but received an error.
2008-07-15 23:13:53 -0400: Verify permissions for “Macintosh HD”
2008-07-15 23:13:54 -0400: Reading permissions database.
2008-07-15 23:13:54 -0400: Reading the permissions database can take several minutes.
2008-07-15 23:13:54 -0400: Error: The underlying task reported failure on exit.2008-07-15 23:13:54 -0400:
2008-07-15 23:13:54 -0400: Disk Utility stopped verifying permissions on “Macintosh HD” because the following error was encountered:
The underlying task reported failure on exit.
2008-07-15 23:13:54 -0400: Permissions verification complete
This only takes a second to happen so I don't think the permissions are ever checked. I attempted to boot from the Install Disk and run the permissions verify from there but get the same error message. The drive verifies with no problem, but the permissions verify can not run.
I attempted to install 10.5.4 anyway against my better judgment. Everything went fine until it attempted to write the receipt. The installer locked up solid for over an hour and I couldn't do anything but power off the machine. Luckily everything came back up with little to no issue, but I'm concerned with what I'm seeing in the install.log file.
Jul 15 22:07:07 Fiji installdb[899]: -[IFDBD_SchemaA updateFile:uid:gid:mode:]: database error (1): SQL logic error or missing database
Jul 15 22:07:07 Fiji /private/tmp/scripts.hRGQ/./postinstall[890]: IFDBExistingReceiptSetFilePerms() = 00000000, 1
Jul 15 22:07:07 Fiji pkgutil[1128]: Updating receipt 'com.apple.pkg.BaseSystem' path 'System/Library/UserEventPlugins/SCMonitor.plugin/Contents/Info.plist' on '/' with actual metadata from '/System/Library/UserEventPlugins/SCMonitor.plugin/Contents/Info.plist'.
Jul 15 22:07:13 Fiji installdb[899]: -[IFDBD_SchemaA(Utilities) pathkeyForPath:insert:] database error (1): SQL logic error or missing database
Jul 15 22:07:13 Fiji installdb[899]: -[IFDBD_SchemaA updateFile:uid:gid:mode:]: database error (1): SQL logic error or missing database
Jul 15 22:07:13 Fiji installdb[899]: -[IFDBD_SchemaA closeReceipt]: database error (8): attempt to write a readonly database
Jul 15 22:07:13 Fiji /private/tmp/scripts.hRGQ/./postinstall[890]: IFDBExistingReceiptSetFilePerms() = 00000000, 1
This is in the system.log:
Jul 15 23:06:21 Fiji com.apple.SystemStarter[40]: The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Jul 15 23:06:21 Fiji com.apple.SystemStarter[40]: Break on _THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___Y OU_MUST_EXEC_() to debug.
Most of these messages repeat over and over, so I'm a little concerned. Everything seems to be working, but because I had to restart the system during the upgrade, I'm worried something did not complete. This is the third time the system has locked up during an installation so I know something isn't correct. I've attempt to boot in to single user mode to run the fsck, but it says everything is fine and you can't use disk util to repair permissions in single user mode it seems.
Does anyone have an idea of what these messages mean?
thx

Hello and thank you to all who replied.
I wanted to give a quick update on what I found on my Macbook. I before I continue, I'm going state that I don't recommending doing what I did unless you are extremely comfortable with Unix/Linux.
After seeing the responses that I had to reinstall the OS I got really curious to what the Mac was doing, so I called up a friend of mine who is a linux admin. I too use linux a bit, but not at his level. He recently purchased a Mac as well.
He is new to the mac and hadn't heard of checking permissions before updates, so I explained the whole scenario. Once he understood the basics we got to work.
What we found is, there is a permissions database on the mac located in /Library/Receipts/db called the a.receiptdb. One his new Macbook Pro the file was owned by _installer and group wheel. On my Macbook the file was owned by root and group admin.
Changing the owner to _installer and group to wheel allowed the permission verify to run but reported some issues. Looking more deeply at the permissions, I also noticed that not only were the directory permissions for the db directory different, but also /Library/Receipts/boms directory and most of the pkg directories. The owner and groups didn't match up. Now I'm not saying mine were wrong, but they didn't match his newer install. So I changed the permissions on all of these files and re-ran the the permission verify.
It found a ton of permissions that were not correct. On top of that it found a lot of files that were OS and Unix binaries that had been modified so it wasn't going to change the permissions on any of them. I'm guessing this happened because the combo update didn't complete properly the first time.
After matching up the permissions, I allowed it to repair the permissions then re-installed the combo update while watching the console install.log. Everything finished with no errors. After the reboot, I ran the permission verify again, it only came back with 2 permission differences. I repaired those and was done.
I'm still getting the:
Jul 17 23:16:24 Fiji com.apple.SystemStarter[27]: The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Jul 17 23:16:24 Fiji com.apple.SystemStarter[27]: Break on _THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___Y OU_MUST_EXEC_() to debug.
On boot up in the system.log. Apparently something is starting up and getting stuck in a loop at start up so I'll have to see what that is, but overall everything seems to be working much better. I may do a re-install just to be safe at some point, but right now everything seems fine. I just need to track down what is getting stuck on startup.
It seems all of this was caused because the permissions were wrong on the files that verify the permissions. I'm kind of confused on why some of this is an issue because you enter your admin password before the update, which I thought meant that the installer will run as root, but that doesn't seem to be the case.
Thx
Message was edited by: J3P mac

How can I install 10.5.2 9C2028 over 10.5.2 9C31?

So, my load set is based on 10.5.2 9C31 (the 10.5.2 GM)
I got a new MacBook Pro that ships with 10.5.2 9C2028 -- a later build.
10.4.x -- when this happened -- would allow me to install the 10.4.x load set on a system, then use the "later build" 10.4.x DVD to upgrade the OS.
10.5.2 9C2028 -- the installer DVD -- is saying that 10.5.2 9C31 is a "later version" and won't let me do an upgrade.
I find if I purge the entire "a.receiptdb" file from /library/receipts/db, then this check goes away and I can install over top of 9C31, but upon the restart after install, it's stuck at the spinning grey wheel.
a "safe boot" brings up the normal Leopard "create an account", etc. screens -- which it shouldn't necessarily do.
Anybody have any other suggestions for a way to "overwrite" 10.5.2 9C31 with the new 10.5.2 9C2028? I'm not looking to do an "archive and install" with this as my load set has a ton of apps that would have to be reinstalled and a number of changes to the system OS which I'd have to do...
Thanks!
- Steve

The issue you're coming across is that 10.5 was forked after 10.5.1 and before 10.5.2. The build you have is specific to the new hardware, and there will not be a "merged" build that will work on all Apple hardware that is shipping "today" prior to 10.5.3. So if you want to try this, you're going to be reinventing some part of the wheel.
I will reiterate here that if you're looking to create an image that will deploy on all systems today, you are pursuing the wrong approach. You will encounter issues every time Apple releases now hardware. It's best to go with something that starts with Apple's base image and applies packages to customize it with your specific settings and applications, rather than trying to "nuke and pave" the thing from the ground up. But hey, I've only been working with people who are imaging systems for corporate IT deployment for 5 years. What do I know.

Error: The underlying task reported failure on exit and (~)file on root

following is error i'm getting while i run disk utility verify disk permissions
"Verify permissions for “Macintosh HD”
Reading permissions database.
Reading the permissions database can take several minutes.
Error: The underlying task reported failure on exit.
Permissions verification complete"
so i tried booting from leopard disk, i'm getting the same error there also
and i have a (~) file on my macintosh HD
somebody plz help

..."Error: The underlying task reported failure on exit."...
One reason this error can appear is if "repair permissions" is unable to read the permissions database at "/Library/Receipts/db/a.receiptdb" of the affected volume, due to incorrect permissions.
Yes, you read that correctly - "repair permissions", the procedure to correct incorrect permissions, can fail to work if permissions are incorrect. This is a ridiculous shortcoming of the new (in my opinion "beta"-quality) Leopard versions of "repair permissions" that goes out of its way to drop its privileges to a level that is insufficient to complete its job.
If you are able to manually adjust the permissions (eg. using 'chown', or 'chmod' -- I would recommend against using "Get Info" unless you are very careful since it also is "beta" quality in Leopard) of all of the folders along the path to the "a.receiptdb", and of the file itself, to ensure that the user '_installer' has at least "read" permissions, that should allow "repair permissions" to function...

Looooong Time To Repair Permissions

Brand new machine so I'm just learning it. Repair Permissions first reviews the Permissions Data Base. This takes 4 1/5 minutes by the clock. That seems a very long time. Is it normal? Then, it takes 2 min to repair even though it found nothing to repair. Again, is that normal?

OS X stores file and folder permission and ACL settings in the /Library/Receipts/db/a.receiptdb file.
Mine contains about 90mb of info. It may contain more than double that depending on optional
packages installed. If you would like to see whats in the file, drag a copy of it out on your desktop
and open it with Pacifist (don't try to open it in its default location, its permission setting won't
allow it). After looking at the contents, I think you will see why it takes as long as it does to repair
permissions.
Kj

10.5.5 Installation - hangs at desktop background image - Safe Boot?

Used the updater to install 10.5.5. A number of additional updates came down and all seemed to install fine. The 10.5.5 update did not install and provided an error. I tried again and on restart the system hangs at the desktop image. It gets past the grey apple screen and loads the desktop image. A small mouse arrow pointer comes up that I can move around but that is far as it goes. This is an iMac 24" with 4GB RAM.
Is there an option where I can "Safe Boot" and roll back the attempted installation? I have a time machine disk that I will unplug - but how can I recover from that if there is no "safe boot" option?

I've spent a lot of time digging around in the guts of OS X, Tiger and Leopard both. There is no magic
going on in there. If the right files are present and working and the caches and boot files are
functional, the OS works, if not you have problems or the OS quits working.
+"Apple tells us those messages are accurate but can be ignored. What makes you think their+
+absence is a sign that the updates have been properly registered with the database that keeps+
+track of such things?"+
Definition: SUID (set user ID):
The SUID permission causes a script to run as the user who is the owner of the script, rather than the user who started it. What the SUID warning message is saying is that according to the install
database, the information the database has about that file (file size, modification date, checksum,
etc.) is different from the actual state of the file as it now exists on your hard drive. Because a
"SetUID root" (in other words, an executable file whose owner is "root" (aka system) and who has
its SetUID bit set) executable file has the power to run as root right as you launch it, you need to
be very careful about setting the permissions on files so that you create SetUID root executables
willy nilly. The warning means that because the executable is different from what Disk Utility
expected, it's not going to try to verify or repair the permissions on that file.
How did it get that way? A glitch in the install program and/or a file was locked and didn't get
updated properly during the update process.
+"Apple tells us those messages are accurate but can be ignored. What makes you think their absence is a sign that the updates have been properly registered with the database that keeps track of such things?"+
Well just for grins, I opened up a 10.5.5 combo update, the /library/receipts/db/a.receiptdb file
and compared the following files mentioned in this typical DU permissions repair warning:
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources /DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Reso urces/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner " has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconf ig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writecon fig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAg ent" has been modified and will not be repaired.
Using Pacifist, I compared the permissions in the 10.5.5 combo receipt database file and 10.5.5
combo update package against the actual files on the hard drive.They were all indeed identical.
I extracted the files to the desktop from the combo update, loaded them into hex fiend, loaded
the matching files from my hard drive into hex fiend and compared them. They were identical
in size byte for byte and in data with the 10.5.5 combo update.
I will continue to use my method, for I found that none of the discrepancies that you claimed
may exist did not in fact exist.
Kj

Permissions Database disappeared

Hello,
My iMac hung up on shutdown, I just had the spinning wheel for about 10 minutes. The startup drive was very full. I forced the machine to shutdown by hlding down the power button. Upon restart it seems that a few permission problems have appeared: I cannot access my idisk (it says the password is incorrect, I cannot access my shared folder (it asks for the password). I went to disk utility to repair permissions, it ran repair permissions which lasted for about 3 seconds and says it's all fine. Repair permissions on my machine usually takes about 10 minutes at least. It seems that my permissions database has been reset somehow. How can I rebuild it?
Thank you.
-cauri

When the act of repairing permissions takes no more than a few seconds or two, it's a symptom of exactly what you figured it must be: the permissions database isn't readable.
The permissions database is called "a.receiptdb," and it resides in the "Library/Receipts/db" directory. The files located in the nearby "Library/Receipts/boms" directory are the source for generating the database.
If any of the .bom files are missing, I won't be able to help you. If, on the other hand, you're experiencing the same problem I did, here's what what worked for me:
cd /Library/Receipts
sudo chown -R _installer:wheel boms
sudo chown -R _installer:admin db
If you're not comfortable using the Terminal, I'm sorry to say I don't have anything less .. um .. geeky. I tried to figure a way to do it all in the Finder, but using the "Get Info" window to change owners & permissions is too limited to work.

A.receiptdb

Similar Messages

Maybe you are looking for