Thất bại ở bước EXEC spawning / bin / plymouth (kiểm tra Debian)


16

Sau khi tôi thực hiện một dist-upgradephiên bản thử nghiệm Debian (Jessie), tôi không thể khởi động được nữa. Tôi đã kết hôn tại dấu nhắc lệnh:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs

Các lỗi sau xuất hiện:

root@debian:~# journalctl -xb
debian systemd[222]: Failed at step EXEC spawning /bin/plymouth: No such file or directory

Đáng ngạc nhiên, Google không giúp đỡ và chủ đề nhỏ mà tôi thấy là dành cho Arch (ngay cả khi tôi thêm + debian trong tìm kiếm của mình) và không có ý nghĩa với tôi.

Bất kỳ con trỏ về làm thế nào để phục hồi từ này?

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x84_64 GNU/Linux

Có lẽ điều này cần phải được thay đổi để loại bỏ thử nghiệm khỏi tiêu đề, vì nó đã được "xác nhận" trên Jessie / ổn định, v.v. kể từ SystemD; (
Hvisage

Câu trả lời:


20

Tôi cũng đã có lỗi chính xác này ngày hôm nay là kết quả của một cuộc tranh luận khò khè để nâng cấp jessie.

Hệ thống không thể khởi động lại mặc dù không có lỗi từ "apt-get dist-Nâng cấp". Đầu ra lỗi cuối cùng thông qua "Tạp chí -xb" (hoặc "-xd") được liên kết với "plymouth" (một ứng dụng mà tôi chưa bao giờ nghe thấy). Nhưng hóa ra việc không khởi động lại không liên quan gì đến plymouth, mà là một sự bất thường nhỏ dưới một mục phụ trợ trong / etc / fstab: thay đổi "auto" thành "noauto" cho thiết bị cdrom (không liên quan gì đến NFS) và sau đó systemd sẽ cho phép khởi động. Đây là một dòng fstab hoạt động dưới sự khò khè và thất bại trong âm thầm cho phép khởi động lại dưới jessie.

Không có lỗi thông qua tạp chí liên quan đến fstab. Đó là những tìm kiếm trên web may mắn dẫn tôi đến giải pháp tối nghĩa này.


4
Chính xác. Lỗi plymouth lọt vào mắt tôi và tôi đã bỏ qua nguyên nhân thực sự.
youri

Vâng, trong trường hợp của tôi, nó đã noauto, nhưng một hệ thống tập tin không phải là "có" vì đĩa được thêm vào ... <add-French-tests-words> systemd hoàn toàn phải sử dụng để gắn kết hệ thống tập tin ... thực sự phải là một báo cáo lỗi chống lại systemd ... nhưng biết LP từ những kinh nghiệm trước đây về việc gắn hệ thống tập tin, nó sẽ bị bỏ qua; (Tất cả những cách tốt nhất để giải quyết các rắc rối liên quan đến hệ thống trong tương lai
Hvisage

Thay vì bình luận dòng trong fstab, hãy thêm nofailtùy chọn cho tất cả các hệ thống tệp không cần thiết. Tùy chọn này báo cho systemd bỏ qua lỗi trong quá trình mount và tiếp tục quá trình khởi động bình thường.
Marki555

11

Kết hợp các câu trả lời trước đó, vấn đề này dường như được gây ra bởi các mục không hợp lệ trong / etc / fstab.

Trong trường hợp của tôi, tôi đang chạy bên trong hộp ảo và đó là một thư mục dùng chung mà tôi đã thiết lập để tự động gắn kết khi khởi động, đó là vấn đề. Trong hai câu trả lời khác, đó là sự giải quyết cho thiết bị NFS hoặc CD-ROM là vấn đề.

Tôi sẽ đề nghị rằng để khắc phục sự cố, chỉ cần nhận xét tất cả các dòng không cần thiết trong / etc / fstab và sau đó thêm lại từng dòng một cho đến khi bạn sao chép vấn đề.

Dòng có vấn đề sau đó có thể được chẩn đoán và sửa chữa. Có thể trong quá trình nâng cấp dist, những thứ như thư mục chia sẻ Vbox, chia sẻ mạng hoặc các hệ thống tệp chuyên dụng khác không được nâng cấp chính xác.


ĐÚNG!!!!! xem bình luận của tôi trong câu trả lời khác
Hvisage

3

Tôi đã có lỗi chính xác ngày hôm nay.

Tôi đã cài đặt plymouth nhưng nó không thay đổi kết quả.

Nó được gây ra bởi một mục nhập nfs sai trong / etc / fstab. Sau khi xóa mục đó, lỗi biến mất. Tôi đoán hành vi khủng khiếp này là do hệ thống ngu ngốc.


2

Tôi xác nhận đó là một vấn đề trong fstab. Nếu bạn vào bên trong fstab và xóa dòng cuối cùng bạn đã thực hiện giống như trước và hệ thống bắt đầu. Tôi gặp sự cố tự động khi chia sẻ trong VirtualBox 5 / debian 8. Không có vấn đề gì trong Virtualbox 4 / debian 7


0

Tôi thấy đây là một chủ đề khá cũ vào thời điểm này ... nhưng tôi cũng đã gặp vấn đề này ngày hôm nay.

Tôi đã phải bình luận dòng này /etc/fstabđể ngăn hệ thống khởi động ở 'chế độ khẩn cấp':

#UUID=0x0000x0-0x00-0000-xx00-0000xxx00000 /boot           ext2    defaults        0       2
/dev/mapper/Ubuntu16043LTSVM--vg-swap_1 none            swap    sw              0       0

* (UUID cố ý bị xáo trộn)

CẬP NHẬT:

Dòng UUID /etc/fstabdường như có lỗi trong vấn đề này. Kì lạ Sau khi đọc thêm về vấn đề này trên chủ đề này, tôi vẫn không gần gũi hơn với câu trả lời dứt khoát về nguyên nhân gốc rễ, nhưng ít nhất SWAP được cấu hình ngay bây giờ.

Có ai có thể giải quyết vấn đề này hoàn toàn? hoặc tìm ra nguyên nhân gốc rễ?

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.