जाँच कैसे करें कि MBP को शटडाउन शटडाउन / पुनरारंभ से रोकना और इसे ठीक करना क्या है? [अब लॉग एंट्री के साथ]


12

और उम्मीद है कि वास्तव में अंतिम रूप से संपादित करें: माउंटेन लायन में अपग्रेड करने के बाद, यह मुद्दा तय हो गया है, उम्मीद है कि स्थायी रूप से।

अंतिम संपादन: समस्या हर समय नहीं होती है, कभी-कभी मुझे इसके होने के लिए कई दिनों तक इंतजार करना पड़ता है। इसलिए अलग-अलग परिस्थितियों (यानी सुरक्षित मोड या कुछ सॉफ़्टवेयर अक्षम) के तहत परीक्षण करना कठिन है और मैंने तय किया है कि इसे ठीक करने के लिए विभिन्न शर्तों को पूरा करने में दिन बिताने लायक नहीं है। ग्राहम पेरिन के सुझाव पुनः आरंभ / रिबूट मुद्दों के बारे में विशेष जानकारी प्राप्त करने के लिए सबसे अधिक सहायक थे, सामान्य प्रयोजन लॉग में नहीं पाए गए।

कुछ लॉग प्रविष्टियाँ नीचे संपादित करें में हैं:

मध्य 2010 15in मैकबुक प्रो, OS X 10.7.4 चल रहा है। कभी-कभी मशीन को पुनरारंभ या बंद करने की कोशिश करते समय, यह काम नहीं करेगा - स्क्रीन ग्रे हो जाती है, चरखा दिखाता है, लेकिन मशीन पावर डाउन नहीं करती है इसलिए कई मिनट बाद मुझे पावर दबाकर मशीन को बंद करना पड़ता है बटन।

यह हर बार नहीं होता है, और मैं समस्या के साथ सत्र के दौरान उपयोग किए गए किसी भी सॉफ़्टवेयर से संबंधित नहीं हो सकता। वास्तव में, इसका परीक्षण करते समय, कभी-कभी ऐसा होता है जब मैं इसे शुरू करने के तुरंत बाद मशीन को बंद करने की कोशिश करता हूं।

कैसे जाँच करें कि किस तरह से शटडाउन शटडाउन / पुनरारंभ को रोका जा रहा है? मुझे लगता है कि मुझे कुछ लॉग फ़ाइलों में देखना है, लेकिन मुझे यकीन नहीं है कि कौन से और क्या देखना है।

संपादित करें: ग्राहम पेरिन द्वारा सुझाई गई क्रिया में वर्बोज़ स्टार्ट / शटडाउन सेटिंग जोड़ा गया, और अंततः मशीन रिबूट पर अटक गई। मैंने स्क्रीन पर कुछ वर्बोज़ प्रविष्टियाँ देखीं और रिबूट करने के बाद उन्हें /var/log/launchd-shutdown.log में पाया। ऐसा प्रतीत होता है कि WindowServer का इससे कुछ लेना-देना हो सकता है। नीचे पहले 3 कॉलम हटाए जाने के साथ उस लॉग फ़ाइल का अंत है (पहले में कुछ बढ़ते हुए पूर्णांक संख्याएं थीं, दूसरे में "1" की प्रविष्टियां थीं और तीसरा - "com.apple.launchd"):

