재부팅이 100 % 중단됨-아마도 mountall에서

업데이트 : mountall이 루틴 emit_event () 내부에 매달려있는 것처럼 보입니다.이 이벤트는 /를 다시 마운트 한 후 호출하여 해당 효과를 발생시킵니다. emit_event 내부에서 ply_boot_client_flush ()를 호출 한 다음 env 배열을 구성하고 upstart_emit_event ()를 호출 한 다음 dbus_pending_call_block ()을 호출합니다. 그리고 거기에 달려 있습니다. 그렇다면 왜 dbus_pending_call_block이 무기한 중단 될 수 있을까요? 깨진 플리머스? dbus? 건방진 녀석? 수정 또는 추가 진단에 대한 제안 사항이 있습니까?

Ubuntu 10.04 LTS를 재부팅하면 64 비트 AMD 시스템이 100 % 정지합니다. 드라이브 액세스 표시등이 꺼져 있지만 alt-sysreq 키가 작동합니다. 하드웨어는 Lenovo W700ds 노트북입니다. 사용 가능한 시스템에 대한 정보와 시스템으로 수행 할 수있는 작업 (부팅되지 않기 때문에)이 매우 제한되어 있기 때문에 미리 사과드립니다. 복구 디스크처럼 CD를 사용하여 10.04 CD에서 부팅 할 수 있습니다. 나는 파티션에 fsck, 마운트 및 읽기 및 쓰기를 할 수 있습니다. 이미 스왑을 mkswap으로 다시 포맷하려고했습니다. 내 시스템에 4 개의 ext4 파티션이 있습니다 : sda1은 /, sda2는 / usr, sda3은 / home, 그리고 네 번째는 데이터 스토리지 / sdb1에 사용합니다 (전체 디스크, 내가 만든 마운트 포인트 / hdb에 마운트) . 스왑 인 / sda4도 있습니다. 지금 나는 10에서 '구조 세션'에서 열었던 브라우저에서 이것을 쓰고 있습니다.

나는 무엇이 걸려 있는지, 왜, 그리고 그것을 고치기 위해 할 수있는 일을 진단하는 데 도움이되는 제안 / 의견에 크게 감사드립니다. 나는 이미 웹 검색을했지만이 줄을 따라 새로운 것을 발견하지 못했습니다 (유사한 증상이있는 1-1.5 세의 버그 보고서가 있지만 수정 사항이 작동하지 않았습니다).

7 월 1 일경에 새 디스크에 10.04를 설치 한 다음 적성을 사용하여 모든 것을 최신 상태로 유지했습니다. 그 이후로 LOTS를 설치하고 있습니다패키지 (아래 dpkg 로그를 첨부합니다). sda가 750GB (/ 20GB, / usr 80GB) 인 나는 '언젠가 사용할 수있는'패키지를 설치할 공간이 충분했습니다. 내가 설치 한 패키지 중 하나가 시스템을 망쳤는지 궁금합니다. 커널 2.6.32-32-generic을 설치하고 재부팅했지만 이후 더 많은 패키지를 설치했습니다. 나는이 기계를 가능한 한 드물게 재부팅합니다. 장소를 옮기는 동안 최대 절전 모드를 선호합니다. 최근에, 최대 절전 모드와 관련된 이상한 동작이 나타났습니다. 시스템이 최대 절전 모드 일 때 잠금 해제에 필요한 암호가있는 그놈 화면 보호기가 나타납니다. 글쎄, 내 암호를 인식하지 못합니다! alt-F1을 실행하고 루트로 로그인 한 다음 화면 보호기를 종료해야했습니다. 그렇다면 모든 것이 좋을 것 같습니다. 또한, 최대 절전 모드에서 화면에 화려한 쓰레기가 깜박 거리는 동안 짧은 시간 동안 자주 보게됩니다. 사라져서 원인을 찾으려고하지 않았습니다. 또 다른 관련 포인트는 10.04 설치시 "nomodeset"을 사용해야한다는 것입니다. 같은 CD에서 복구 쉘을 불러올 때 nomodeset 만 사용하면 NumLock LED 또는 Caps Lock LED가 깜박입니다 ( 충돌?), 그러나 "noapic nolapic acpi = off"도 사용하면 정상적으로 나타납니다. 부팅 중단 문제를 해결하는지 확인하기 위해 시스템에서 이러한 옵션을 사용해 보았습니다. nomodeset 만 사용하면 NumLock LED 또는 Caps Lock LED (충돌?)가 깜박이면서 중단되지만 "noapic nolapic acpi = off"도 사용하면 정상적으로 나타납니다. 부팅 중단 문제를 해결하는지 확인하기 위해 시스템에서 이러한 옵션을 사용해 보았습니다. nomodeset 만 사용하면 NumLock LED 또는 Caps Lock LED (충돌?)가 깜박이면서 중단되지만 "noapic nolapic acpi = off"도 사용하면 정상적으로 나타납니다. 부팅 중단 문제를 해결하는지 확인하기 위해 시스템에서 이러한 옵션을 사용해 보았습니다.

이것은, 내가 작업뿐만 아니라 다른 거의 모든 사용 기계 그래서 다시 부팅하도록되어지고 TOP의 우선 순위를. / home은 손상되지 않았습니다. 그러나 나는 끊임없는 부팅 의이 원인을 진단하려고 노력하면서 거의 모든 것을 끝내고 있습니다.

