10.85 Supplement now includes Mach_Kernel in HD window.

As an admin user, Copy/paste this into terminal, then hit return.

sudo chflags hidden /mach_kernel

It will ask for your password. Enter it, but you won't see it echo back on the screen. Just type it and hit return.

I haven't updated, yet. However, things like that have been reported in the past.

Whatever wrote the file didn't set the hidden bit.

Update: Yes, it was not hidden when I updated.

You are not alone. I also see the mach_kernel file in the root directory of Macintosh HD.

Joseph you aren't alone. This post wasn't here earlier when I installed the 10.8.5 supplemental update. I too have 3 computers and the mach_kernel file was visible on all 3 computers. As per another post I used the above terminal command and file became invisible on all 3 computers.

Ditto!

time for a supplemental update 🙂

You mean a supplemental supplemental update 😉

Showed up here too. Not brave or savvy or mad enough to mess with it.

I also had the mach_kernel expose itself in my HD root after the update.

I used the terminal command posted earlier to hide it again. Thanks for that post, saved me from having to Google it.

I agree whole heartedly with Joseph Kriz that Apple dropped the ball.

Lets see what Mavericks brings... hopefully I won't have to go through all the software upgrades I did with Mountain Lion and the speed returns.

Joseph Kriz wrote:

I think most of us here are savy enough and been around quite a long time.

Apple apparently has gone mostly to mobile devices and has dropped the ball on the original Apple Computer software.

I've been around long enough to have seen this happen periodically going back way before iOS.

iOS isn't the boogeyman.

Joseph Kriz wrote:

Some say, if it says "Repair Permissons Complete" then the problems have been fixed.

I say, no way in God's Green Earth.

If they were fixed, then the same ones wouldn't keep showing up as needing fixing.

Those permissions didn't need fixing in the first place. As the text in the Disk Utility First Aid window says, you only need to click Repair Disk Permissions if you have a permissions problem. In fact, the help topic for it says:

If you see a message that your permissions are set improperly, you may be able to correct the disk’s permissions.

So if you don't see any such message & your apps installed by the OS X Installer.app, Software Update, or an Apple software installer work normally, there is no reason to run a Permissions repair. It is just a waste of time to do so because there is nothing that needs fixing.

What the permissions repair actually does is compare the permissions of these files against locally stored receipts data created by an installer. If they differ, you see the familiar "permissions differ on xxx" message. But that doesn't necessarily mean there is anything actually wrong with the file's permissions. Frequently, it just means that an app update has not modified the locally stored receipts data for some of that app's component files, so that data differs from the actual permission string of those updated files. In that case, "repairing" them could actually damage them. Fortunately, the repair doesn't do that, regardless of what the log says it does.

Note that a file's permissions string contains more than its permissions settings. The leading character indicates its file type. A dash indicates a regular file, a "d" indicates a directory (a folder in user terms), a lower case el indicates a symbolic link, & so on. So when you see something like "should be -rw-rw-r-- , they are lrw-rw-r-- " in the repair log, all it really means is the file's receipts data has not been updated to indicate the file is now a link instead of a regular file. The repair can't (nor should it ever) change the file's type, so when you see "repaired permissions for xxx" the log is accurate because the permissions part of the string has been "repaired" (resulting in no change) even though the file type still differs from what is in the receipts data for it.

That's an example of why you can run the permissions repair repeatedly & still see the same "permissions differ" messages every time you do so -- & why it is pointless to do that. Once you see the 'repair complete' message, the repair has done everything it can & should do to reset permissions to match the receipts info.

I realize all those repeating "permissions differ" messages bother some users but the fact remains that they won't go away unless & until an installer updates the receipts info for those files, & there is no particular reason for an installer to do that unless & until it affects the operation of the app(s) that rely on those files.

If not setting the hidden bit on one file is the only "bug" left in 10.8.5, then I say "Job Well Done!" 😉