234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   Job has not died after being killed 2 seconds ago. Simulating exit.
234 com.apple.WindowServer   Dispatching kevent callback.
234 com.apple.WindowServer   EVFILT_PROC event for job.
1 com.apple.launchd         KEVENT[0]: udata = 0x107827a90 data = 0x0 ident = 234 filter = EVFILT_PROC flags= 0x0 fflags = NOTE_EXIT
234 com.apple.WindowServer   Reaping
234 com.apple.WindowServer   Simulated exit: <rdar://problem/9359725>
234 com.apple.WindowServer   Exited 22.016701 seconds after the first signal was sent
0 com.apple.WindowServer     Exited while shutdown in progress. Processes remaining: 0/0
0 com.apple.WindowServer   Job was last to exit during shutdown of: System.
0 com.apple.WindowServer    Total rusage: utime 0.000000 stime 0.000000 maxrss 0 ixrss 0 idrss 0 isrss 0 minflt 0 majflt 0 nswap 0 inblock 0 oublock 0 msgsnd 0 msgrcv 0 nsignals 0 nvcsw 0 nivcsw 0
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver.active
0 com.apple.WindowServer  Mach service deleted: com.apple.windowserver.active
0 com.apple.WindowServer  Closing receive right for com.apple.windowserver
0 com.apple.WindowServer   Mach service deleted: com.apple.windowserver
0 com.apple.WindowServer    Removed
1 com.apple.launchd      System: No submanagers left.
1 com.apple.launchd    System: Removing.
1 com.apple.launchd   System: Removing job manager.
1 com.apple.launchd    System: Userspace shutdown finished at: Wed Aug  1 08:53:12 2012
1 com.apple.launchd   System: Userspace shutdown took approximately 22 seconds.
1 com.apple.launchd   VM statistics (now - orig): Free: 28472 Active: -21833 Inactive: -1038 Reactivations: 0 PageIns: 25 PageOuts: 0 Faults: 1654 COW-Faults: 335 Purgeable: -849 Purges: 0
1 com.apple.launchd   System: Stray process at shutdown: PID 234 PPID 1 PGID 234 WindowServer
1 com.apple.launchd       System: About to call: reboot(RB_HALT).

किसी भी सामान्य रूप से उपयोग किए जाने वाले डिस्क को कनेक्ट करें, किसी भी सामान्य रूप से उपयोग किए जाने वाले फ़ाइल सर्वर कनेक्शन बनाएं, फिर कृपया mountकमांड चलाएं । अपने प्रश्न में परिणाम को शामिल करने से चीजों को कम करने में मदद मिल सकती है।
ग्राहम पेरिन

सामान्य रूप से उपयोग किए जाने वाले डिस्क या फ़ाइल सर्वर कनेक्शन नहीं हैं, मैं प्रति माह कई बार यूएसबी ड्राइव को जोड़ रहा हूं, लेकिन मेरे पास अभी प्रयास करने के लिए नहीं है। मैंने बिना किसी डिस्क से जुड़े 'माउंट' चलाया, लेकिन कुछ भी गड़बड़ नहीं है।
ल्यूपिनचो

कृपया, लिटिल स्निच का कौन सा संस्करण? क्या समस्या सुरक्षित बूट के साथ प्रजनन योग्य है, या लिटिल स्निच के बिना?
ग्राहम पेरिन

नवीनतम स्थिर LS (2.5.3), संस्करण 3 का पूर्वावलोकन नहीं। लेकिन यह पिछले 1-2 संस्करणों के साथ भी हो रहा था। मैं एलएस या सुरक्षित मोड के बिना इसका यथोचित परीक्षण नहीं कर सकता, क्योंकि यह हर समय नहीं होता है, कभी-कभी ऐसा होने में कई दिन लग जाते हैं और मैं मशीन को उस तरह से नहीं चला सकता जैसे कि समय की विस्तारित अवधि के लिए। मुझे लगता है, मैं अभी इसके लिए जीवित रहूंगा, और माउंटेन लायन में अपग्रेड करूंगा और देखूंगा कि क्या होता है। लेकिन आपके सुझाव सबसे अधिक उपयोगी और विशिष्ट थे, इस प्रकार आपको इनाम मिलता है।
lupincho

धन्यवाद! ओएस को अपग्रेड करने की आपकी योजना के आधार पर, मैंने अपने उत्तर में एक खंड जोड़ा। अब सबसे छोटा उत्तर यह है कि 10.7.4 की तुलना में, 10.8 दोनों (ए) के लिए बल की आवश्यकता कम होनी चाहिए; और (बी) बल के मामले में निदान करना आसान है।
ग्राहम पेरिन

जवाबों:


6

अन्य उत्तरों को लागू करना ...


पुनरारंभ या बंद करने के दौरान क्रिया मोड का निरीक्षण करें

मैक ओएस एक्स: एकल-उपयोगकर्ता या वर्बोज़ मोड में कैसे शुरू करें

- अगर आप वर्बोज़ मोड में शुरू करते हैं, तो फिर से शुरू या बंद करें, इसी तरह वर्बोज़ होगा।

संकेत: यदि क्रिया मोड में चीजें एक निश्चित बिंदु से आगे नहीं बढ़ पाती हैं, तो या तो पांच मिनट पहले अनुमति दें:

  • पुनः आरंभ करने के लिए मजबूर करना (कमांड-कंट्रोल-पॉवर); या
  • एक बंद करने के लिए मजबूर (प्रेस और कुंजी दबाए रखें)।

