fsck / dirty filesystem on instance is death
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init (Ubuntu) |
Won't Fix
|
High
|
Unassigned | ||
Precise |
Won't Fix
|
High
|
Unassigned | ||
Quantal |
Won't Fix
|
High
|
Unassigned |
Bug Description
As we saw in bug 898373, if a filesystem needs manual intervention for an fsck, then boot completely stops. mountall will wait indefinitely on someone attending to this broken filesystem, and in a cloud (at least in EC2) with no console access, that means the system will never boot.
I discussed this in #ubuntu-devel with slangasek at http://
He suggested to mark disk 'noauto' or 'nobootwait', but that is not really what someone would want to do.
The ideal fix in some sense would be to start an ssh daemon, and force the user into a screen session where they could fix it.
To that, slangasek said:
smoser: sure, either fixing /etc/init/
Related bugs:
* bug 898373 : fsck.ext3: Device or resource busy while trying to open /dev/xvda2
tags: | added: rls-p-tracking |
Changed in cloud-init (Ubuntu): | |
assignee: | nobody → Ben Howard (utlemming) |
Changed in cloud-init (Ubuntu Precise): | |
status: | Triaged → Won't Fix |
Changed in cloud-init (Ubuntu Quantal): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Ben Howard (utlemming) |
tags: |
added: rls-q-incoming removed: rls-p-tracking |
Changed in cloud-init (Ubuntu Quantal): | |
milestone: | none → quantal-alpha-3 |
Changed in cloud-init (Ubuntu): | |
status: | Triaged → Won't Fix |
Changed in cloud-init (Ubuntu): | |
milestone: | quantal-alpha-3 → none |
Removed the rls-q-incoming tag, according to the process.