Apple Knowledge Base's picture

Boot Camp: Press any key message appears while installing Windows 8 using DVD media (Apple KB)

When installing Windows 8 on an iMac (Late 2013) or Mac Pro (Late 2013), installation may not complete if you use an optical disc for installation. Instead, you are prompted to "press any key" or the computer restarts back to OS X.

Read more: http://support.apple.com/kb/TS5373

vijay-kumar's picture

All File & real folders disappear after run cvfsck -nv & -wv commands

anyone who can help me out from this problem and recover the volume data ??

serged's picture

XSAN Maverick FSMPM die randomly on 2 MDC.

Tags: 

We have a new install with 2 macmini, promise thunderbolt and osx 10.9.1    

 

Randomly the fsmpm seems to die and restart. This does happend on both mdc and a failover is triggered if the one failing owns the volume.  

 

 

 

First Maverick install...

THX
 

Serge.

 

 

 

 

 

 xsand[30]: Unable to connect to local FSMPM

 kernel[0]: Reconnecting to local portmapper on host '127.0.0.1'

20140130 13:48:07] 0x7fff777e6310 (debug) PortMapper: FSD on port 49170 disconnected.
[20140130 13:48:07] 0x7fff777e6310 (debug) PortMapper: FSS 'SANVOL01' disconnected.
[20140130 13:48:07] 0x7fff777e6310 (debug) PortMapper: kicking diskscan_thread 4389867520.
[20140130 13:48:07] 0x7fff777e6310 (debug) FSS: State Change 'SANVOL01' REGISTERED: (no substate) -> DYING: (no substate) , next event in 60s (/SourceCache/XsanFS/XsanFS-508/snfs/fsmpm/fsmpm.c#5597)
[20140130 13:48:07] 0x105a81000 INFO Starting Disk rescan
[20140130 13:48:07] 0x105a81000 (debug) Disk rescan delay completed
[20140130 13:48:07] 0x7fff777e6310 (debug) PortMapper: new_input authenticating protocol type(134) pmt_type(0) FSD(127.0.0.1)...
[20140130 13:48:07] 0x7fff777e6310 (debug) PortMapper: Local FSD client is registered, on port 49170.

Maverick, MDS, random failover

Hi all, I was awoken abruptly by a message stating that my Xsan volume had failed over. I got up to investigate, but can't find any telltale signs, other that some spotlight oddness. I recently rebuilt our SAN volume fresh under Mavericks.  Prior to this, I had always disabled spotlight, but I read over at Krypted.com that spotlight has drastically improved for Xsan 3, and that there should be no reason to not enable it. Checking my server stats and logs, I see that my acting MDC ramped up to a steady 20% CPU a few days ago.  That didn't subside until the failover this morning.  Looking at the logs, I can't see anything that corresponds with that much CPU usage.  The secondary MDC (now hosing the volume) also had some serious CPU usage following the failover, caused mostly by spotlight processes.  They were SERIOUSLY kicking the CPU.  We're talking total CPU usage in the neighborhood of 60% for the entire box.  Eventually, mds subsided and things are back to normal on the secondary, but I'll be damned if I can make sense of this.  Think I should just disable spotlight on this volume and rest easy? Some logs are below.  I'm particularly concerned about the inode errors at the end of it all. As always, thanks for any input! Pete Primary MDC (during the failover, nothing of note before this): 1/31/14 3:41:54.000 AM kernel[0]: Reconnecting to local portmapper on host '127.0.0.1' 1/31/14 3:41:54.000 AM kernel[0]: Local portmapper OK 1/31/14 3:41:54.269 AM KernelEventAgent[70]: tid 54485244 received event(s) VQ_NOTRESP (1) 1/31/14 3:41:54.269 AM KernelEventAgent[70]: tid 54485244 type 'acfs', mounted on '/Volumes/Xsan', from '/dev/disk14', not responding 1/31/14 3:41:54.270 AM KernelEventAgent[70]: tid 54485244 found 1 filesystem(s) with problem(s) 1/31/14 3:41:55.000 AM kernel[0]: Reconnecting to FSS 'Xsan' 1/31/14 3:41:55.269 AM fsmpm[329]: PortMapper: Initiating activation vote for FSS 'Xsan'. 1/31/14 3:41:56.800 AM fsmpm[329]: PortMapper: Starting FSS service 'Xsan[0]' on crosby.commarts.wisc.edu. 1/31/14 3:41:56.800 AM fsmpm[329]: PortMapper: Started FSS service 'Xsan' pid 70870. 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001440b6b lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001440b70 lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001440b7f lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001439f6c lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001439f5f lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001439f5b lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001439e8a lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x1000001439e83 lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x10000014321cc lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:02.000 AM kernel[0]: Cookie/0x10000014321ce lsn 0x0 got ESTALE for reopen, about to manually close 1/31/14 3:42:03.000 AM kernel[0]: Reconnect successful to FSS 'Xsan' on host '10.1.226.66'. 1/31/14 3:42:03.000 AM kernel[0]: Using v2 readdir for 'Xsan' 1/31/14 3:42:03.195 AM fsmpm[329]: PortMapper: Reconnect Event for /Volumes/Xsan 1/31/14 3:42:03.195 AM fsmpm[329]: PortMapper: Requesting MDS recycle of /Volumes/Xsan 1/31/14 3:42:03.195 AM KernelEventAgent[70]: tid 54485244 received event(s) VQ_NOTRESP (1) 1/31/14 3:42:43.330 AM mds[63]: XSANFS_FSCTL_SpotlightRPC fsctl failed (errno = 12) 1/31/14 3:42:43.330 AM mds[63]: ERROR: _MDSChannelInitForXsan: _XsanCreateMDSChannel failed: 12 1/31/14 3:42:43.340 AM mds[63]: (Warning) Volume: vsd:0x7fa0a38b5e00 Open failed. failureCount:0 (null) Secondary MDC (during failover): 1/31/14 3:26:32.534 AM secd[503]: SecErrorGetOSStatus unknown error domain: com.apple.security.sos.error for error: The operation couldn’t be completed. (com.apple.security.sos.error error 2 - Public Key not available - failed to register before call) 1/31/14 3:26:32.534 AM secd[503]: securityd_xpc_dictionary_handler EscrowSecurityAl[1230] DeviceInCircle The operation couldn’t be completed. (com.apple.security.sos.error error 2 - Public Key not available - failed to register before call) 1/31/14 3:41:53.864 AM KernelEventAgent[71]: tid 54485244 received event(s) VQ_NOTRESP (1) 1/31/14 3:41:53.864 AM KernelEventAgent[71]: tid 54485244 type 'acfs', mounted on '/Volumes/Xsan', from '/dev/disk14', not responding 1/31/14 3:41:53.865 AM KernelEventAgent[71]: tid 54485244 found 1 filesystem(s) with problem(s) 1/31/14 3:41:54.000 AM kernel[0]: Reconnecting to FSS 'Xsan' 1/31/14 3:41:54.864 AM fsmpm[332]: PortMapper: Initiating activation vote for FSS 'Xsan'. 1/31/14 3:42:01.000 AM kernel[0]: Reconnect successful to FSS 'Xsan' on host '10.1.226.66'. 1/31/14 3:42:01.000 AM kernel[0]: Using v2 readdir for 'Xsan' 1/31/14 3:42:01.578 AM mds[64]: XSANFS_FSCTL_SpotlightRPC fsctl failed (errno = 35) 1/31/14 3:42:01.578 AM fsmpm[332]: PortMapper: Reconnect Event for /Volumes/Xsan 1/31/14 3:42:01.578 AM mds[64]: ERROR: _MDSChannelXsanFetchAccessTokenForUID: _XsanFetchAccessToken failed: 35 1/31/14 3:42:01.578 AM KernelEventAgent[71]: tid 54485244 received event(s) VQ_NOTRESP (1) 1/31/14 3:42:01.578 AM fsmpm[332]: PortMapper: Requesting MDS recycle of /Volumes/Xsan 1/31/14 3:42:01.578 AM mds[64]: (Error) Message: MDSChannel RPC failure (fetchQueryResultsForContext:) [no channelAccessToken] 1/31/14 3:42:01.579 AM mds[64]: (Error) Store: {channel:0x7fb209709ef0 localPath:'/Volumes/Xsan'} MDSChannel failed -- initiating recovery 1/31/14 3:42:01.580 AM fsm[334]: Xsan FSS 'Xsan[1]': Node 10.1.226.67 [1] does not support Directory Quotas. DQ limits will not be enforced on this client. 1/31/14 3:42:01.581 AM fsm[334]: Xsan FSS 'Xsan[1]': Node 10.1.226.139 [3] does not support Directory Quotas. DQ limits will not be enforced on this client. 1/31/14 3:42:01.581 AM fsm[334]: Xsan FSS 'Xsan[1]': Node 10.1.226.61 [4] does not support Directory Quotas. DQ limits will not be enforced on this client. 1/31/14 3:42:41.686 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:41.686 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:41.719 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:41.720 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:41.721 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:41.721 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:41.729 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:41.729 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:41.754 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:41.755 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:42.480 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:42.480 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:42.923 AM fsm[334]: MDSChannelPeerRef MDSChannelPeerCreate(CFAllocatorRef, CFDictionaryRef): (os/kern) invalid argument 1/31/14 3:42:42.923 AM fsm[334]: Xsan FSS 'Xsan[1]': XsanSpotlightRpc_ChannelCreate: MDSChannelPeerCreate failed 1/31/14 3:42:43.235 AM mds[64]: (Warning) DiskStore: vsd:0x7fb20c01f600 Reindexing /Volumes/Xsan because the volume UUID (B47765A5-AEF7-4E4F-81C6-4AF9905FEAF6) is not the expected UUID (9E593104-F333-4734-8FBA-92E75B5D59B4) Then tons of errors similar to the following: ... 1/31/14 3:56:21.000 AM kernel[0]: Sandbox: mdworker(66241) deny file-write-create /Volumes/Xsan/Users/Staff/joeuser/iPhoto Library S11/.ipspot_update.sb-3f48c7b2-0842vk ... 1/31/14 4:01:32.560 AM mdworker[66185]: (Normal) Import: Using too many resources after 8640 files (wired: 0 resident: 43242 swapped: 0 regions: 2078), hit usage threshold importing /Volumes/Xsan/Users/Staff/joeuser/WFF Archive/WFF 2010 Spot/Digidesign Databases, exiting to clean up now. 1/31/14 4:01:32.643 AM mdworker[66184]: (Normal) Import: Using too many resources after 8576 files (wired: 0 resident: 35498 swapped: 0 regions: 2077), hit usage threshold importing /Volumes/Xsan/Users/Staff/joeuser/WFF Archive/WFF SPOT 08/Web stills/Web icons, exiting to clean up now. Eventually wrapping up with: 1/31/14 4:11:13.637 AM mdworker[66963]: (Normal) Import: Using too many resources after 1984 files (wired: 0 resident: 19441 swapped: 0 regions: 2072), hit usage threshold importing /Volumes/Xsan/Users/Grads/joeuser2/poster.tif, exiting to clean up now. 1/31/14 4:11:27.366 AM mdworker[66891]: (Normal) Import: Using too many resources after 2048 files (wired: 0 resident: 3588 swapped: 0 regions: 2072), hit usage threshold importing /Volumes/Xsan/Users/Undergrads/joeuser3/Adobe Media Cache/Media Cache Files/301B-CAR 48000.pek, exiting to clean up now. 1/31/14 4:13:22.449 AM fsm[334]: Xsan FSS 'Xsan[1]': _Inodelookup invalid inode [0x0] 1/31/14 4:13:22.449 AM fsm[334]: Xsan FSS 'Xsan[1]': _Inodelookup invalid inode [0x0]

aaron's picture

QLogic End-of-Life for 9000 series fiber channel switches

Today we learned that QLogic silently End-Of-Life’d the 9000 series Fiber Channel Switch product line on December 31st, 2013. It is no longer possible to purchase the switches or any of their upgrade components.

Customers who already own 9000 series products should be notified that QLogic will continue to offer support for existing installations.

Customers who’s switches are NOT currently under support should be are that QLogic does not offer any option to purchase replacement parts for any components that fail, The only way to obtain replacement parts is through an active support contract.

The 5800 series is still shipping but the writing is quite clearly on the wall. Time to snuggle up to Brocade and Cisco!!!

(Related, QLogic and Brocade recently announced a strategic partnership.)

abstractrude's picture

Mac Pros Finally Arriving in Europe Again

After almost a year of being unavalible due to regulatory complaince, the Mac Pro is now avalible in Europe again.  http://9to5mac.com/2014/01/12/apple-now-shipping-the-mac-pro-to-europe-once-again-after-eu-ban-of-old-model/

abstractrude's picture

Active Storage Re-Opens Under New Management

Active Storage seems to be back. This post was found on their support forums:

http://support.active-storage.com/entries/36393097-Active-Storage-is-Back-

Active Storage is back in business under new management. We are happy to announce that we honor warranties for installed ActiveRAID, mRAID and mVault products. We offer three-year system warranty starting from the invoice date and one-year warranty for batteries. For products with expired warranties we offer extended warranty service as well. We have large inventory of spare parts and new systems. We are excited to serve your requirement for system expansions and new installations.  

Active Storage, Inc. closed down in January 2013 and was re-opened in October 2013 as Active Storage, LLC. Please visit us at www.active-storage.com to learn more about our products, services, and technical support. 

Happy holidays!

Interesting to say the least.

mrk4's picture

ATTO HBA LUN ISSUE - AGAIN, this time with 10.9??? RESOLVED!

Forums: 

I used to have issues with ATTO 41/42ES HBAs seeing all the LUNs on our XSAN system (Qlogic 5600/Infortrend RAIDS). Replacing the problem client PCI card with an Apple 4Gb card eliminated the problem.

Since updating the XSAN to Lion 10.7.4/10.7.5, and using the latest available ATTO drivers/flash files for the 41/42ES - the problems 'had' disappeared.

Unfortunately, while rumming some pre-upgrade tests using a metadata controller on Mavericks 10.9.1, it appears the problem has reoccured. Its a real issue now as I have many connected clients running the ATTO cards, and updating the MDC OS may or may not make them stop seeing the various XSAN volumes.

I've tried flashing the ATTO firmware etc, but a test client machine I have here happily running on an ATTO 41ES and Lion 10.7.5 to our existing 10.7 MDC, when connected to the test 10.9 XSAN will not see some LUNS on either 10.7 or 10.9. Swap the HBA for an Apple, and hey presto - there they are. Grrrr!

Has anyone come across this issue - or better still got a fix (that does not involve buying Apple cards!) ?

Thanks

 

kworq's picture

Open Directory Replica on a MDC - Incorrect Search Policy

Forums: 

Im having an issue I hope someone can enlighten me on. 

I have an xsan environment with 2 metadata controllers. MDC1 is just a the master controller. MDC 2 is also a AFP re-share and is an open directory master. 

All clients and MDC’s are bound to MDC2 open directory master. 

When MDC2 needs to be rebooted all clients loose ACL’s to the xsan because the OD is offline. 

I made the MDC1 an open directory replica and that functions as expected. Unfortunately now in xsan admin MDC1 now says “Incorrect Search Policy”  because it is now bond to itself and not MDC2. 

How can I have both? Can a MDC not be a OD Replica?

vhannon's picture

Lion and Mavericks

I made a snap decision to upgrade a workstaion to 10.9 completely forgetting that XSAN would be unhappy as our MDC is on 10.7.  

Has anyone done either of the following?

Install an older version of the XSAN client on 10.9?  or

Forced an upgrade to 10.9 on an Xserve that isn't supported?

Any other creativesolutions for getting around this predicament would be great.  (I could roll the workstation back to 10.7 but I'm saving that as the worst case scenario)

Thanks.

V

Pages

Subscribe to Xsanity RSS