यदि एक मजबूर पुनरारंभ सफल नहीं होता है, तो समस्या के कारण के लिए एक और सुराग हो सकता है।

एक संबंधित प्रश्न, यद्यपि समस्या-उन्मुख नहीं: क्या कोई भी शटडाउन संदेश की व्याख्या कर सकता है?

यहाँ समस्या-उन्मुख मामले को ल्यूपिनचो के लिए हल करना आसान होना चाहिए। बहुत कम चाय छोड़ता है।

कमांड-वी कुंजी के बिना क्रिया मोड में शुरू करने के लिए

एक वरीयता NVRAM में संग्रहीत किया जा सकता है। टर्मिनल में निम्नलिखित कमांड दर्ज करें, और अपना व्यवस्थापक पासवर्ड दर्ज करने के लिए तैयार रहें:

sudo nvram boot-args="-v"

सिस्टम की अगली शुरुआत क्रिया होगी।


sysdiagnose

टर्मिनल में प्रत्येक पुनरारंभ या बंद करने से पहले:

sudo sysdiagnose

यह समय लेने वाला है, लेकिन आपको सभी रनों के परिणामों की जांच करने की आवश्यकता नहीं है। अगर कोई समस्या आती है तो ही ध्यान दें।

ल्यूपिनचो जैसे मामले के लिए:

  • रन ऑफ़ रीस्टार्ट या बंद होने से पहलेsysdiagnose समस्या का पता चल सकता है
  • sysdiagnose का अंतिम परिणाम ब्याज की एक मजबूर पुनरारंभ या बंद होने के बाद हो सकता है ।

अधिक विशेष रूप से: यदि एक sysdiagnoseनिश्चित बिंदु से आगे बढ़ने में विफल रहता है, तो उस बिंदु को जानने से अंतर्निहित समस्या की भावना हासिल करने में मदद मिल सकती है।

रन के दौरान आप निम्नलिखित कुंजी संयोजन का उपयोग कर सकते हैं, बार-बार, यह देखने के लिए कि क्या चीजें प्रगति कर रही हैं:

  • नियंत्रण टी

दिनचर्या के allmemoryहिस्से के लिए sysdiagnose, एप्पल के दो मिनट का अनुमान बेतहाशा गलत हो सकता है। धैर्य रखें।

यदि आपको संदेह है कि sysdiagnoseएक निश्चित बिंदु से आगे बढ़ने में विफल रहता है, तो कुंजी:

  • Control-C

यदि कंट्रोल-सी का बार-बार उपयोग गर्भपात करने में विफल रहता है sysdiagnose, तो (माउंटेन लायन के साथ मेरे अनुभव में) यह लगभग तय है कि ऑपरेटिंग सिस्टम को पुनरारंभ या बंद करने का प्रयास विफल हो जाएगा।


शटडाउन की निगरानी

खोजक में, जाने के लिए:

/private/var/log/shutdown_monitor.log

यह फ़ाइल आम तौर पर खाली होती है, लेकिन इसमें समस्याग्रस्त शटडाउन के बाद रुचि के आइटम हो सकते हैं। (मुझे इस क्षेत्र में बहुत कम अनुभव है।)

यदि शटडाउन में केवल आवारा प्रक्रिया WindowServer है

शटडाउन में आवारा प्रक्रियाओं का होना असामान्य नहीं है। एक आवारा समस्या तभी हो सकती है जब उसे मार न दिया जाए।

यदि आपको संदेह है कि WindowServer मारा नहीं गया है, और यह कि यह विशेष आवारा शटडाउन विफलता में योगदान देता है: अपने आप से पूछें कि क्या कोई तृतीय पक्ष सॉफ़्टवेयर WindowServer प्रक्रिया का गैर-मानक उपयोग करता है।

माउंटेन लायन पर WindowServer के एक GrabFS दृश्य का त्वरित रूप, दो डिस्प्ले के साथ:

यहाँ छवि विवरण दर्ज करें

यदि शेर भी ऐसा ही है, तो मेरी यह भावना है कि शटडाउन विफल होने का कारण WindowServer से परे है।


प्रक्षेपण के परिणामों पर आधारित अनुमान

जब भी मशीन सामान्य रूप से चल रही है, तो निम्न कमांड का क्या जवाब है?

