always fscks first boot after install

Do you have a windows partition on your PC ?
Do you use UTC time ?

May be this bug is #89069 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/89069

Bug 63175 is something different - the user there has fsck on _every_ reboot and we don't know how to reproduce that.

This bug involves fsck only on the first boot after installation. It is probably the same bug as 89069, as Patrice Vetsel suggests. It is probably related to UTC/non-UTC and timezone setup.

The system in question has its hardware clock set to UTC but it has a disused W98SE install on its disk. I haven't checked whether it is able to access ntp.ubuntu.com. If I take out that disk and use a scratch disk instead, this bug (the spurious fsck) does not appear so I think it must be related to the presence of the windows partition(s).

14:40 <cjwatson> iwj: FWIW /var/log/installer/cdebconf/questions.dat should be
                 enough information for accurate reproduction by somebody who
                 knows how to read it; alternatively an install with
                 DEBCONF_DEBUG=developer in the kernel boot parameters
14:40 <cjwatson> (and /var/log/installer/syslog from the latter)

ubuntu/widows xp both does an first check after resizing partition and install of ubuntu

I have determined that:

 * I can reproduce this bug with the alternate CD but not with the
   desktop CD (I haven't investigated why not).
 * The problem is indeed caused by the clock warping back one hour
   between the system installation and the first boot. In my case
   this is due to confusion and mismatch between the CMOS clock and
   the supposed timezone.
 * fsck notices and fixes the "last mount" and "last write" times.
 * fsck then complains about the "last check" time, indirectly,
   by claiming the fs hasn't been checked for 49710 days.

I think that:

 * It is not reasonable for us to assume that the CMOS can be correct
   at this point and in particular we mustn't assume that the system
   clock will not warp backwards shortly after installation. There
   are many reasons why this might happen, including that the
   installer setup may not have as good access to ntp timeservers as
   the installed system. I don't think we should try to get all of
   this perfect (in particular, there is guesswork involved which is
   never going to be right without asking the user questions, which we
   want to avoid).
 * If the last check time is in the future by less than some amount
   (say, <=24h or <=48h) e2fsck should just fix it and not complain.

Ian.

"If the last check time is in the future by less than some amount (say, <=24h or <=48h) e2fsck should just fix it and not complain."

I agree, this sounds like a sensible fix.

This is a test patch which I've generated which works around the problem a different way. I sitll think the Ubuntu installer and init scripts are being willfully negligent by not trying to do a better. If Ian is really right that the Ubuntu installer isn't going to ask the User to set the clock correctly, there is really not much I'm going to be able to do.

Let's try that again....

Moving milestone to beta.

This particular misbehaviour was worked around here:

 e2fsprogs (1.40.2-1ubuntu1) gutsy; urgency=low
 .
   * If last check time is in the future just fix it up even during preen,
     just like last mount and last write times. LP: #131201.
     See also Debian #343662, #343645.
   * Invent a spurious debian/copyright file to satisfy Launchpad.

hou is je kop dicht 1312201 brian murray

2007/8/31 Brian Murray <email address hidden>

> ** Tags added: iso-testing
>
> --
> always fscks first boot after install
> https://bugs.launchpad.net/bugs/131201
> You received this bug notification because you are a bug contact for
> debian-installer in ubuntu.
>