Xubuntu 18.04 कर्नेल को बूट होने में लंबा समय लगता है


10

17.10 से अपग्रेड करने के बाद, मैंने बूट समय का अनुभव किया है। पहले इसमें 5 मिनट से ज्यादा का समय लगता था। dmesgपता चला कि अपराधी एक गैर-मौजूद फ्लॉपी ड्राइव था, जिसे कर्नेल ने खोजने की कोशिश की।

इसे हटाने के तुरंत बाद, 5 मिनट लगभग 40 सेकंड के लिए नीचे चले गए, जो मुझे लगता है कि अपडेट से पहले अभी भी अधिक है। रनिंग dmesgफिर से दिखाता है कि फाइलसिस्टम ( पूर्ण आउटपुट ) को माउंट करने में 30 सेकंड लगते हैं , निम्न संदेश के साथ:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

मैं SSD से बूट कर रहा हूं, जिसमें दो अन्य हार्ड ड्राइव प्लग किए गए हैं, जिनमें से एक को ext4 में स्वरूपित किया गया है, लेकिन एक सिस्टम डेटा रखता है। मुझे लगता है कि यह एसएसडी है। इन 30 सेकंड के दौरान, कोई पाठ प्रदर्शित नहीं होता है, न ही छप, बस एक खाली स्क्रीन है।

अब, मैंने कहा कि यह अद्यतन से पहले धीमा लगता है, क्योंकि मेरे पास पहले से सटीक समय नहीं है, इसलिए मेरा पहला सवाल है, क्या फाइल सिस्टम को माउंट करने में 30 सेकंड लगना सामान्य है, और यदि नहीं, तो कैसे पता करें देरी के कारण क्या हो सकता है?

संपादित करें 1:

स्वैप को चालू या बंद करने का कोई प्रभाव नहीं पड़ता है

इस बीच मैंने अपने कंप्यूटर में एक और हार्ड ड्राइव भी स्थापित किया। ऐसा लगता है कि मेरे बूट समय को कुछ और 10 सेकंड तक बढ़ा दिया गया है, दूसरी पंक्ति dmesgआउटपुट में दिखाई दे रही है, ठीक 30 सेकंड की देरी से पहले।

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

संपादित करें 2:

systemd-analyze blameपरिणाम यहाँ हैं

इस बीच कई पुनरारंभ होने के बाद, dmesgऊपर दी गई लाइनों को मैंने उनके समय के अनुसार बदल दिया:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

मैं यह जानने के लिए कि क्या यह बेतरतीब ढंग से बदलता है, या एक ही रहता है (पहले एडिट में कोड ब्लॉक अतिरिक्त एचडीडी डालने के बाद पहले बूट से है) यह जानने के लिए मैं कुछ रीस्टार्ट करूँगा।

EDIT 2.5: random: crng init doneआमतौर पर एडिट 1 में दिखाए गए समय के अनुसार दिखाई देता है, शायद ही कभी एडिट 2 में। यह प्रतीत होता है ... यादृच्छिक।


क्या आप इस कमांड के आउटपुट को शामिल करने के लिए अपने प्रश्न को चला systemd-analyze blameऔर संपादित कर सकते हैं ?
विदरलो

मैंने पहले इसे चलाया है और परिणामों का योग 8-9 सेकंड से कम था, इसलिए मैंने सोचा कि यह अप्रासंगिक होगा। मैंने परिणाम जोड़ दिए हैं।
जेस वंसन

जवाबों:


18

मुझे भी यही समस्या थी। बूट संदेशों के दौरान यह कहेगा कि यह फिर से शुरू होने वाले उपकरण की प्रतीक्षा कर रहा है। जाँच करें कि /etc/initramfs-tools/conf.d/resumeक्या इसमें UUID है जैसे RESUME=some-uuiduuid को हटा दें और इसे "none" के साथ बदलें RESUME=none। उसके बाद दौड़ना sudo update-initramfs -uk allऔर जाना अच्छा होना चाहिए।


