resize2fs doesn't notice the partition was fsck'ed

[misiu_mp]

Binary package hint: gparted

Running from a live cd image of ubuntu 9.04 through virtual box.
When trying to shrink a partition (on a virtual box HDD) I got a message saying the e2fsck should be run on the affected partition. It was run and finished without errors:

   check file system on /dev/sda5 for errors and (if possible) fix them 00:04:02 ( SUCCESS )

   e2fsck -f -y -v /dev/sda5
      ....

   shrink file system 00:00:01 ( ERROR )

   resize2fs /dev/sda5 15791863K
   resize2fs 1.41.4 (27-Jan-2009)
   Please run 'e2fsck -f /dev/sda5' first.
(full output attached)

Manually running e2fsck followed by resize2fs ends in the same result.
Performing the operation on another partition (/dev/sda6) also fails.

Note: resizing partitions inside a virtual box disk (VDI) using a gparted from a livecd is the recommended way (http://forums.virtualbox.org/viewtopic.php?p=29276#29276).

[Endolith (endolith)]

I think I have the same problem. It resizes the partition, checks the file system, then tries to resize the filesystem to fit the partition. resize2fs gives an error, so GParted just gives up and doesn't try to fix the problem it created.

ubuntu@ubuntu:~$ sudo resize2fs -p /dev/sda7
resize2fs 1.41.4 (27-Jan-2009)
Please run 'e2fsck -f /dev/sda7' first.

ubuntu@ubuntu:~$ sudo e2fsck -f /dev/sda7
e2fsck 1.41.4 (27-Jan-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Jaunty: 665315/4340752 files (0.6% non-contiguous), 16571397/17464655 blocks

ubuntu@ubuntu:~$ sudo resize2fs -p /dev/sda7
resize2fs 1.41.4 (27-Jan-2009)
Please run 'e2fsck -f /dev/sda7' first.

[Endolith (endolith)]

I am using Jaunty LiveCD

Seems this problem has existed for years?

http://<email address hidden>/msg91916.html

[Endolith (endolith)]

GParted liveCD that I just downloaded has the same problem. now i don't know if i should boot my computer.

[Endolith (endolith)]

Isn't there a "verbose mode" or something? I have no idea why it has a problem with resizing, it just refuses to do it.

[Theodore Ts'o (tytso)]

Please send the output of dumpe2fs -h on the filesystem before and after running e2fsck -f. Tihs is normally due to buggy initscripts and an incorrect system clock when the filesystems are mounted and/or checked.

The debian bug has been closed because it has been fixed under debian when their initscripts were fixed. This may be related to a a fundamental design flaw in the Ubuntu installer which caused me to have to have a special /etc/e2fsck.conf file that that only exists when packaging e2fsprogs for Ubuntu (and not for Debian).

[Endolith (endolith)]

I just forced it, sorry. I hope that didn't ruin anything, but I need to use my computer.

Before I forced it, I made an image of the partition on another drive (ddrescue to a file). Is that still usable for your test?

[Jan Claeys (janc)]

I think it would certainly be useful (if you still have it).

[Scott James Remnant (Canonical) (canonical-scott)]

Ted - do you know whether the image copy would be sufficient?

Also we've long-since fixed the buggy init script problem - we should probably drop that conffile

[Endolith (endolith)]

Here's what I get from this command:

/m/E/newbackup> dumpe2fs -h Jimage

[Theodore Ts'o (tytso)]

On Wed, Jul 15, 2009 at 04:16:23PM -0000, Scott James Remnant wrote:
> Ted - do you know whether the image copy would be sufficient?

Yes, it should be. It would also be good to see the hardware clock
time, the system clock, and the claimed time zone.

> Also we've long-since fixed the buggy init script problem - we should
> probably drop that conffile

As I recall there were two problems; one was the buggy init script.
The other was that Ubuntu didn't want to ask the user what time zone
the user was in, or what the correct time was, and that resulted in a
forced fsck after the initial install. So we could try dropping it,
but we might want to double check that something sane happens during
the installation and after the first boot vis-a-vis getting the correct
time and timezone set.

      - Ted

[Scott James Remnant (Canonical) (canonical-scott)]

 status confirmed

On Wed, 2009-07-15 at 17:58 +0000, Endolith wrote:
> Here's what I get from this command:
>
> /m/E/newbackup> dumpe2fs -h Jimage
>
>
> ** Attachment added: "dumpe2fs.txt"
> http://launchpadlibrarian.net/29080242/dumpe2fs.txt
>
Thanks - any help Ted?

Scott
--
Scott James Remnant
<email address hidden>

[Theodore Ts'o (tytso)]

On Thu, Jul 16, 2009 at 10:28:17AM -0000, Scott James Remnant wrote:
>
> On Wed, 2009-07-15 at 17:58 +0000, Endolith wrote:
> > Here's what I get from this command:
> >
> > /m/E/newbackup> dumpe2fs -h Jimage
> >
> >
> > ** Attachment added: "dumpe2fs.txt"
> > http://launchpadlibrarian.net/29080242/dumpe2fs.txt
> >
> Thanks - any help Ted?

Yep, it looks like Ubuntu still needs "buggy init scripts", at least
on whatever system was run on.

Last mount time: Tue Jun 16 21:53:18 2009
Last write time: Tue Jun 16 19:54:51 2009
Mount count: 0
Maximum mount count: 33
Last checked: Tue Jun 16 19:54:51 2009
Check interval: 15552000 (6 months)
Next check after: Sun Dec 13 18:54:51 2009

The problem is the mount time is in the future; this is because of
Ubuntu's, well, buggy init scripts, which has the system clock set to
the hardware clock, which was ticking localtime, as if it were GMT.
This bug is especially bad for people living west of GMT, since the
system clock is temporarily ticking in the future. Proper init
scripts need to inform the system about the timezone (which is why the
Ubuntu installer needs to _set_ the timezone correctly) which can warp
the system clock to the correct time, ***before** e2fsck is run on the
root filesystem, and ***before*** the root filesystem is remounted.

This is why the last mount time is set in the future; because of
Ubuntu's buggy init scripts. (Or at least, they were buggy at the
time this filesystem was in use.) This problem tends not be noticed
in places east of GMT (i.e., in the US) since even with buggy init
scripts, the system clock error is in the opposite directory, so time
is ticking in the past when the root filesystem is mounted, and this
doesn't cause the problem. People who have their system clock tick
GMT (i.e. real Unix/Liunx time), instead of the localtime abomination
promoted by Windows (especially since the CMOS doesn't store the local
time zone, so there's no way of interpreting the hardware clock time,
and no way of knowing if the Daylight Savings Time / Summer Time
adjustment has been made), also don't have this problem.
Unfortunately, at least historically, Ubuntu was decided it was better
to follow Window's mistakes. :-(

Anyway, looking at this some more, I think the real problem is that
the "buggy init scripts" boolean not only suppressed the full check,
but it also suppressed e2fsck fixing the problem of the mount time
being in the future. This is what is causing resize2fs to constantly
complain about mount time being in the future. So what we need to do
is to change e2fsck to fix the problem, but not force a full check if
buggy_init_scripts is set.

Also, depending on what Ubuntu distribution was use for this
filesystem image, I might not be so quick to assume that Ubuntu really
has fixed all of the aspects of the the buggy init scripts. But I
suppose we'll know soon enough; if it hasn't been fixed, we'll get
tons of complaints from people in Western Europe, and hopefully this
time someone else will get to field the abuse from confused, clueless
Windows users. (I was really tired last time of people compl...

[Endolith (endolith)]

I don't understand why this has anything to do with the system clock, which is clearly not something that can be relied on. It's just looking to see if the volume has been mounted since the last time it was checked for problems? There's no better way to do that?

Seems like Ubuntu's decision is the best one, since it's often used on multi-boot systems with Windows. https://help.ubuntu.com/community/UbuntuTime#Multiple%20Boot%20Systems%20Time%20Conflicts

[Theodore Ts'o (tytso)]

Endolith,

That's what we do. The problem is that the system clock is set incorrectly thanks to Ubuntu's decision at the time when the file system is mounted. This means that the incorrect system time is set at mount time. The time then gets warped into the past (to the correct time) later by other init scripts, perhaps when ntpdate is run. So checking to see if the mounted has been mounted since the last time it has been checked from problem only works if the system clock is reliable --- which it isn't if your system clock ticks localtime, and either (a) the init scripts are buggy, or (b) the system doesn't know what timezone it's in, because the Ubuntu installer doesn't want to ask the users.

This lead to me repeated having to explain this to Ubuntu users again, and again, and again, and how this wasn't e2fsck's fault, since there was no way I could tell whether or not this was due to filesystem bugs, or a buggy init scripts. Hence the buggy init scripts config option.

In any case, I've confirmed that this is precisely why this bug is happening.

[Theodore Ts'o (tytso)]

This patch fixes the problem. Note that because of Ubuntu's time handling problem, we've never experienced this issue on any other distributions.

[Scott James Remnant (Canonical) (canonical-scott)]

Ted you appear to have been addressing the wrong person; the original reporter was running 9.04 while Endolith is running jaunty.

Is the original reporter (misiu_mp) still experiencing by this problem?

[Jan Claeys (janc)]

@Theodore Ts'o

> his may be related to a a fundamental design flaw in the Ubuntu installer

and

> The other was that Ubuntu didn't want to ask the user what time zone
> the user was in, or what the correct time was

The Ubuntu installer has always asked for time zones, so what exactly do you mean by that?

Maybe that the live CD doesn't ask for the time zone?

Is there a bug report about that?

[Endolith (endolith)]

9.04 and Jaunty Jackalope are the same thing. :)

[Theodore Ts'o (tytso)]

This bug has been fixed for a long, long time (since v1.41.9). This probably can be closed....