This bug was fixed in the package sysvinit - 2.86.ds1-14.1ubuntu45
---
sysvinit (2.86.ds1-14.1ubuntu45) hardy; urgency=low
* Fix handling of fatal fsck errors in the usplash integration. (LP: #209416)
- usplash-fsck-functions.sh: When fsck exits with an error 1, this
With Ted's example commands I can replicate the reboot loop in splash
mode. I'll have a look at this now.
Setting to sysvinit since I suspect the bug is in checkroot.sh (for not
displaying the text message properly) and the usplash fsck integration
(for not killing usplash on failure).
**
When I corrupt the disk and boot without 'splash' (either immediately or
after a few reboot loops), I get attached screenshot. This looks fine to
me, I get the RUN fsck MANUALLY notice and a root shell.
However, Sam's screenshot is different: given the check percentage lines
on his system, the
I fixed the fsck integration to quit usplash on fsck errors 1. Now I
end up with the same screen as Sam. The RUN fsck MANUALLY message is
not printed. I do get a sulogin shell, but it does not show any prompt.
I suspect that the terminal attributes get wrecked. Looking into that
now.
--
fsck
I tested this with the following cases:
- clean fs, routine check, cancel
- clean fs, routine check, no cancel
- two clean fses with routine check, and mixed cancelling
- one ext3 and one reiserfsck
- corrupt ext3 root fs (I get to the console and get the fsck message, as well
as usable
I got it now, I think. I uploaded a new sysfsutils which is now sitting
in the UNAPPROVED queue, and will be accepted after the Hardy RC
release.
FYI, I attach the debdiff.
** Attachment added: debdiff
http://launchpadlibrarian.net/13506860/sysvinit.209416.debdiff
--
fsck not repairing
Ted: since upstart was new to Hardy - for the record, upstart was
introduced in Edgy, i.e. Ubuntu 6.10.
--
fsck not repairing corruption on boot
https://bugs.launchpad.net/bugs/209416
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
i tried theodore's debugfs commands, at boot the fsck happens during the
splash screen and then when it fails i am taken to a prompt (though it
is not very clear as there is no # or $) see attachment.
is there any reason that Inodes that were not part of a corrupted
orphan linked list found
sam tygier [2008-04-02 1:14 -]:
is there a way to deliberately cause this sort of disk corruption? i had
a google for way to do it, but is seems that most people want to fix
corruption ;-)
In my experience, this triggers a fatal error, which is correctable
well:
sudo tune2fs -s 0
Actually, that won't replicate the problem you're trying to replicate.
In order to do that, you need to induce an error which causes e2fsck to
exit with a preenhalt statement when you run it with the -p option.
So for example:
# debugfs -w -R write /etc/motd test-file /tmp/foo.img
debugfs 1.40.8
I'll do some reproducing and checking where exactly the bug lies.
** Changed in: upstart (Ubuntu)
Assignee: (unassigned) = Martin Pitt (pitti)
--
fsck not repairing corruption on boot
https://bugs.launchpad.net/bugs/209416
You received this bug notification because you are a member of
I agree that we should really fix this for Hardy. I'm currently not sure
where the problem is (in upstart, or the usplash integration, etc.).
Incidentally, is it possible to safely fake this situation in order to
test this? Well, I guess temporarily replacing e2fsck with an exit 4
shell script
Sam,
In your original report, you said:
I did the nosplash thing and got the following
* Checking root file system...
1254
fsck 1.40.8 (13-Mar-2008)
/dev/sda9 contains a file system with error, check forced.
Checking drive /dev/sda9: 0% (stage 1/5, 1/79)
Checking drive /dev/sda9: 1% (stage 1/5,
i snipped out the some lines from the middle with incrementing
percentages (and there were normal verbose booting lines above). i did
not not see any message telling me to run fsck.
the reboot loops were with no interaction by me. it would just go
through BIOS, then grub, then show the splash,
the fsck man page says
-y For some filesystem-specific checkers, the -y option will cause
the fs-specific fsck to always attempt to fix any detected
filesystem corruption automatically. Sometimes an expert may be
able to do better driving the
There are two prolems with using -y. First of all, the idea of giving
the user these files may have been dmanaged at the next login doesn't
work if these are access control files for controlling which hosts are
allowed to talk to a server, or other forms of security critical files
if the machine
The getting stuck in a reboot loop part is possibly a duplicate of bug
204097.
--
fsck not repairing corruption on boot
https://bugs.launchpad.net/bugs/209416
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
This looks like an upstart bug. There are certain bugs which e2fsck
will not fix automatically, but where it wants a human to look at the
filesystem and decide what the right thing is before just going ahead
and blindly fixing the problem. (For example, the filesystem corruption
might result in
18 matches
Mail list logo
