Slow boot -“ งานเริ่มต้นกำลังทำงานสำหรับ dev-disk-by …”

ฉันจำไม่ได้เมื่อเกิดปัญหาขึ้น แต่เป็นไปได้เมื่อฉันย้ายอิมเมจ VMWare Ubuntu ของฉันไปยัง SSD ภายนอกเพื่อที่ฉันจะสามารถใช้ระบบปฏิบัติการกับพีซีเครื่องใดก็ได้ของฉัน ไม่มีการเชื่อมโยงหลายบน Google เกี่ยวกับปัญหา fstabแต่คนที่ปรากฏพูดคุยเกี่ยวกับ ตัวอย่างเช่นการบูตช้า - "งานเริ่มต้นทำงานสำหรับ dev-disk-by ... " คืออะไร - ฟอรั่ม

กล่าวถึงต้องลบพาร์ติชัน swap และสร้างอีกครั้ง

ฉันสามารถลองทำสิ่งนี้กับ Gparted ได้ แต่ความกังวลหลักของฉันคือการสูญเสียการตั้งค่าปัจจุบันของฉันใน Ubuntu เนื่องจากฉันไม่แน่ใจว่าจะเกิดอะไรขึ้นถ้าฉันยุ่งกับการสลับตามที่แนะนำในเธรด ใครช่วยได้บ้าง

หากคุณได้รับ "งานเริ่มต้นเริ่มต้นโดย dev-disk-by .. " ตามด้วยการหน่วงเวลา 90 วินาทีระหว่างการบู๊ตแต่ละครั้งให้ทำตามขั้นตอนต่อไปนี้:

1. ติดตั้ง gparted โดยใช้ Software Center
2. เปิด gparted และดูว่าพาร์ทิชันใดที่อูบุนตูใช้อยู่ในปัจจุบัน

3. แก้ไขไฟล์ fstab โดยใช้บรรทัดด้านล่าง

   sudo -H gedit /etc/fstab
   

4. ค้นหาอุปกรณ์ที่คุณไม่ได้ใช้อยู่ในปัจจุบัน

5. แทรก a #และช่องว่างที่จุดเริ่มต้นของบรรทัดนั้นคอมเม้นท์

6. รีเซ็ตหวังว่ามันจะเหมาะกับคุณ!

ดูเหมือนว่าปัญหานี้เกิดขึ้นเนื่องจากข้อเท็จจริงที่ว่าแม้ว่า fstab มีรายการแลกเปลี่ยน แต่จริงๆแล้วไม่มีอยู่จริง ฉันใช้ GParted เพื่อปรับขนาดพาร์ติชันและสร้าง Swap ใหม่ ฉันคัดลอก UUID ไปยังไฟล์ fstab ...

1. ตอนนี้ฉันมี swap
2. และการบูตจะลดลงไปภายในไม่กี่วินาทีเทียบกับ 90+ วินาที

ฉันมีปัญหาเดียวกันหลังจากปรับขนาดพาร์ติชันหลักของฉันบน VM ของฉันตั้งแต่gparted liveบังคับให้ฉันลบและกำหนดค่าเริ่มต้นให้สลับใหม่ ทำให้ UUID ใหม่ถูกตั้งค่าที่ไม่ตรงกับไฟล์ fstab

เพื่อหลีกเลี่ยงปัญหาใน/etc/fstabคุณสามารถอย่างใดอย่างหนึ่ง

• แทนที่ swap UUID ด้วยอันใหม่ (รันsudo blkidเพื่อค้นหา) หลังจากปรับขนาดพาร์ติชันหลัก

• หรือคอมเม้นท์ swap พาร์ติชั่นก่อน (หรือหลัง) การปรับขนาดพาร์ติชั่นหลัก

ฉันอยากจะแนะนำอดีตเพราะมันเป็นวิธีที่ระบบปฏิบัติการมีความหมายที่จะติดตั้ง

/dev/mapper/cryptswap1ในกรณีที่ผมเคยใช้แลกเปลี่ยนการเข้ารหัสและการเริ่มต้นงานดังกล่าว เพื่อแก้ปัญหาฉันยังต้องลบไฟล์/etc/crypttabนอกเหนือจากขั้นตอนที่อธิบายในคำตอบโดย William MacDonald

เมื่อปรับขนาดหรือลบพาร์ติชันด้วย gparted คุณมักจะต้องสร้างพาร์ทิชัน swap ใหม่

จากนั้นจึงจำเป็นต้องเปิดใช้งานการแลกเปลี่ยนผ่าน gparted หลังจากการสร้าง (มีคำสั่ง "เปิดใช้งานการสลับ")

นอกจากนี้คุณต้องคัดลอก UUID ใหม่ลงใน / etc / fstab เพื่อติดตั้งมิฉะนั้นตอนบู๊ต OS จะพยายามค้นหา แต่จะไร้ประโยชน์เพราะไฟล์ fstab มี UUID ที่อ้างถึงการแลกเปลี่ยนเก่า Gparted ส่งข้อมูลสำหรับ UUID แต่คุณสามารถเรียกใช้ในเทอร์มินัลได้อย่างง่ายดาย:

sudo blkid

เพื่อหามัน

ฉันมีปัญหาเดียวกันเมื่อทำการบูท