sudo launchctl list | grep  --invert-match com.apple

आश्चर्य है कि क्या कोई गैर-Apple सॉफ़्टवेयर समस्या के लिए योगदान देता है। एंटी-वायरस, एंटी-मैलवेयर सॉफ़्टवेयर?


लायन से माउंटेन लायन में अपग्रेड के बाद

के लिए लक्ष्य:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log

ऐसा लगता है कि डिफ़ॉल्ट एक लॉग प्रति शट डाउन है, जिसमें अधिकतम दो हैं इसलिए यह भी है:

/private/var/log/com.apple.launchd/launchd-shutdown.system.log.1

किसी भी मजबूर पुनरारंभ या जबरन बंद करने के बाद, आप दोनों में से सबसे हाल ही की एक कॉपी सेट करना चुन सकते हैं । यदि किसी एक से अधिक अवसर पर बल की आवश्यकता होती है, तो आप फ़ाइलों की तुलना करके देख सकते हैं कि क्या एक पैटर्न उभरता है।

आम तौर पर

तीसरे पक्ष के सॉफ़्टवेयर के साथ किसी समस्या की संभावना से इंकार न करें, यहां तक ​​कि गुणवत्ता भी जारी करें। लिटिल स्निक अच्छी तरह से लिखा और व्यापक रूप से सम्मानित किया जा सकता है लेकिन:

  • जब इस तरह की समस्या के रूप में समस्याओं का विस्तार हो जाता है या बहुत अधिक अस्पष्ट हो जाता है, तो कोई भी गैर-Apple कर्नेल एक्सटेंशन ध्यान देने योग्य है।

मैंने ओएस एक्स 10.8 के बिल्ड 12 ए 269 का परीक्षण किया था, इसे रिलीज़ होने से पहले लगभग दो सप्ताह तक, विशेष परिस्थितियों में कठिन परिस्थितियों में व्यवहार को बंद करने पर ध्यान दिया । जब तक मैंने WWDC 2012 के किसी भी वीडियो को नहीं देखा है, मुझे इस बात का आभास नहीं है कि Apple ने सभी कठिन परिस्थितियों में बल की आवश्यकता को रोकने के लिए बहुत मेहनत की है।

डेविड डेलमोंटे के उत्तर पर निर्माण

कम से कम माउंटेन लायन पर, मुझे लिटिल स्निच 3.0 प्रिव्यू 2 (3857) का लोड बहुत पहले दिखाई देता है - शटडाउन लॉगिंग शुरू होने से पहले । यदि इस KEXT से संबंधित चीजें शटडाउन समय के आसपास समान रूप से देर से होती हैं , तो शायद डिस्क पर सामान्य लॉग फ़ाइलों में कोई समस्या स्पष्ट नहीं होगी।


यदि आपको कभी भी समस्या का कारण पता चलता है - तो सिंह या माउंटेन लायन के साथ - मुझे यह जानकर खुशी होगी।

इस बीच, इनाम के लिए बड़े धन्यवाद के साथ, एक समापन विचार:

kextstat -l | grep --invert-match com.apple

1
धन्यवाद, nvram कमांड के साथ वर्बोज़ मोड को सक्षम किया। हालाँकि, पुनरारंभ करने के बाद भी कोई shutdown_monitor.log नहीं है। फ़ाइलें लॉन्च-शटडाउन.लॉग और लॉन्चड-शटडाउन.लॉग .1 हैं (ऐसा लगता है कि इनमें से केवल वर्तमान और 1 पिछले को दूसरे लॉग के विपरीत रखा गया है), लेकिन ये पहले भी थे और मैंने इन्हें पहले देखा था। मैं वर्बोज़ मोड शटडाउन संदेशों की जाँच करूंगा, उम्मीद है कि मैं देख सकता था कि शटडाउन / पुनरारंभ कहाँ अटक गया है।
ल्यूपिनचो

यदि कोई समस्या पुनरावृत्ति होती है, तो एक फोटो या दो क्रिया करें। फ़ोकस आदि के बारे में बहुत अधिक चिंता न करें, मैं कुछ धब्बा के साथ मुख्य बिंदुओं को भी पहचानूंगा। मेरे पास इस बारे में एक कूबड़ है कि आपके मामले में क्या गलत है, sysdiagnoseइस उत्तर का नया हिस्सा सबसे अधिक प्रासंगिक हो सकता है।
ग्राहम पेरिन

