Khởi động lại treo 100% - có thể trong mountall


8

CẬP NHẬT: Có vẻ như mountall đang treo bên trong thường trình emit_event (), mà nó gọi sau / được kể lại để phát ra một sự kiện cho hiệu ứng đó. Bên trong emit_event, nó gọi ply_boot_client_flush (), sau đó xây dựng mảng env, gọi upstart_emit_event (), sau đó là dbus_pending_call_block (). Và nó bị treo. Vì vậy, bất kỳ ý tưởng tại sao dbus_pending_call_block sẽ treo vô thời hạn? Plymouth bị hỏng? dbus? mới bắt đầu? Bất kỳ đề xuất cho sửa chữa hoặc chẩn đoán thêm?

Khởi động lại Ubuntu 10.04 LTS của tôi, máy AMD 64 bit bị treo 100%. Đèn truy cập ổ đĩa tắt, nhưng các phím alt-sysreq hoạt động. Phần cứng là máy tính xách tay Lenovo W700ds. Bây giờ, tôi xin lỗi trước, vì tôi rất hạn chế về thông tin về hệ thống tôi có sẵn và trong những gì tôi có thể làm với nó (vì nó sẽ không khởi động được). Tôi có thể khởi động từ CD 10.04 - sử dụng nó như một đĩa cứu hộ. Tôi có thể fsck, gắn kết và đọc và ghi vào các phân vùng của mình - chúng vẫn ổn. Tôi đã thử định dạng lại trao đổi của mình với mkswap. Tôi có 4 phân vùng ext4 trên hệ thống của mình: sda1 là /, sda2 là / usr, sda3 là / home và thứ 4 mà tôi sử dụng để lưu trữ dữ liệu / sdb1 (là toàn bộ đĩa, gắn kết tại mountpoint / hdb mà tôi đã tạo) . Ngoài ra còn có / sda4 là trao đổi. Ngay bây giờ tôi đang viết bài này từ một trình duyệt tôi đã mở trong 'phiên giải cứu' từ số 10.

Tôi sẽ rất cảm kích gợi ý / ý kiến về những gì tôi có thể làm để giúp chẩn đoán những gì đang treo, tại sao, và những gì tôi có thể làm gì để sửa chữa nó. Tôi đã thực hiện một nghiên cứu web, nhưng không tìm thấy gì mới trên các dòng này (một số báo cáo lỗi 1-1,5 năm tuổi có các triệu chứng tương tự, nhưng các bản sửa lỗi của chúng không hoạt động).

Tôi đã cài đặt 10.04 trên một đĩa mới vào khoảng đầu tháng 7, sau đó sử dụng năng khiếu để đưa mọi thứ cập nhật. Kể từ đó, tôi đã cài đặt của các gói (tôi sẽ đính kèm nhật ký dpkg bên dưới). Với sda là 750GB (/ 20GB, / usr 80GB), tôi có rất nhiều dung lượng để cài đặt các gói mà tôi 'có thể một ngày nào đó sẽ sử dụng'. Tôi tự hỏi nếu một trong những gói này tôi đã cài đặt đã làm hỏng hệ thống của tôi? Tôi đã cài đặt kernel 2.6.32-32 và khởi động lại, nhưng đã cài đặt nhiều gói hơn kể từ đó. Tôi khởi động lại máy này hiếm khi có thể - thích ngủ đông trong khi đi từ nơi này sang nơi khác. Gần đây, tôi nhận thấy một số hành vi kỳ lạ liên quan đến khử ngủ đông: khi hệ thống sẽ khử ngủ đông, nó sẽ hiển thị trình bảo vệ màn hình gnome với mật khẩu cần thiết để mở khóa - tốt, nó sẽ không nhận ra mật khẩu của tôi! Tôi đã phải thay thế F1, đăng nhập bằng root và giết trình bảo vệ màn hình. Sau đó tất cả sẽ ổn, hoặc có vẻ như vậy. Cũng thế, khi ngủ đông tôi thường thấy trong một thời gian ngắn nhấp nháy rác đầy màu sắc trên màn hình. Nó sẽ biến mất, vì vậy tôi đã không cố gắng tìm ra nguyên nhân. Một điểm có thể có liên quan khác là tôi cần sử dụng "nomodeset" trong quá trình cài đặt 10.04 và khi đưa vỏ cứu hộ từ cùng một đĩa CD đó, nếu tôi chỉ sử dụng nomodeset thì cuối cùng nó sẽ bị treo với đèn LED NumLock LED hoặc Caps Lock LED ( sự cố?), nhưng nếu tôi cũng sử dụng "noapic nolapic acpi = off" thì nó sẽ ổn thôi. Tôi đã thử các tùy chọn này với hệ thống của mình để xem liệu chúng có khắc phục được sự cố treo khởi động hay không - chúng không. Nếu tôi chỉ sử dụng nomodeset thì cuối cùng nó sẽ bị treo với đèn LED NumLock LED hoặc Caps Lock LED (sự cố?), nhưng nếu tôi cũng sử dụng "noapic nolapic acpi = off" thì nó sẽ ổn. Tôi đã thử các tùy chọn này với hệ thống của mình để xem liệu chúng có khắc phục được sự cố treo khởi động hay không - chúng không. Nếu tôi chỉ sử dụng nomodeset thì cuối cùng nó sẽ bị treo với đèn LED NumLock LED hoặc Caps Lock LED (sự cố?), nhưng nếu tôi cũng sử dụng "noapic nolapic acpi = off" thì nó sẽ ổn. Tôi đã thử các tùy chọn này với hệ thống của mình để xem liệu chúng có khắc phục được sự cố treo khởi động hay không - chúng không.