ใน/etc/fstabไฟล์ของฉันพาร์ติชันของฉันที่กำหนดเป็น/dev/sda1, /dev/sda2ฯลฯ แต่เมื่อบูตหลายครั้งปรากฏข้อความ " งานเริ่มต้นทำงานสำหรับ dev-sdx " ("x" กำหนดหน่วยหรือพาร์ทิชันที่ได้รับผลกระทบ)

เพื่อแก้ปัญหานี้ฉันเปลี่ยนค่าของ/dev/sdxUUID ของพาร์ติชัน หากต้องการดู UUID lsblk -fจากระยะขั้ว จากนั้นคัดลอก UUID ของพาร์ทิชันได้รับผลกระทบและเขียนไว้ใน/etc/fstabไฟล์เปลี่ยน/dev/sdaxดังนี้การเปลี่ยนแปลง/dev/sda1UUID=xxxxxxxxxxxxxxxxxx

มันใช้งานได้สำหรับฉันฉันหวังว่าข้อมูลนี้จะเป็นประโยชน์

การบู๊ตของฉันช้าลงเพราะฉันเปลี่ยนไดร์ฟและ UUID ไม่ตรงกัน สิ่งนี้ทำให้อูบุนตูทำการสแกนระหว่างการบู๊ต

ฉันสลับไดร์ฟบ่อย ๆ หากการติดตั้งของคุณอยู่ในสถานที่เดียวกันเสมอ (เช่นของฉัน) คุณสามารถลบ UUID และวางเส้นทางโดยตรงเพื่อป้องกันข้อผิดพลาดในการสแกนที่เกิดขึ้น ...

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0

สถานการณ์หลัก:

ตอบในรายละเอียดแล้ว ... (คุณต้องตรวจสอบ UUID ภายใต้ไฟล์เหล่านั้น)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

สถานการณ์ทางเลือก I - Udev:

สิ่งนี้อาจเกิดจากudevหากคุณมีกฎของสคริปต์ภายใต้/etc/udev/rules.d/ที่ไม่ได้หมายถึงให้รันตอนบูทหากสคริปต์ล้มเหลวมันจะทำให้ขั้นตอน fstab นั้นดำเนินต่อไปตลอดไปเพียงแก้ไขสคริปต์ของคุณเพื่อให้ตรงกับความต้องการของคุณหรือลบออก

ทางเลือกสถานการณ์ที่สอง - Crypted Dev:

พาร์ติชันที่เข้ารหัสอาจทำให้เกิดความสับสนเนื่องจากพาร์ติชันหลักมี UUID และที่แมปที่ถอดรหัสแล้วมี UUID อื่นที่แตกต่างจากพาร์ติชันหลักสำหรับพาร์ติชันเดียวที่พวกเขาจะต้องกำหนดไว้ในที่ต่าง ๆetc/crypttabและ/etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

ต้องระบุ UUID จริง etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

UUID เสมือนต้องอยู่ที่ /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

สถานการณ์ทางเลือก III - Ghost Dev:

อุปกรณ์ที่ติดตั้งเพื่อติดตั้งในเวลาบูต แต่ไม่มีอยู่ในระบบหรือถอดออกเช่นไดรฟ์ usb

ชำระเงินอุปกรณ์ที่เชื่อมต่อจริงด้วยlsblk -o name,uuid,mountpointและแก้ไข/etc/fstabเพื่อเก็บเฉพาะอุปกรณ์ที่เชื่อมต่อ หรือปล่อยอุปกรณ์ที่ไม่ได้เชื่อมต่อไว้ที่นั่น แต่ตั้งค่าให้ละเว้นอุปกรณ์เมื่อบู๊ตด้วยตัวเลือกnoautoและตั้งค่าบรรทัดเช่นนี้

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

ตรวจสอบบันทึกของระบบ

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

นอกเหนือจากการตรวจสอบ/etc/fstabหรือ/etc/crypttabตามที่กล่าวไว้ในคำตอบอื่น ๆ แล้วให้ตรวจสอบ UUID ที่มาจากพารามิเตอร์เคอร์เนล/etc/default/grubด้วย ในขณะที่ฉันสับสนมากโดยระบบที่มี cromulent สมบูรณ์แบบ/etc/fstabเท่านั้นที่จะค้นพบresume=…พารามิเตอร์เคอร์เนลในการกำหนดค่าด้วง

คุณสามารถข้ามการรอและไปที่หน้าจอเข้าสู่ระบบของคุณโดยตรงโดยใช้ ' Ctrl+ c' จากนั้นทำงานบนโซลูชัน บางครั้งสิ่งนี้จะดำเนินต่อไปตลอดกาลถ้าไม่

ฉันรู้ว่ามันเก่า แต่ฉันสะดุดกับปัญหานี้ข้อผิดพลาดเดียวกันในขณะที่โคลนการติดตั้งด้วย rsync ไม่มีข้อผิดพลาดใน fstabปัญหาได้รับการแก้ไขหลังจากอัปเดต initrdfs ด้วยมือ เพื่อบรรลุเป้าหมายนั้น

1. บูตเครื่องในการติดตั้งที่ใช้งานได้ (เครื่องมัลติบูต livecd เป็นอย่างอื่น)

2. เมาท์พาร์ติชันรูทของระบบด้วยปัญหา

3. mount dev, sys และ proc สำหรับ chroot ที่ใช้งานได้

4. chroot เป็นรูทของ filesistem

5. รัน mkinitrd

6. ออกจาก chroot และรีบูต