साइड नोट: यहां माउंटेन लायन के /private/var/log/kernel-shutdown.logसाथ (जानकारी के लिए जो मेरे लिए उपयोगी है) लेकिन नहीं /private/var/log/launchd-shutdown.log
ग्राहम पेरिन

'Sysdiagnose' संकेत के लिए धन्यवाद, बस इसे चलाएं, ठीक हो गया, इसे फिर से कोशिश करेंगे। जैसा कि आपने कहा, इसमें कुछ समय लगता है, अन्यथा मैं इसे हर बार चलाने के लिए लॉगआउट हुक में डाल सकता था।
ल्यूपिनचो

स्वचालन आकर्षक है, लेकिन मुझे sysdiagnoseलॉगआउट आइटम बनाने से बचना चाहिए । एक किनारे के मामले में, स्वचालन एक कठिन स्थिति को बदतर बना सकता है।
ग्राहम पेरिन

2

एप्लिकेशन पर जाएं -> उपयोगिताएँ, और कंसोल खोलें

System.log फ़ाइल पर एक नज़र डालें, आप वहां कुछ खोजने में सक्षम हो सकते हैं।


मुझे वहाँ कुछ भी अजीब नहीं दिख रहा है।
ल्यूपिनचो

रिवाल्वर से अच्छा जवाब। +1। क्या आप अपने प्रश्न को कॉपी और पेस्ट कर सकते हैं, आपके द्वारा शटडाउन का अनुरोध करने के बाद आपके द्वारा देखी जाने वाली सिस्टम.लॉग प्रविष्टियाँ - और शायद कुछ मिनट पहले .. उन्हें अपने मूल प्रश्न में चिपकाएँ ..
डेविड डेलमोनेट

मैं अतीत में कई बार system.log पर गया और सुंदर शटडाउन की तुलना में कुछ भी असामान्य नहीं मिला। ऐसा होने पर अगली बार का इंतजार करेंगे और दोबारा लॉग की जांच करेंगे मुझे स्पष्ट करना चाहिए कि मैं सामान्य उद्देश्य लॉग्स से अवगत हूं, मुझे अपने मूल पोस्ट में अपडेट करना होगा।
lupincho

2

pmset -g assertions बिजली के जोर का सारांश मिलता है:

$ pmset -g assertions
Assertion status system-wide:
   PreventUserIdleDisplaySleep             0
   CPUBoundAssertion                       0
   DisableInflow                           0
   ChargeInhibit                           0
   PreventSystemSleep                      0
   PreventUserIdleSystemSleep              1
   ExternalMedia                           1
   DisableLowPowerBatteryWarnings          0
   EnableIdleSleep                         1
   NoRealPowerSources_debug                0
   UserIsActive                            0
   ApplePushServiceTask                    0

Listed by owning process:
  pid 153: [0x00000099012c023b] PreventUserIdleSystemSleep named: "com.apple.audio.'AppleUSBAudioEngine:Apple Inc.:Display Audio:15261930:2,1'.noidlesleep" 
  pid 19: [0x00000013012c0235] ExternalMedia named: "com.apple.powermanagement.externalmediamounted" 

आप किसी प्रक्रिया का पथ देख सकते हैं ps up $pid:

$ ps up 153
USER          PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
_coreaudiod   153   0.0  0.2  2475000   6740   ??  Ss   Fri05PM  12:17.71 /usr/sbin/coreaudiod

मैं इसे चलाता हूं और कुछ नहीं दिखाता। समस्या यह है कि मैं शटडाउन / पुनरारंभ करने के बाद मैं कोई कमांड नहीं चला सकता। यह समस्या हमेशा प्रकट नहीं होती है, इसलिए मुझे इसे बार-बार जांचना होगा, या किसी फ़ाइल में जानकारी सहेजने के लिए एक स्क्रिप्ट लिखना होगा, ताकि समस्याग्रस्त शटडाउन / पुनरारंभ होने के बाद मैं उस फ़ाइल पर वापस जा सकूँ और देख सकूँ कि कुछ भी दिखाई दिया । लेकिन यह एक अच्छी शुरुआत की तरह लगता है, बहुत बहुत धन्यवाद!
lupincho

1