2
आखिरकार! इसने एक समस्या को हल कर दिया है जिसे मैं अनगिनत घंटों से देख रहा हूं - अब इसने मेरे बूट समय को आधा कर दिया। यह फिर से शुरू करने के बारे में उपयोगी जानकारी: askubuntu.com/questions/1057556/…
Casperrw

1
यह मेरे लिए भी काम करता है, इससे पहले लगभग 38 सेकेंड का बूट मिला और 8 सेकंड के बाद।
पाब्लो पाज़ोस

16.04 से 18.04 तक डिस्ट्रो अपग्रेड के बाद मेरे लिए यह समस्या दिखाई दी - और यह तरीका मेरे लिए 30 की देरी को भी दूर करता है।
बोनालेनफ्यूम

5

Ive को यह समस्या कई बार हुई, और मेरा समाधान सभी स्थितियों में काम करता है।

Dsmeg चलाते समय, त्रुटि इस प्रकार दिखाई देती है:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

इसका समाधान यह है:

पहले अपने fstab और blkid की तुलना करें:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

जैसा कि आप देख सकते हैं कि मेरी अदला-बदली / dev / sda7 में fstab में एक अलग UUID है, जितना कि ब्लकिड में है। यह, मेरे मामले में, एक अन्य लिनक्स द्वारा स्वैप्ट को रीपार्टिट करने के कारण और यूयूआईडी को बदलने का कारण बना। बूट विलम्ब स्वैप के नए UUID को खोजने की कोशिश कर रहे सिस्टम के कारण होता है। इसे ठीक करने के लिए, बस UUID को ब्लकिड में कॉपी करें जो fstab फाइल से मेल नहीं खाता है फिर सेव करें।

यदि बूट त्रुटि फिर से शुरू होने के बाद भी है, तो आपको अपनी initramfs.conf फ़ाइल को अतिरिक्त रूप से संपादित करने की आवश्यकता है।

इसके द्वारा करें:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

फिर या तो एक नई फ़ाइल बनाकर, या फिर से शुरू होने वाली फ़ाइल को संपादित करके, पहली पंक्ति RESUME = UUID = << स्वैप के UUID पर लिखें >>

उदाहरण के लिए, मेरा जैसा दिखता है

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

फिर अपने initramfs फ़ाइल को अपडेट करने के लिए नीचे कमांड चलाएँ।

#sudo update-initramfs -u

फिर पुनरारंभ करें। त्रुटि दूर हो जाएगी।


1

मैंने बूट समय में इसी तरह की वृद्धि का अनुभव किया, और जांच करने के बाद dmesgऔर systemd-analyze blameअपराधी दिखाई दियाrandom: crng init

समस्या शुरुआती के लिए एसएसडी से बूटिंग में पर्याप्त एन्ट्रापी नहीं लगती है। इस परिकल्पना की पुष्टि होती है क्योंकि माउस को बूट करने के दौरान एक गुच्छा बाँधने से बूट का समय लगभग 2 मिनट नीचे से घट जाता है जो पहले था।


1

बूट पर, कर्नेल रैंडम नंबर जनरेटर को इनिशियलाइज़ करने के लिए माउस मूवमेंट का इंतज़ार करता है। बूट पर कर्नेल संदेश:
sudo dmesg | less

समस्या:
kernel: random: crng init done

समाधान:
sudo apt install haveged
sudo systemctl enable haveged


0

मुझे स्वैब विभाजन को हटाने और स्वैप फ़ाइल बनाने के बाद ubuntu 19.04 पर धीमी बूट समय के साथ समस्या थी।

Dmesg का आउटपुट

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

/ आदि / fstab में कोई स्वैप नहीं। सभी माउंटेड डिस्क / uuids सही थे।

मैंने चेक किया /etc/initramfs-tools/conf.d/resumeलेकिन वह फाइल गायब थी।

मैं अभी दौड़ता हूं

sudo update-initramfs -uk all

और अब यह वास्तव में तेजी से बूट करता है।

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