วิธีการตรวจสอบว่าทำไม Systemd เข้าสู่โหมดฉุกเฉิน

คอมพิวเตอร์เดสก์ท็อปของฉันที่ใช้ Debian Jessie เริ่มวางลงในเชลล์โหมดฉุกเฉินทุกครั้งที่บูตเครื่อง หน้าจอบอกว่าใช้journalctl -xbเพื่อค้นหาสาเหตุและเพื่อใช้systemctl defaultในการบูทต่อไป เมื่อฉันดำเนินsystemctl defaultการระบบจะยังคงบู๊ตและหลังจากผ่านไปสองสามสัปดาห์ในการใช้ระบบก็ไม่มีอะไรผิดปกติ

เมื่อมองผ่านไปjournalctl -xbไม่มีสิ่งใดโดดเด่นในฐานะเหตุผลในการทิ้งกระสุนฉุกเฉิน มีวิธีที่ง่ายต่อการตรวจสอบว่าเหตุผลที่ตัดสินใจที่จะเข้าสู่โหมดฉุกเฉิน? มีการตั้งค่าสถานะอื่น ๆ หรือตัวเลือกการเริ่มระบบที่จะทำให้ชัดเจนว่าปัญหาอยู่ที่ใด

debian systemd systemd-journald

— jordanm
แหล่งที่มา

ควรปรากฏให้เห็นในวารสาร แต่ด้วยข้อมูลที่ จำกัด ที่คุณให้ไว้ไม่มีทางที่จะแนะนำคุณได้ คุณมีสำเนาของjournalctl -xb มันเมื่อมันเกิดขึ้น?

— Julie Pelletier

Boot ใน verbose โหมดเข้าสู่ระบบsystemd.log_level=debug systemd.log_target=kmsg log_buf_len=1Mเพื่อดูรายละเอียดระดับนิติเวช ...

— jasonwryan

บันทึกที่มีอยู่ควรให้เหตุผลกับคุณอยู่แล้ว มีหลายเหตุผลที่ทำให้เดายากมาก

— Giacomo Catenazzi

ฉันมีปัญหาเดียวกันกับ Ubuntu 16.04 รับติดตั้งใช้งานซ่อมแซมระบบ Linux มากมายในช่วง 20 ปีที่ผ่านมา ไม่มีอะไรพิเศษบนหน้าจอและในครั้งนี้ไม่มีอะไรโดดเด่นในบันทึก หน้าจอบอกว่า Ctrl-D ทำการบู๊ตต่อไป แต่มันจะกลับไปที่พรอมต์เดียวกันหลังจากนั้นครู่หนึ่ง ไม่มีเงื่อนงำ น่าผิดหวังใช่ไหม

— Stéphane Gourichon

คุณได้ลองทำตามขั้นตอนทั้งหมดจากส่วน "วินิจฉัยปัญหาการบูต" ในการดีบั๊ก systemd แล้วหรือยัง

— Siosm

คำตอบ:

ความล้มเหลวควรจะแสดงเป็นสีแดง[ FAIL ]บนคอนโซล (แทน[ OK ]) โดยมีคำอธิบายของหน่วยถัดจากมัน โดยทั่วไปแล้วความล้มเหลวแรกนั้นสำคัญที่สุด ใช้ shift + pageup บนคอนโซลเพื่อเลื่อนขึ้นและดูผลลัพธ์หน้าจอสองสามอันที่ผ่านมา สิ่งนี้อาจไม่ทำงานหากมีเอาต์พุตมากเกินไป

วิธีนี้ใช้ได้แม้ว่าคุณจะไม่เห็น[ OK ]ข้อความเช่นเนื่องจากquietในบรรทัดคำสั่งเคอร์เนลที่ใช้โดย Debian ในความล้มเหลวครั้งแรก systemd สลับไปที่โหมด verbose

systemctlมิฉะนั้นคุณสามารถใช้ หากไม่มีตัวเลือกใด ๆ มันจะแสดงรายการขนาดใหญ่ของหน่วยที่รู้จักพร้อมกับความล้มเหลวที่เน้นด้วยสีแดง เพื่อแสดงให้เห็นเพียงแค่ล้มเหลวคนใช้หรือsystemctl --state=failedsystemctl --failed

emergency.targetหากคุณค้นหาผ่านไฟล์หน่วยที่มีเพียงไม่กี่วิธีที่มากสำหรับการบูตที่จะถอยกลับไป มันมักจะเมื่อ.mountหน่วยสำหรับระบบไฟล์ในท้องถิ่นล้มเหลวทำให้local-fs.targetล้มเหลว หรือเมื่อ initramfs ของคุณล้มเหลวในการเมาท์ระบบไฟล์รูทหาก initramfs ของคุณใช้ systemd

local-fs.targetOnFailure=emergency.targetมี และมันจะล้มเหลวเนื่องจากยูนิตสำหรับระบบไฟล์โลคัลถูกเพิ่มในรายการต้องของ local-fs.target โดยอัตโนมัติ (เว้นแต่มีDefaultDependencies=no)

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

— sourcejedi
แหล่งที่มา

ทุกครั้งที่ฉันเข้าสู่พรอมต์ "โหมดการบำรุงรักษา" และฉันต้องเลื่อนดู journald เพื่อหาข้อผิดพลาดเช่นกัน เนื่องจาก journalctl ใช้น้อยกว่าเป็นเพจเจอร์คุณควรจะสามารถใช้ทางลัดน้อยลงในการค้นหาของคุณ

โดยทั่วไปแล้วฉันจะพึ่งพาฟังก์ชั่นการค้นหา (/) และค้นหาสิ่งที่เทียบเท่ากับ "ข้อผิดพลาด", "คำเตือน" หรือ "ล้มเหลว" และตรวจสอบให้แน่ใจว่า -i เพื่อบังคับการค้นหาแบบตัวพิมพ์เล็กและใหญ่

การกดแป้นของฉันจึงมีแนวโน้มที่จะดูเหมือน:

-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)

ในทางเทคนิคแล้วมันไม่ใช่การค้นหาที่แม่นยำสำหรับปัญหาที่แม่นยำ แต่ฉันไม่เคยพลาดปัญหาการบู๊ตด้วยวิธีนี้

แป้นพิมพ์ลัดที่เกี่ยวข้องน้อยลงบางรายการด้านล่าง:

http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for-effective-navigation/

— madumlao
แหล่งที่มา

ฉันเชื่อว่ามันควรจะเป็นไปได้ที่จะผ่านหน้าได้อย่างรวดเร็วและมองหาข้อความสีแดง (LOG_ERR ขึ้นไป) systemdจะบันทึกข้อความสีแดงสำหรับความล้มเหลวในการเริ่มหน่วยบริการหรือที่สำคัญกว่าความล้มเหลวในการติดตั้งระบบไฟล์

— sourcejedi