मैं इस समस्या का इस्तेमाल किया है और एक तय है कि मेरे लिए काम किया लगता है। हालांकि मैं सीधे आपके सवाल का जवाब नहीं दे रहा हूं (कैसे जांच करें कि समस्या क्या है), यह एक फिक्स है जो शॉट के लायक हो सकता है:

  1. "Macintosh HD> लाइब्रेरी" पर नेविगेट करें
  2. "जावा" नामक फ़ोल्डर को हटाएं
  3. कचरा खाली करें
  4. बंद करना
  5. एक बार जब आप जावा-संबंधी कुछ भी चलाते हैं, तो आपको जावा को फिर से स्थापित करने के लिए प्रेरित किया जाएगा।

उसके बाद, शटडाउन समय में सुधार होना चाहिए। नोट: मैं अभी भी सिस्टम बंद होने के तुरंत बाद शटडाउन ले रहा हूं, इसलिए जब आप चरणों का पालन करते हैं और परीक्षण करना चाहते हैं, तो सिस्टम बंद होने से पहले कुछ मिनट प्रतीक्षा करें।


यह तो दिलचस्प है; ऐसा किया, चलो देखते हैं क्या होता है। मुद्दा यह है कि यह हर बार नहीं होता है, इसलिए सत्यापित करने का एकमात्र तरीका कई दिनों तक इंतजार करना है और यदि यह फिर से नहीं होता है, तो इसका मतलब यह हो सकता है कि यह तय हो गया है।
ल्यूपिनचो

यह काम नहीं किया, बस मशीन को बंद करने में समस्या हुई।
ल्यूपिनचो

1
  1. क्या आपके पास कोई परिधीय उपकरण जुड़ा हुआ है (यूएसबी, एफडब्ल्यू, आदि)?

यदि हां, तो सब कुछ डिस्कनेक्ट करना दिलचस्प होगा और देखें कि क्या समस्या मौजूद है।

  1. क्या आपने अनुमतियों की मरम्मत, और फ़ाइल अखंडता की जाँच करने की कोशिश की है?

आशा है कि ये मदद


मैंने मरम्मत की अनुमति दी। कोई पेरीफेरस नहीं, एक ईथरनेट केबल भी नहीं। उस जानकारी को प्रश्न में जोड़ देगा।
ल्यूपिनचो

पेरिफेरल - इस बात पर विचार करने के लिए हमेशा अच्छा होता है (जब ल्यूपचो के प्रश्न के रूप में) I / O के साथ किसी मुद्दे की गंध हो। अनुमतियाँ - IMHO ओएस के एक शट डाउन को रोकने की संभावना नहीं है। विघटन - संभव है, लेकिन मेरे लिए इसके मौजूदा रूप में सवाल सॉफ्टवेयर के साथ एक समस्या का अधिक बू आ रही है। (साइड नोट, अखंडता पर: मैं फ्री या ओपन सोर्स सॉफ्टवेयर का उपयोग कर सकता हूं। मैं मैक हार्डवेयर के साथ डिस्क के हर ब्लॉक की अखंडता को सत्यापित करने के लिए उपयोग कर सकता हूं जहां कोर स्टोरेज का उपयोग किया जाता है? - इस समय वहां बहुत अधिक टेक्नोब्लेबल है, अंततः इसे कुछ के लिए संक्षेपण करना चाहिए। सरल।)
ग्राहम पेरिन

1

कुछ और विचार:

  1. एक अन्य उपयोगकर्ता खाता बनाएँ। केवल इस परीक्षण खाते के रूप में लॉग इन करें। यदि आपको समस्या नहीं है, तो यह आपके उपयोगकर्ता सॉफ़्टवेयर में कुछ होने की संभावना है। यदि आपके पास समस्या है, तो यह संभव है कि यह हार्डवेयर हो सकता है।

  2. बैटरी पावर का उपयोग करके समस्या को फिर से बनाने की कोशिश करें।

  3. Apple के सिस्टम प्रबंधन नियंत्रक के चरणों का पालन करें -

सिस्टम मैनेजमेंट कंट्रोलर (एसएमसी) को रीसेट करना एसएमसी को मैक पोर्टेबल्स पर एक बैटरी के साथ रीसेट करना जिसे आप निकाल सकते हैं