Đây là một máy tôi sử dụng cho công việc cũng như đối với gần như mọi thứ khác, vì vậy nhận được nó để khởi động lại là một TOP ưu tiên. / nhà còn nguyên, cái nào tốt. Nhưng tôi đang cố gắng hết sức để cố gắng chẩn đoán (ít khắc phục hơn) nguyên nhân gây ra lỗi treo giày này.

Tôi khởi động hệ thống và nó bắt đầu chạy tập lệnh cấu hình mountall trong /etc/init/mountall.conf. Tôi thấy đầu ra từ mountall chạy fsck - 4 dòng có nội dung: fsck từ produc-linux-ng 2.17.2 (đó là một trên mỗi phân vùng ext4). Sau đó, có thêm 4 dòng từ fsck thông báo cho người dùng rằng các phân vùng được tìm thấy là "sạch". Và đó là nó - mọi thứ chỉ dừng lại. Đèn LED hoạt động ổ đĩa tắt. Tôi có thể sử dụng các phím alt-sysreq, nhưng chúng chưa được chứng minh là hữu ích. Tôi thấy một báo cáo lỗi trong đó một người dùng đã sử dụng alt-sysreq-i để giết tiến trình và nó đã thả anh ta vào một cái vỏ. Đối với tôi, nó nói rằng nó đã giết chết các quá trình (udev và udev-Bridge và plymouth, nói rằng udev đang hồi sinh, v.v.), nhưng tôi không nhận được bất kỳ vỏ nào.

Tôi đã cố gắng xác định chính xác những gì được treo. Cuối cùng, tôi đã sửa lại /etc/init/mountall.conf. Tôi đã thêm các dòng echo và tôi đã thêm tùy chọn -v (verbose) vào bộ thực thi của mountall. Không có dòng echo sau khi thực hiện mountall được hiển thị, vì vậy điều này có thể có nghĩa là mountall đang treo. Hoặc, nó có thể không hiển thị cuối cùng của đầu ra - trong trường hợp đó mountall có thể đã thoát và một cái gì đó khác có thể bị treo. Tôi lưu ý rằng alt-sysreq-i không nói mountall bị giết. Tôi đã cố gắng thu hẹp những gì hệ thống có thể bị treo bằng cách nhận xét sda3 (/ home), trao đổi và sdb1 (/ hdb) từ fstab, nhưng nó vẫn bị treo.

Có rất nhiều thứ tôi có thể tự làm, nhưng cảm giác như tôi đang ở trên đầu mình ở đây. Ví dụ, tôi muốn lấy mã nguồn cho mountall, thêm cờ in, biên dịch lại và dán nó vào hệ thống của tôi - để thu hẹp A) nếu mountall thực sự bị treo và B) nó đang treo cái gì. NHƯNG, tôi không thể khởi động máy của mình vào một vỏ để biên dịch bên trong - và môi trường đĩa cứu hộ chỉ là 2.6.32-28 chung chung # 55 - vì vậy nó sẽ không khớp với hệ thống của tôi. Tôi muốn xóa hoặc cài đặt lại các gói, nhưng một lần nữa, tôi không thể khởi động máy của mình và làm điều này.

(tệp nhật ký dpkg của tôi là vài MB, vì vậy tôi sẽ đính kèm nó trong hộp thoại sau)

Cảm ơn, Greg


tốt, nếu bạn có thể khởi động thanh usb hoặc livecd, gắn đĩa vào đó bạn có thể chroot vào máy tính của mình và gỡ bỏ các gói. Nhưng mặt khác, bạn nói rằng đây là máy tính làm việc của bạn, nó được ưu tiên HÀNG ĐẦU. Vì vậy, so sánh thời gian tìm kiếm những gì sai với thời gian cài đặt sạch (bạn có nhà trên phân vùng riêng)?
Denwerko

