EXEC 단계에서 /bin/plymouth를 빌드하지 못했습니다(Debian 테스트).

나는 또한 오늘 이 정확한 오류를 겪었습니다. 이는 debian wheezy에서 jessie로 업그레이드한 결과였습니다.

"apt-get dist-upgrade"에서는 오류가 발생하지 않았지만 시스템을 재부팅하지 못했습니다. "journalctl -xb"(또는 "-xd")를 통한 최종 오류 출력은 "plymouth"(들어본 적이 없는 응용 프로그램)와 관련이 있습니다. 그러나 실패한 재부팅은 plymouth와 아무 관련이 없다는 것이 밝혀졌지만 /etc/fstab의 보조 항목 아래에 약간의 예외가 있습니다. CDROM 장치의 "auto"를 "noauto"(NFS와 관련 없음)로 변경하면 systemd는 부팅을 허용합니다. 이것은 wheezy에서는 작동하지만 jessie에서는 재부팅을 허용하지 않는 fstab 라인입니다.

fstab과 관련된 Journalctl을 통해 오류가 없습니다. 운 좋게도 웹 검색을 통해 이 모호한 해결책을 찾을 수 있었습니다.

이전 답변과 함께 이 문제는 /etc/fstab의 잘못된 항목으로 인해 발생한 것으로 보입니다.

제 경우에는 시작할 때 자동으로 마운트되도록 설정한 공유 폴더인 virtualbox에서 실행하고 있는데 바로 여기에 문제가 있습니다. 다른 두 답변에서는 문제가 NFS 또는 CD-ROM 장치 설정에 있습니다.

문제를 해결하려면 /etc/fstab에서 중요하지 않은 모든 줄을 주석 처리한 다음 문제가 재현될 때까지 하나씩 다시 추가하는 것이 좋습니다.

그런 다음 문제가 있는 라인을 진단하고 수리할 수 있습니다. dist 업그레이드 프로세스 중에 Vbox 공유 폴더, 네트워크 공유 또는 기타 개인 파일 시스템과 같은 항목이 올바르게 업그레이드되지 않을 수 있습니다.

오늘 정확한 오류가 발생했습니다.

plymouth를 설치했지만 결과는 변경되지 않았습니다.

이는 /etc/fstab의 잘못된 nfs 항목으로 인해 발생합니다. 항목을 제거한 후 오류가 사라졌습니다. 나는이 끔찍한 행동이 어리석은 시스템 때문이라고 생각합니다.

꽤 오래된 스레드인 것 같은데...오늘도 이 문제에 부딪혔습니다.

/etc/fstab시스템이 "긴급 모드"로 부팅되는 것을 방지하려면 다음 줄을 주석 처리해야 했습니다 .

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

*(UUID는 의도적으로 난독화되었습니다)

고쳐 쓰다:

UUID 라인이 /etc/fstab문제를 일으키는 것 같습니다. 이상한. 이 문제에 대해 자세히 읽은 후이 스레드아직 근본 원인에 가까운 명확한 답은 없지만 적어도 스왑은 이제 구성되었습니다.

이 문제를 완전히 해결할 수 있는 사람이 있나요? 아니면 근본 원인을 찾으시나요?