कम्प्यूटर बंद कीजिए। यदि यह जुड़ा हुआ है, तो कंप्यूटर से मैगसेफ़ पावर एडाप्टर को डिस्कनेक्ट करें। बैटरी निकालें। 5 सेकंड के लिए पावर बटन दबाएं और दबाए रखें। पावर बटन छोड़ें। बैटरी और MagSafe पावर एडाप्टर को फिर से कनेक्ट करें। कंप्यूटर चालू करने के लिए पावर बटन दबाएं।


अपने विचार के लिए मुख्य रूप से वोट दिया (1)। विचार (2) के लिए, वर्तमान में वर्णित लक्षणों के साथ, व्यक्तिगत रूप से मुझे अकेले बैटरी पावर के साथ किसी भी अंतर पर संदेह नहीं होगा। हालांकि लूपिनचो जैसी समस्याएं प्रत्यक्ष पहुंच के बिना निदान के लिए आश्चर्यजनक रूप से कठिन हैं ... इसलिए यह एक बुरा विचार नहीं है। आइडिया (3), एक रीसेट द्वारा हल की गई समस्याएं (मेरे लिए) अत्यंत दुर्लभ हैं ... लेकिन फिर भी यह एक बुरा विचार नहीं है - यह प्रदर्शन करने के लिए त्वरित और सरल है, इसलिए, मेरे वोट का लाभ उठाएं।
ग्राहम पेरिन

1

मुझे पता ही नहीं चला कि आपको लिटिल स्निक चल रहा है। मैं सिर्फ एक दोस्त के लिए इसी तरह के मुद्दे को हल करता हूं, एलएस को हटाकर। मेरा सुझाव है कि आप कोशिश करें। ठीक से निकालने के लिए, LS इंस्टॉलर को फिर से डाउनलोड करें। इंस्टॉलर चलाएं, लेकिन स्थापना रद्द करें चुनें।

मैं उत्सुक हूँ कि आप इस ऐप का उपयोग क्यों करना चाहते हैं ..



कृपया: क्या आपके दोस्त के कंप्यूटर ने शेर, या माउंटेन शेर को चलाया? लिटिल स्निच के किस संस्करण की स्थापना रद्द की गई थी?
ग्राहम पेरिन

1
वह शेर था। मैं LS संस्करण नहीं जानता .. क्षमा करें।
डेविड डेलमोनेट

1
इस बात का कोई प्रमाण नहीं है कि एलएस ऐसा कर रहा है और दुर्भाग्य से, क्योंकि समस्या हर बार नहीं होती है, इसलिए एलएस हटाए गए परीक्षण के साथ कई दिनों तक ले जाएगा जिसके दौरान मैं एलएस नहीं खो सकता हूं। एलएस को चलाने के कारण के रूप में: घर पर बहुत सारे प्रोग्राम फ़ोनिंग हैं और आउटगोइंग ट्रैफ़िक के लिए यह नियंत्रण का एक और स्तर है। जब मैं आधिकारिक तौर पर जारी किया जाता है तो मैं संस्करण 3 में अपग्रेड करने के लिए आखिरकार क्या करूंगा।
ल्यूपिनचो

समस्या निवारण उद्देश्यों के लिए, लिटिल स्निक को कम से कम दो कारणों से अन्य थर्ड पार्टी KEXT से अलग तरीके से व्यवहार किया जा सकता है: (i) इसके लोड की इयरनेस, और (ii) सिस्टम डोमेन में इसका प्लेसमेंट /System/Library/Extensions। डेविड को श्रेय देने के साथ मैंने अपने उत्तर में एक खंड जोड़ा।
ग्राहम पेरिन

0

मेरी प्रेमिका ने केवल पैर को खींचकर और कूड़ेदान को खाली करके कचरे को हटाकर समानताएं के लिए निर्देशिकाओं को हटा दिया था। हालाँकि, मुझे लाइब्रेरी फ़ोल्डर के भीतर फिर से समानताएं मिलीं, और इसे ठीक से अनइंस्टॉल करने के लिए एक शेल स्क्रिप्ट (.sh फ़ाइल) थी। इससे हमारी लंबी बूट समस्याओं का समाधान और समाधान हुआ।

मैं इसका उल्लेख करता हूं क्योंकि समानताएं कई धीमी बूटियों का एक ज्ञात कारण है और ऐसा प्रतीत होता है कि उनकी वेबसाइट को इंगित करना आसान नहीं है।

हैप्पी ट्रेल्स, आशा है कि यह किसी की मदद करता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.