Jump to content

Spotlight gets disabled on system drive after logoff/restart


d2a
 Share

14 posts in this topic

Recommended Posts

So i'm happily chugging along with Yosemite - I know, it's old, so am I - and all's well. Basically a clover-based install on an old GA-P35C board, that was originally SL, then Mav, and finally updated to Yosemite. No clean installs - all updates.

 

But:

 

When I log out or reboot, the startup partition becomes unindexable and search is disabled.

sudo mdutil -s /
/:
	Indexing and searching disabled.

If i renable search:

sudo mdutil -i on /

The old index becomes useable for search, but the drive is still not indexable.

 

I have to remove the metadata_never_index file from the root of the partition:

sudo rm /.metadata_never_index

OK - all good right? But as soon as I log off or reboot, the partition has the never index file back in place and searching is disabled. So what have I got to do to the drive to get it back? Is there a secret boot flag (clover?) or disk partition flag that's been accidentally set? I did have issues initially getting the drive to show up in the finder, and found it had a hidden flag applied - could that be related? Really painful and I'm sure it's a corner case but if anyone out there has any inspiration I'd be grateful - thanks.

Link to comment
Share on other sites

Thanks. sure - i think it might be a permissions issue but i've repaired them a few times, both from System and using the Recovery partition, without improvement. i've tried disabling, enabling, adding to privacy in spotlight and then removing, without luck.

 

i've seen similar problems posted elsewhere so i don't believe it's limited to osx86

 

One thought: I had to run the yosemite installer app using the root user as it failed for the normal user. perhaps this has corrupted the permissions?

 

any thoughts on how to diagnose that?

Link to comment
Share on other sites

Nope - can't enable spotlight under a new user either.

 

Added System (boot OS partition) to privacy list in Spotlight, close prefs, and reopen and it's marked as private, reboot and it's gone.

 

Can't help feeling this may be a deeper partition level problem. the drive initially refused to show up on the desktop (unlike all other drives and partitions) or in the sidebar of the finder, after update. Could still be browsed fine, but i had to chflag the volume to get it to show up. Perhaps there's a flag or property in the partition table that's messing this up?

 

The .metadata_never_index file is added at logoff as far as i can tell, rather than startup...

Link to comment
Share on other sites

A ha - could be on to something. I'm on Clover 4035 according to the log. I have an EFI partition on the system drive, which does have the .metadata_never_index file in place. In fact, all partitions on this drive (recovery partition, EFI, OS) have a never index file. Is it possible i've misconfigured Clover? maybe i'll try a clean config file...

  • Like 1
Link to comment
Share on other sites

OK - you were right about the Clover RC script - 80.save_nvram_plist.local - I commented out the contents of the function dealing with .metadata_never_index, removed the .metadata_never_index from the /, enabled spotlight, and rebooted. File was not replaced, and indexing survived the reboot. Phew!

 

SO next question is why the script incorrectly identifies all the partitions of my drive as EFI and inserts the never_index file? I'll take a look over the script and see what i can deduce, but thanks for taking the time and for the pointer to the shutdown script.

 

If I learn more I'll post back here and possibly let the clover folks know too.

Link to comment
Share on other sites

So a quick test of the script run under terminal. I commented out a few lines here and there, but the basic flow seems to be:

  1. first run it reports: Found ESP on disk0s1**** disk0s1 Get mount point failed - all EFI partitions on attached drives are mounted and visible on Desktop. .metadata_never_index file is written to /
  2. if run a second time (with EFI partitions still mounted) it reports: Found ESP on disk0s1 with /Volumes/ESP-01/EFI/CLOVER. This correctly checks the EFI, spots that there's already a never index file and ends.

So perhaps there's an issue in not mounting the partitions fast enough before checking for the mount point. But there's certainly a logic problem, in that if no EFI mount point is found, it defaults to root.

Link to comment
Share on other sites

So after hacking around the script some more, it seems to have issues on my system because:

 

the first test it uses to determine the filesystem

file -sb /dev/rdisk0s1

returns something like this on my drive

x86 boot sector, code offset 0x63, OEM-ID "BSD  4.4", Media descriptor 0xf8, heads 32, hidden sectors 40, sectors 409600 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 3152, reserved3 0x800000, serial number 0x30691edf, label: "EFI        "

which does not match any of the cases in the test. It expects "DOS/MBR boot sector," or "DOS/MBR boot sector " or "Macintosh HFS Extend"

 

Secondly, once it fails on this test, it goes on to attempt to mount the partition using msdos hfs exfat in turn. but further down the function, it relies on the ${RETURN_VAL} == 0 test to confirm successfully getting the mount point, but this is reset by each loop of the mount attempts. so if the FS is msdos as in my case, the RETURN_VAL is set to 0, then reset to 1 by the hfs and exfat mount attempts.

Link to comment
Share on other sites

  • 1 month later...

hmm. well in clover rev 4013 there is code to set metadata never index on ESP on shutdown here.

 so now i guess the question is are you on clover 4013 and if so does the root of your drive have a EFI folder.

 

Same issue with clover rev 4035.

 

To make things clear... SOLUTION: Update to Clover rev 4061, reboot and you will get Spotlight working again!

Link to comment
Share on other sites

 Share

×
×
  • Create New...