[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: e2fsprogs 1.38
- To: umce-linux@xxxxxxxxx
- Subject: Re: e2fsprogs 1.38
- From: Marcus Watts <mdw@xxxxxxxxx>
- Date: Fri, 18 Nov 2005 15:53:50 -0500
- In-reply-to: Your message of "Fri, 18 Nov 2005 10:11:04 EST." <firstname.lastname@example.org>
> In-Reply-To: <200511180833.DAA14827@xxxxxxxxxxxxxxxxxxxx>
> References: <200511180833.DAA14827@xxxxxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> Message-Id: <c38b41de88664dd6602dfadfeeb09b56@xxxxxxxxx>
> Content-Transfer-Encoding: 7bit
> From: Jane Klingsten <ueda@xxxxxxxxx>
> Subject: Re: e2fsprogs 1.38
> Date: Fri, 18 Nov 2005 10:11:04 -0500
> To: Marcus Watts <mdw@xxxxxxxxx>
> X-Mailer: Apple Mail (2.623)
> Hi Marcus,
> Can you clarify what you meant by:
> > I think now that the fault was in checkfs.
> Was there or is there a bug in checkfs?
> On Nov 18, 2005, at 3:33 AM, Marcus Watts wrote:
> > Michael C Garrison <mcgarr@xxxxxxxxx> had written to ifs2@:
> > ...
> >> When checking e2fsprogs.sf.net website, the latest is 1.38. There are
> >> quite a lot of bug fixes since 1.35, so perhaps we (being umce
> >> linux) should think about updating to 1.38 in the future.
> > ...
> > I've built a copy of 1.38 here:
> > lfs-e2fsprogs-1.38.T
> > I've also updated the build notes to reflect this.
> > Probably this should be merged into our base & various future cds.
> > I don't see any remarkable changes, but it does appear to fix various
> > data typing issues and may work better on very large filesystems.
> > I originally did this because I had a machine with bad blocks
> > in the root partition and checkfs was booting up anyways after
> > fsck failed. I think now that the fault was in checkfs.
> > -Marcus
> > !DSPAM:437d920c214571584618197!
I ran out of time last night to see if I had a mutant version
of checkfs or what. I am convinced now there's a bug in checkfs
in all recent transcripts of the base for umce linux.
Here's a diff of what I tried:
diff -u /home/radmind/file/lfs-base-1.2.5.T/etc/rc.d/init.d/checkfs /tmp/checkfs
--- /home/radmind/file/lfs-base-1.2.5.T/etc/rc.d/init.d/checkfs 2004-08-21 04:12:47.000000000 -0400
+++ /tmp/checkfs 2005-11-18 15:46:15.000000000 -0500
@@ -43,7 +43,20 @@
fsck $options -a -C -T /
+case "$error_value" in
+1) echo fixed, ok ;;
+0) echo success ;;
+2) echo need to reboot ;;
+ if [ "$error_value" -gt 2 -a "$error_value" -lt 16 ]
+ echo halt--fixme
+ echo something weird
+ fi ;;
if [ "$error_value" = 1 ]
The bug is in not setting error_value.
The case statement was because I wasn't sure what was happening with
the multiple ifs after that, and wanted to be sure fsck wasn't
returning some weird value that the if's weren't catching.