시스템을 부팅하면 /etc/init/mountall.conf에서 mountall 구성 스크립트 실행이 시작됩니다. fsck-4 줄을 실행하는 mountall의 출력은 다음과 같습니다. util-linux-ng 2.17.2의 fsck (ext4 파티션 당 1 개). 그런 다음 fsck에서 4 줄이 더 남아 사용자에게 파티션이 "깨끗한"것으로 알려졌습니다. 그리고 그게 다입니다. 모든 것이 멈추었습니다. 드라이브 작동 LED가 꺼집니다. alt-sysreq 키를 사용할 수 있지만 지금까지 유용한 것으로 입증되지 않았습니다. 한 사용자가 alt-sysreq-i를 사용하여 프로세스를 종료하고 셸에 넣은 버그 보고서를 보았습니다. 나를 위해, 그것은 프로세스 (udev와 udev-bridge와 plymouth를 죽였다는 udev 등을 말함)를 죽 였지만 쉘을 얻지 못했습니다.

나는 정확히 무엇이 걸려 있는지 확인하려고 노력했습니다. 이를 위해 /etc/init/mountall.conf를 다루었습니다. 에코 라인을 추가했으며 mountall의 exec에 -v (verbose) 옵션을 추가했습니다. mountall의 실행 후 에코 라인이 표시되지 않으므로 mountall이 중단되었음을 의미 할 수 있습니다. 또는 출력의 마지막을 표시하지 않을 수 있습니다.이 경우 mountall이 종료되고 다른 것이 걸려있을 수 있습니다. alt-sysreq-i는 mountall이 종료되었다고 말하지 않습니다. fstab에서 sda3 (/ home), swap 및 sdb1 (/ hdb)을 주석 처리하여 시스템이 멈추는 것을 좁히려 고했지만 여전히 정지합니다.

내가 할 수있는 일이 많지만 여기에 내 머리가있는 것 같은 느낌이 든다. 예를 들어 mountall의 소스 코드를 얻고, 인쇄 된 플래그를 추가하고, 시스템에 다시 컴파일하고 붙여 넣습니다-mountall이 실제로 매달려있는 경우 A)를 좁히고 B) 매달려있는 것을 좁히고 싶습니다. 그러나 내 컴퓨터를 컴파일 할 쉘로 부팅 할 수 없으며 복구 디스크 환경은 2.6.32-28-generic # 55이므로 시스템과 일치하지 않습니다. 패키지를 제거하거나 다시 설치하고 싶지만 컴퓨터를 부팅하여이 작업을 수행 할 수 없습니다.

(내 dpkg 로그 파일은 몇 MB이므로 다음 대화 상자에 첨부합니다)

고마워, 그렉

Denwerko :이 결과를 가져와야하는 컴퓨터에는 아무 작업도하지 않았습니다. 우분투 9.10에서는 꽤 안정적이었습니다. 이런 일은 없었습니다. 소스를 다듬고 재 컴파일하는 것은 모두 사용자 공간 코드였습니다. 나는 OS를 전혀 고민하지 않았다. 표준 채널 (적성 / 시냅스 패키지 관리자, 해당 도구를 통해 얻은 deb 패키지) 외부에 OS 공간 코드를 설치하지 않았습니다. 그렉 어제

그러나, 나는 2.1all을 mountall하기위한 소스 코드를 얻었고 5 번 설치 한 후 구조 환경에서 컴파일하도록했습니다 (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . nih_info () 호출을 통해 코드에 디버깅 인쇄를 추가했으며 비 차단 대신 fsck 차단을 실행하는 스폰을 만들었습니다. mountall이 어딘가에서 (또는 nih, dbus 또는 plymouth ...) 충돌하고 있다는 이론을 연구하고 있습니다. 매번 코드에서 동일한 위치에 출력을 얻는 것처럼 보이지 않지만 mount () 루틴에서 / dev / sda1을 /-로 다시 마운트 한 후 언젠가는 중지되는 것 같습니다. 그렉 어제

또한 제안한대로 chroot를 통해 dpkg -r 패키지를 수행했으며 작동하는 것 같습니다 (/ proc로 무언가를 수행하려는 제거 스크립트 하나 제외). 나는 와인과 필요한 32 비트 호환 패키지 (lib32nss, ia32lib, lib32v4l 등)와 구조 환경에 설치되지 않은 여러 ibus 패키지 (일부 ibus 패키지가 있으며 제거하지 않도록주의)를 제거했습니다. 플라즈마-위젯-김 판넬-백엔드-이 부스, ibus-qt4, ibus-qt1. 이 중 어느 것도 문제에 영향을 미치지 않았으므로 지금 필요하지 않은 더 많은 패키지를 제거했습니다 (wx widget 및 jdk 패키지 등).

업데이트 : mountall이 emit_event () 루틴 안에 매달려있는 것처럼 보입니다.이 이벤트는 /를 다시 마운트 한 후 호출하여 이벤트를 발생시킵니다. emit_event에서 ply_boot_client_flush ()를 호출 한 다음 env 배열을 구성하고 upstart_emit_event ()를 호출 한 다음 dbus_pending_call_block ()을 호출합니다. 그리고 거기에 달려 있습니다. 그렇다면 왜 dbus_pending_call_block이 무기한 중단 될 수 있을까요? 깨진 플리머스? dbus? 건방진 녀석? 수정 또는 추가 진단에 대한 제안 사항이 있습니까?

솔루션 따라서 언젠가 나는 그것을 가지고 놀고 싶기 때문에 cloud-init 및 cloud-utils를 설치 한 것 같습니다. Will은 우레아 헤드 구성으로 cloud-init 나사를 끄고 dbus 이벤트 'mounted /'가 발생하면 시작되어 시스템이 dbus 메시지를 보낸 즉시 중단됩니다. r / w. cloud-init 및 cloud-utils를 제거했으며 이제는 모두 괜찮아 보입니다. 졸리고 내 삶의 24 시간을 잃었다.