Tôi sẽ lặp lại @denwerko - có thể bạn sẽ chỉ mất vài giờ để cài đặt sạch và sau đó cài đặt bất kỳ phần mềm bổ sung nào bạn cần. Lắp thẻ nhớ USB / ổ USB ngoài và sao chép nội dung của / nhà của bạn vào đó. Bạn có thể khôi phục nó sau đó. Về "tính ổn định" - nó phụ thuộc - bạn đã cài đặt gói nào và từ đâu? Cài đặt các gói từ PPA và mã biên dịch có thể gây ra nhiều bất ổn hơn so với cài đặt các gói tiêu chuẩn từ trung tâm phần mềm / trình quản lý gói synap.
fossfreedom

@greg - bạn có phần cứng nào cần cài đặt thêm trình điều khiển - ví dụ: card mạng / card đồ họa? Bạn đã thử đơn giản hóa máy tính để bàn của mình bằng cách vô hiệu hóa / rút tất cả các thẻ - chỉ để lại những điều cơ bản như đồ họa tích hợp & bàn phím có dây?
fossfreedom

@Greg nếu điều này được giải quyết tại sao câu trả lời của họ không được chấp nhận? Vui lòng làm theo các quy tắc chung cho AskUbfox và thêm câu hỏi của bạn vào câu trả lời và chấp nhận nó.
Rinzwind

Câu trả lời:


1

Denwerko: Tôi đã không làm gì với máy của mình nên đã tạo ra kết quả này. Nó khá ổn định trong Ubuntu 9.10 - chưa bao giờ có chuyện như thế này xảy ra. Tất cả các vấn đề với nguồn, biên dịch lại mọi thứ - tất cả đều là mã không gian người dùng. Tôi đã không mày mò chút nào với HĐH. Tôi cũng chưa cài đặt bất kỳ mã không gian hệ điều hành nào bên ngoài các kênh tiêu chuẩn (trình quản lý gói aptitude / synaptic, các gói gỡ lỗi thu được từ các công cụ đó). Greg ngày hôm qua

Tuy nhiên, tôi đã nhận được mã nguồn để mountall 2.15.3 và đã biên dịch nó trong môi trường cứu hộ, sau 5 lần cài đặt (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . Tôi đã thêm các bản in gỡ lỗi trong mã thông qua các cuộc gọi nih_info () và tôi đã thực hiện các sinh sản thực hiện chặn fsck thay vì không chặn. Tôi đang làm việc trên lý thuyết rằng mountall đang gặp sự cố ở đâu đó (hoặc nih, hoặc dbus hoặc plymouth ...). Tôi dường như không nhận được đầu ra đến cùng một vị trí trong mã mỗi lần chạy, nhưng dường như nó sẽ dừng lại sau khi kết thúc / dev / sda1 đến / - trong thói quen được gắn kết (). Greg ngày hôm qua

Tôi cũng đã thực hiện dpkg -r các gói thông qua chroot như bạn đề xuất và điều đó dường như hoạt động (ngoại trừ một tập lệnh deinstall muốn làm gì đó với / Proc). Tôi đã cài đặt lại rượu vang và các gói tương thích 32 bit mà nó cần (lib32nss, ia32lib, lib32v4l, v.v.) và một số gói ibus không được cài đặt trong môi trường cứu hộ (một số gói ibus và tôi không cẩn thận loại bỏ chúng) plasma-widget-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Không có điều nào trong số này ảnh hưởng đến vấn đề, vì vậy tôi đã gỡ bỏ nhiều gói hơn bây giờ tôi không cần (gói wx & gói jdk, v.v.) -không có hiệu lực

CẬP NHẬT: Có vẻ như mountall đang treo bên trong thường trình emit_event (), mà nó gọi sau / được kết nối lại để phát ra và sự kiện cho hiệu ứng đó. Bên trong emit_event, nó gọi ply_boot_client_flush (), sau đó xây dựng mảng env, gọi upstart_emit_event (), sau đó là dbus_pending_call_block (). Và nó bị treo. Vì vậy, bất kỳ ý tưởng tại sao dbus_pending_call_block sẽ treo vô thời hạn? Plymouth bị hỏng? dbus? mới bắt đầu? Bất kỳ đề xuất cho sửa chữa hoặc chẩn đoán thêm?

GIẢI PHÁP Vì vậy, có vẻ như tôi đã cài đặt cloud-init và cloud-utils bởi vì mặc dù một ngày nào đó tôi có thể muốn chơi với nó. Will, hóa ra các ốc vít khởi tạo đám mây với cấu hình ureadahead và khởi chạy khi sự kiện dbus 'gắn /' xảy ra, khiến hệ thống của tôi bị treo ngay khi nó gửi tin nhắn dbus đó, xảy ra sau khi / được gửi lại từ ro đến r / w. Tôi đã gỡ cài đặt cloud-init và cloud-utils và tất cả có vẻ ổn bây giờ. Ngoại trừ, tôi buồn ngủ và mất 24 giờ trong cuộc đời: \

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.