fsck on every (re)boot

I am also experiencing the same problem. I used "upgrade-manager -c -d" to install Edgy Beta (amd64), and now fsck checks both partitions (/boot and /, both ext3) on every single reboot.

To the original reporter: the usplash bug is at https://launchpad.net/distros/ubuntu/+source/usplash/+bug/56587/

Same problem here, fresh edgy beta install. Fsck checks every boot all mounted partitions (2 fat32, 2 ext3, 1 xfs). On dapper before there were no problems, check runs clean every time.

Same here -- I exerienced this issue with both the 32 & 64 bit beta's.
Running on a Dell Optiplex GX620 with Nvidia card being the only change to the standard build.

Same problem. On amd64 with jfs fs.

Happens here, 32bit.

One 160gb drive
 Partitions:
   * 1gig swap
   * 20gig root (ext3)
   * 20gig /home (ext3)
   * rest a data partition (vfat)

Two 250gb drives
   * one partiion, in RAID1 array with mdadm

Here is a bootchart from my system.

Same problem on an Asus W3V notebook.

IDE 60GB HDD
Intel Pentium M 1.86
1.5Gh RAM

Partitions:
29gig windows (fat32)
21gig home (ext3)
6gig root (ext3)
no swap

Same problem here.

Abit NF7-S
AMD Athlon XP 2600+ mobile
1 GB RAM
NVidia 6600Gt

Kernel: 2.6.17-10-generic

IDE 30GB
2x SATA 80GB

Partitions:

hda1 1GB /boot
md0 14GB / (raid0)
md1 144GB /home (raid0)
md2 2GB swap (raid0)

All formated with ReiserFS. The Filesystems are clean.

I can add myself:

Asus K8N-E
Athlon 64 2800+
1 GB RAM
1x 160 GB Samsung P-ATA drive
1x 250 GB Samsung S-ATA drive

Partitions:

/dev/hda1 56GB /media/windows - Windows System Disk (ntfs)
/dev/hda2 32GB /root (ext3)
/dev/hda5 60GB /home (ext3)
/dev/hda6 2GB swap

/dev/sda1 128GB /media/daten (FAT32) - shared between Windows and Linux
/dev/sda2 56GB /media/ablage - Windows data pile for everything (ntfs)
/dev/sda3 49GB /tmp

I am running Edgy final (32bit) with -generic kernel.

I confirm this bug:

Gigabyte 7VTXE+
WDC WD1200JB 120 gb

/dev/hda1 21Gb - fat32 /media/hda1
/dev/hda5 46Gb - fat32 /media/hda5
/dev/hda5 40Gb - fat32 /media/hda6
/dev/hda7 6,1Gb - ext3 /
/dev/hda8 512Mb - swap

Same here, at least on my desktop. Fresh Edgy Final installed. No problems with Dapper.

Samsung SP1604N
/dev/hda1 10 Gb - ntfs
/dev/hda2 5 Gb - ntfs
/dev/hda3 1 kb - extended
/dev/hda4 18,6 Gb - ext3
/dev/hda5 63 Gb - ntfs
/dev/hda6 52,4 Gb - ext3

Samsung SP1604N (yep, another one)
/dev/hdb1 203,9 Mb - vfat
/dev/hdb2 1 kb - extended
/dev/hdb3 14,6 - ext3
/dev/hdb4 1,5 Gb - swap
/dev/hda5 40 Gb - vfat
/dev/hda6 50 Gb - ext3
/dev/hda7 10,3 Gb - ext3

No problems on my notebook, HP nx6110. Fresh Edgy Final.

/dev/hda1 7,9 GB - ntfs
/dev/hda2 9,8 GB - ext3
/dev/hda3 1 kb - extended
/dev/hda4 18,1 GB - ext3
/dev/hda5 475,2 Mb - vfat
/dev/hda6 949,1 Mb - swap

Same with me on a fresh Edgy install on a Sony Vaio FS415B, formatted as ext3.

Possibly related:

On running

sudo tune2fs -l /dev/xxxx

Mount count: 13
Maximum mount count: 30
Last checked: Thu Jan 1 01:00:00 1970

Mmmm, that date looks suspicious!

I have the same issue with Edgy Eft final. It's there a way to get rid of this problem? Taking so much time to boot.

Have this been fixed or looked in to???
Four months had passed...And I believe this is kinda serious bug.
Or very very annoying at least.

Regards, Matías

AFAIK it's still not fixed. In my case editing /etc/fstab helped. You need to change the last two digits for FAT32 partitions to zero (normally the last one is 1).

The effect is, that the partitions won't be checked. It's a nasty workaround but since I only use it to share certain files between Ubuntu and WinXP, it doesn't matter for me.

i got the same fsck issue, making my boot time around 30min.
Additionnaly i got a OOM killer during the fsck done during the boot. from dmesg:
[17180557.480000] Out of Memory: Kill process 3528 (logsave) score 5361 and children.
[17180557.480000] Out of memory: Killed process 3529 (fsck).

and the box is 512mbyte of ram + 256mbyte of swap. so largely enougth to support a fsck.

i dunno what to do and the fsck during the boot doesnt say which partition is checked which make it very hard to diagnose

Do you have any FAT32-partitions?

It seems, that fsck always checks FAT32-partitions, even though it may show it was checking your root and/or home partition.

Try editing your fstab and change the two numbers at the end of the FAT32 entries (probably 0 and 1) to 0 for both.

This will cause the partitions not to be checked on startup, so don't do it, if you have anything important stored on your FAT32-partiton(s). Alternatively you can try this with all the other drives, one at a time, to see which one is really checked.

I can confirm the same thing on my system, but in addition, I notice the following output from tune2fs:

daniel@daniel-desktop:~$ sudo tune2fs -l /dev/hda1
tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 01489b91-7a70-4355-9108-b0b86ad2c4da
...
...
Last mount time: Thu Mar 29 07:48:46 2007
Last write time: Thu Mar 29 07:48:46 2007
Mount count: 7
Maximum mount count: 30
Last checked: Thu Jan 1 07:30:00 1970
Check interval: 0 (<none>)
...

What I notice is that the last checked time doesn't seem to be getting updated. It shows Jan 1, 1970 - even though if just ran through fsck 30 minutes ago, and every time I boot.

Thanks for taking the time to report this bug and helping to make Ubuntu better. When fsck is run it logs to /var/log/fsck/checkfs and /var/log/fsck/checkroot. Could you please add those files to your bug report? Thanks in advance.

Adding checkroot file

Adding checkfs file

Milestoning for beta to make sure this doesn't fall off the radar.

Daniel, the log files you attached show that fsck thought the filesystems were clean. Was this from a manual run of fsck, or was it from the automatic one at boot, and if the latter did fsck decide to do a full filesystem check on the boot immediately before you attached these logs?

Also, I note that your "last mount time" and "last write time" are in the future, to go along with your "last checked" being in the past. Does your system clock appear to be behaving normally?

Running 'sudo date -s @0' and then rebooting certainly seems to produce a thoroughly confused hardware clock for a couple of reboots. I wonder if this is a useful starting point.

One thought I have is that we could use /etc/adjtime very early in the boot process (although probably not in the initramfs, or we'd have to update it at every boot) to try to make sure that the hardware clock is at least somewhat sane. It might take a couple of boots to stabilise after installation, but that's better than nothing.

Assigned to mvo; please investigate this. Possibilities are that it's caused by faulty hardware clocks, and somehow it's not being set correctly (by the udev 85-hwclock.rules).

Or maybe it's something even weirder.

Useful things from those affected would be:

 * a bootchart from your system. Install the "bootchart" package and reboot, attach the PNG from /var/log/bootchart

 * a copy of /var/log/udev from your system

 * output of tune2fs on the affected filesystems

 * output of "date"

I looked at the checkfs scripts and the various forum posts to see if I can find any indication what causes this problem and also I tried to reproduce this on a vmware image without success so far.

If someone is still affected by this problem I would really appreciate the output of:
$ cat /var/log/fsck/*
$ sudo tune2fs -l /dev/-insert-devices-here-
$ date

and the BIOS date settings.

The puzzeling thing is that on the systems I have at hand the "check interval is unset:
Check interval: 0 (<none>)

This means that it shouldn't do this check even if the clock is off a lot. Debian sets this interval to 6 month, but for ext3 we haven't been using this neither in edgy nor dapper (according to my checks on fresh installs).

If I run tune2fs -i and give it a different value than 0 I can easily reproduce the problem with a incorrect clock setting (as expected).

I would really appreciate the logs from someone affected by this bug.

Thanks,
 Michael

I'm not in front of my Edgy-box right now, so I can't check any log files, but after the last post I think the whole problem might be related to using intervals for checking.

The proof would be my two systems: the desktop checks my /home-partition (ext3) every 14 days (all the others are set to 30 boots) and suffers from this problem. My laptop has all partitions left at 30 boots and does not suffer from this.

Now the only strange thing is, that editing /etc/fstab so that my FAT32-partitions won't be checked actually "resolves" the problem.

I'll see if I can dig up some valuable logs.

Sorry it's taken me a while to get back to this. As of right now, I'm thoroughly confused.

I left the Edgy box up for the past couple weeks (no need to reboot, and was tired of the fsck action). But I rebooted now just to generate the bootchart - and fsck didn't run. Also, I've checked the tune2fs output, and it looks like now the last fsck check has been updated in the output to reflect 28-Feb (my last reboot prior to todays).

My system clock appears to be behaving normally. The "future" date from my previous attachment was because sudo was giving me grief (date too far in the future). I ran sudo for some stuff, then I enabled NTP which changed my clock to +8GMT (I'm in Singapore). So to avoid rebooting I had thrown my clock even further ahead manually in order to get sudo to behave without rebooting.

I'll attach the bootchart anyways, as well as /var/log/udev.

The output for cat /var/log/fsck/* is small, so I'll paste:

daniel@daniel-desktop:~$ cat /var/log/fsck/*
Log of fsck -C -R -A -a
Tue Mar 13 08:51:23 2007

fsck 1.39 (29-May-2006)
/dev/md0: clean, 11216/19546112 files, 4482325/39072064 blocks

Tue Mar 13 08:51:23 2007
----------------
Log of fsck -C -a -t ext3 /dev/hda1
Tue Mar 13 08:51:23 2007

fsck 1.39 (29-May-2006)
/dev/hda1: clean, 155148/9371648 files, 1243005/18731782 blocks

Tue Mar 13 08:51:23 2007
----------------
daniel@daniel-desktop:~$

Alright, I just rebooted again, and again, fine, no fsck. Weird. I checked the BIOS date, and it shows up fine 13-March as I'd expect. Output of 'date' from my system is:

daniel@daniel-desktop:~$ date
Tue Mar 13 09:22:19 SGT 2007
daniel@daniel-desktop:~$

I'll attach the tune2fs output, as well as /var/log/udev.

But as of right now, it seems to 'magically' have resolved itself... :-\

gzipped /var/log/udev

$ cat /var/log/fsck/*

Log of fsck -C -R -A -a
Tue Mar 13 03:55:03 2007

fsck 1.39 (29-May-2006)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/sda1: 220649 files, 3665979/15312004 clusters
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/hdb5: 122194 files, 1681108/1876384 clusters

Tue Mar 13 03:56:11 2007
----------------
Log of fsck -C -a -t ext3 /dev/hdb1
Tue Mar 13 03:55:03 2007

fsck 1.39 (29-May-2006)
/dev/hdb1: clean, 296511/2496960 files, 2196210/4992190 blocks

Tue Mar 13 03:55:03 2007
----------------

$ sudo tune2fs -l /dev/-insert-device-here- (root partition only)

tune2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: b1c9ae04-50dc-4513-9a52-ef3b7c8a0640
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2496960
Block count: 4992190
Reserved block count: 249609
Free blocks: 2795980
Free inodes: 2200449
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16320
Inode blocks per group: 510
Last mount time: Tue Mar 13 03:55:03 2007
Last write time: Tue Mar 13 03:55:03 2007
Mount count: 25
Maximum mount count: 30
Last checked: Tue Feb 27 13:35:24 2007
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Journal backup: inode blocks

$ date

mar mar 13 04:27:46 COT 2007

tune2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0e176fbb-7754-4436-94b4-b68a3c86221e
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2203200
Block count: 4399801
Reserved block count: 219990
Free blocks: 3743628
Free inodes: 2081545
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16320
Inode blocks per group: 510
Filesystem created: Wed Mar 21 14:46:13 2007
Last mount time: Wed Mar 21 14:28:37 2007
Last write time: Wed Mar 21 14:28:37 2007
Mount count: 2
Maximum mount count: 26
Last checked: Wed Mar 21 14:19:59 2007
Check interval: 15552000 (6 months)
Next check after: Mon Sep 17 15:19:59 2007
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 587597
Default directory hash: tea
Directory Hash Seed: 42e4f4c3-98fd-474d-b3f2-c507f79196bb
Journal backup: inode blocks

this is the output on ogras test system. but the fsck happend only on the first boot on a fresh edubuntu server install.
Saying its 49710 days without check ... the clock is correct in teh installer as well as in teh installed system though.

<ogra> mvo, i think i have the cause for my fsck ... my bios clock isnt set to gmt but the fs creation happens before setting the clock, the timestamp on the created filesysstem is in the future

Bringing milestone forward

After some researching, I think it must be caused by the fact that the hwclock.sh init script gets run very late in the boot process. Priror to S50hwclock.sh, the system clock (or kernel clock) is uninitialized, so fsck-1.40 complains the last mount/write time is in the future.

If I were not wrong, this problem shall be experienced by people living in the GMT minus timezones who reboots often. The root cause of this problem is that the kernel initializes the system clock from the RTC, the hardware clock on motherboard, which is several hours behind UTC in GMT minus timezones. Therefore, during the early stage of the boot process, the system clock is several hours behind the UTC, and fsck complains.

Fresh installed feisty does the same thing, it runs fsck at every boot. Do you think the reason is the same?

I suspect the problem does not relate to the filesystem check interval, but to one of the other timestamps, such as the last mount time. A discrepancy there will trigger a full filesystem check regardless of the checkinterval. For example:

potpal:[/tmp] dd if=/dev/zero bs=1M count=1 of=fs.ext3
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.00205541 seconds, 510 MB/s
potpal:[/tmp] mke2fs -j fs.ext3
mke2fs 1.40-WIP (14-Nov-2006)
fs.ext3 is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
128 inodes, 1024 blocks
51 blocks (4.98%) reserved for the super user
First data block=1
Maximum filesystem blocks=1048576
1 block group
8192 blocks per group, 8192 fragments per group
128 inodes per group

Writing inode tables: done

Filesystem too small for a journal
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
potpal:[/tmp] debugfs -w fs.ext3
debugfs 1.40-WIP (14-Nov-2006)
debugfs: ssv mtime 201001010000
debugfs: quit
potpal:[/tmp] fsck -n /tmp/fs.ext3
fsck 1.40-WIP (14-Nov-2006)
e2fsck 1.40-WIP (14-Nov-2006)
Superblock last mount time is in the future. Fix? no

/tmp/fs.ext3 contains a file system with errors, check forced.
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
/tmp/fs.ext3: 11/128 files (9.1% non-contiguous), 38/1024 blocks

Two things about ogra's superblock info:

Filesystem created: Wed Mar 21 14:46:13 2007
Last mount time: Wed Mar 21 14:28:37 2007
Last write time: Wed Mar 21 14:28:37 2007
Mount count: 2
Maximum mount count: 26
Last checked: Wed Mar 21 14:19:59 2007
Check interval: 15552000 (6 months)

First, the filesystem creation time is later than the last mount time. Second, the check interval is set (don't we set that to zero by default now?).

If my guess is correct, it should be possible to reproduce this problem by setting the hardware clock backward between installation and first boot. Systems with a faulty CMOS battery, where the clock resets to an earlier epoch at each boot, would exhibit this type of problem.

This is for #89069 but because it is marked as a duplicate of this topic, should be useful here too.

Found a workaround for who has mine same problem (only at first boot after installation - Last mount in future - fsck died with exit status 3), thanks to #ubuntu-it.

Install normally ubuntu, after installation shutdown the system and does not start for so much hours as the difference (+) with GMT is (in my case ROME, boot system 2 hours after installing).
No error messages will appear on first Feisty boot.
enjoy ;)

We are checking the file system after 180 days by default and this errors seems to occur for people who are ahead of GMT by a few hours (and people with wasted batteries probably).

Could we not simply fix this by adding 12+ hours to the time variable in the code that checks against last fsck? In reality that would cause a check every 179.5 days, but who's counting? :)

The last comment by tillicollaps3 describes a work-around that suggests this should work.

I don't think bug #89069 is a duplicate of this bug. Bug #89069 is clearly a bug in Ubiquity, which updates the system clock to localtime by syncing to a time server shortly after starting its real installation work, but without updating the timezone accordingly. It is experienced by people in GMT + timezones only. - It hasn't been fixed yet in Tribe-2 CD.

I suggest people experience this bug (bug #63175) check their hardware clocks:
1. Type "sudo hwclock -r" regularly to see if it goes slower than the system time.
2. Power cycle your computers and boot straight into BIOS to see if the hardware clocks are correct. (Perhaps keep your computers switched off with power cables disconnected for a couple of hours.)

Hi
First sorry for my english.
I try to lose that fsck on /dev/md0 at each boot time wher sepnd about 5-10min long to finish.
I set tune2fs -c 0 /dev/md0
Was ignored still doing fsck
Maybe was a stupid things but i try to boot with fastboot parameter on grub something like this:
title Ubuntu, kernel 2.6.17-12-server
root (hd0,0)
kernel /boot/vmlinuz-2.6.17-12-server root=/dev/md0 ro fastboot
initrd /boot/initrd.img-2.6.17-12-server
quiet
savedefault
boot
Still same result.
Ok I was thinking is mdadm problem or fsck problem so i upgrade bouth of them to last version and patch them too.
Same old story.
Last thing I wish to do i sto see the bootchart map to see how is looking.
Like any noob did it in the ubuntu way apt-get install bootchart
and i answer Y at that huge list who will be installed. All good till at this point and now surprise in less 35 sec my sistem give me the prompter with login:
This is cool but i dont know what is the answer of my solved problem.
Let me tell you something i did b4 this.
I extract 1 of raid disck from running server and put him on the machine (old server machine) and reboot from him.
Is also true cat /proc/mdstat tell me all the time coz im runing with 1 hdd only and second is on fail.
So to lose that I use the new option of mdadm --manage --remove and cut the missing disck at all and now my /proc/mdstats look like this
Personalities : [raid1]
md0 : active raid1 hda1[0]
      10482304 blocks [1/1] [U]

unused devices: <none>
but after this "enginering" still got the same delay on boot.
I was give up thill now when after i install bootchart the problem is gone.
I add all my services back to this testing server and all run ok.
I will try later on main server wher i install bootchart but i didnt reboot him yet.
If is any help im glad to give you all info you need even access to this testing server dont know what fix him but is fixed.

(Disabling the periodic fsck is Bug #3581 . That bug isn't about very frequent fscks though)

Thanks for the answer.
I still dont get the proper answer at this simple question on each bug reports.
Why settings made by tune2fs isnt check by fsck.

Moving milestone forward.

>I still dont get the proper answer at this simple question on each bug reports.
>Why settings made by tune2fs isnt check by fsck.

E2fsck is checking the superblock settings made by tune2fs. However, in order to perform the check based on times since last fsck time, e2fsck requires that the system clock be set correctly. With current buggy Debian/Ubuntu boot scripts, this isn't happening.

I could work around the problem by adding a config option to /etc/e2fsck.conf

[work-around-buggy-Ubuntu-boot-scripts]
       time-offset = 43200

Which would tell e2fsck to subtract 43,200 seconds from the time returned by time(0), to work around the fact that Ubuntu is screwing up the system clock in the early boot cycle due to not correctly handling the time zone correctly. But otherwise, this is not a problem to solved by e2fsck, but by the buggy Debian/Ubuntu boot scripts that can't be bothered to have the time set correctly when e2fsck is run.

>What I notice is that the last checked time doesn't seem to be getting updated. It shows Jan 1, 1970 - even though if just ran through fsck 30 minutes ago, and every >time I boot.

In humandoing's case, it looks like the problem is that the battery for his CMOS system clock is dead, so the time is always incorrectly set at Jan 1, 1970 during early boot. That a separate problem, and about the only fix would be for e2fsck to never do time-based checks if someone has bad hardware clock on their system. So unliike dahas's comment, the solution would be for e2fsck it *ignore* the tune2fs settings, because the system clock can't be trusted when e2fsck is run.

Hi
Nice work to figure why this things happend and thank you for the answer.
Is ok when i have set something more than zero value on tune2fs -c but when i set tune2fs -c 0 that means to skip all the time dont care about what is the time of system.
This is what I consider bug of e2fsck for any value over 0 can be untrusted the clock but when I sed zero means i will do the fsck when i will have time or can do that with out affect the server function.
I tell you this because on running e2fsck over a system with software raid on mirror can ruin bouth disk or if u have more all of them will be lost as data if the fist 1 who say is up and sincronized have made some changes by e2fsck and change data. This is 1 case and second if i have a big (raid or not) partition as root will take alot time to do that.
I know isnt the smart way to set root partition very big but that in practice that can be happend.
Sorry for my english hope You will get what I wish to tell You.
Thanks Dahas

In correct, "tune2fs -c 0" does NOT mean skip all time-based checks. "tune2fs -c 0" means to skip checks based on number of mounts. To disable all time-based checks, you need to use "tune2fs -i 0". Read the tune2fs man page, please!! The bug in this case seems to be in your understanding of tune2fs options.

Then I'm sorry for my mistake
Like old man say RTFM is the answer.

Setting status back to New as logs Michael asked for were supplied.

Moving milestone to beta.

moving milestone to RC

I just wanted to add, that now Ive upgraded my laptop and reinstalled my desktop with Kubuntu Gutsy Beta. Both machines have one FAT32-partition (details can be found in my post above) and the desktop is still the only one to suffer from this problem. Editing /etc/fstab so that the FAT32-partition on my desktop is never checked, solves the problem.

A question for the release team:

To fix this bug, we need to upload a util-linux newer than -6ubuntu1,
which raises the question of whether you want me to upload -6ubuntu2, or
-8ubuntu1. Of potential interest to the release in their own right are:
    - mount: doesn't drop privileges properly when calling helpers
    - hwclock: fix --rtc option. Closes: #444924
  * hwclock: Reintroduce hwclockfirst.sh on Debian machines. Closes: #443487

I don't feel that there is anything there that should not go into a
2.13 upload of util-linux, but wanted to give you folks a chance for
input before I upload something... 2.13-8 is currently in incoming,
where it will sit for the next 5 hours or so.

thoughts?
lamont

util-linux (2.13-8) unstable; urgency=low

  * Upstream git:
    - po: update sv.po (from translationproject.org)
    - mount: doesn't drop privileges properly when calling helpers
    - hwclock: fix --rtc option. Closes: #444924
    - setarch: fix compiler warning
    - login: login segfaults on EOF (rh#298461)
    - build-sys: nls/locale handling in util-linux-ng general
    - blockdev: add missing description about option --report in manpage
  * fix messages in "hwclock.sh start". Closes: #436873
  * Honor DEB_BUILD_OPTIONS=nostrip. Closes: #443853

 -- LaMont Jones <email address hidden> Mon, 01 Oct 2007 21:57:41 -0600

util-linux (2.13-7) unstable; urgency=low

  * cfdisk.8: mention slang next to curses. Closes: #295487
  * util-linux.postrm: remove /etc/adjtime on purge. Closes: #245236
  * hwclock: Reintroduce hwclockfirst.sh on Debian machines. Closes: #443487
  * mount.preinst: chroot-check was broken. Closes: #443466

 -- LaMont Jones <email address hidden> Fri, 21 Sep 2007 22:10:20 -0600

(most of the hwclock.sh change is indentation)
% git diff v2.13-6..v2.13-8 | diffstat
 configure.ac | 1
 debian/changelog | 24 +
 debian/hwclock.sh | 76 ++--
 debian/mount.preinst | 22 -
 debian/rules | 9
 debian/util-linux.postinst | 3
 debian/util-linux.postrm | 1
 disk-utils/blockdev.8 | 8
 fdisk/cfdisk.8 | 4
 hwclock/rtc.c | 33 -
 include/nls.h | 8
 login-utils/login.c | 4
 misc-utils/cal.c | 1
 misc-utils/look.c | 1
 misc-utils/write.c | 1
 mount/mount.c | 8
 mount/umount.c | 8
 po/sv.po | 747 +++++++++++++++------------------------------
 sys-utils/setarch.c | 2
 text-utils/colrm.c | 2
 text-utils/more.c | 1
 text-utils/pg.c | 2
 22 files changed, 392 insertions(+), 574 deletions(-)

See http://bugs.debian.org/443487 for some detail on the issue. The affected users are anyone who has their BIOS time set to localtime, and is east of Greenwich. Solving this for ubiquity installs requires allowing the user to tell the installed system that this is the case (new question in ubiquity). The util-linux fix by itself will fix debian-installer installed systems, as well as those that have been told post-install that the BIOS clock is localtime.

I'm fine with -8ubuntu1

2.13-8ubuntu1 uploaded.

I'm leaving this bug open so that it can be used for the ubiquity change to prompt for "BIOS clock in localtime or UTC?" and thereby set things up for hwclockfirst.sh to do the right thing.

We already have a different ubiquity bug for that (bug 37750).

Although you say this effects only people east of Greenwich, I am based in London and still experience this bug. Can provide more info if needed.

Same problem here... leaving in dublin GMT = London

same problem here. The fsck check slows down the startup time dramatically.

When reporting problems, please tell us which version of e2fsprogs and what version of ubuntu you are using. Also whether you have your hardware clock ticking localtime or UTC. Otherwise a "same here" isn't very useful....

I am sorry I did not provide those details

Ubuntu 7.10
Esfsprogs version - 1.40.2-1ubuntu1

I do not know how to see the hardware timing settings. Is that an option on
the bios setup?

Best regards,

      Duarte Molha

On Nov 18, 2007 6:04 PM, Theodore Ts'o <email address hidden> wrote:

> When reporting problems, please tell us which version of e2fsprogs and
> what version of ubuntu you are using. Also whether you have your
> hardware clock ticking localtime or UTC. Otherwise a "same here" isn't
> very useful....
>
> --
> fsck on every (re)boot
> https://bugs.launchpad.net/bugs/63175
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
=========================
    Duarte Miguel Paulo Molha
        Tel: +447795416232
 Email: <email address hidden>
=========================

I experience this problem

Running e2fsprogs 1.40.2-1ubuntu1 (gutsy) and my hardware clock is ticking localtime - at least it says LOCAL in /etc/adjtime

Timezone is Europe/London

Bulldog, this is due to Ubuntu having buggy init scripts, and not setting the time correctly before running e2fsck. For some number of strange reasons I haven't been able to get Ubuntu staff to deal with this problem correclty, so starting with e2fsprogs 1.40.3, the debian/rules files have been set up to work around the problem using an /etc/e2fsck.conf script:

[options]
        buggy_init_scripts = 1

Sorry theodore for that i didn't provide the information correctly. I am not
a Linux Expert :-(

On Dec 16, 2007 8:34 PM, Theodore Ts'o <email address hidden> wrote:

> Bulldog, this is due to Ubuntu having buggy init scripts, and not
> setting the time correctly before running e2fsck. For some number of
> strange reasons I haven't been able to get Ubuntu staff to deal with
> this problem correclty, so starting with e2fsprogs 1.40.3, the
> debian/rules files have been set up to work around the problem using an
> /etc/e2fsck.conf script:
>
> [options]
> buggy_init_scripts = 1
>
> --
> fsck on every (re)boot
> https://bugs.launchpad.net/bugs/63175
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I too have almost the same problem. Im using alpha3 ubuntu 8.04 i386 version on amd64 laptop. It scare me to boot to linux as everytime its going to do the fsck thing and some kind of error comes up

fsck 1.40.3 (05-Dec-2007)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  430:4e/52, 431:54/65, 432:4c/6d, 433:44/6f, 434:52/76, 435:20/65, 436:69/20
  , 437:73/64, 438:20/69, 439:6d/73, 440:69/6b, 442:73/20, 443:69/6f
  , 444:6e/72, 445:67/20, 446:ff/6f, 447:0d/74, 448:0a/68, 449:44/65
  , 450:69/72, 451:73/20, 452:6b/6d, 453:20/65, 454:65/64, 455:72/69
  , 456:72/61, 457:6f/2e, 458:72/ff, 459:ff/0d, 460:0d/0a, 461:0a/44
  , 462:50/69, 463:72/73, 464:65/6b, 465:73/20, 466:73/65, 467:20/72
  , 468:61/72, 469:6e/6f, 470:79/72, 471:20/ff, 472:6b/0d, 473:65/0a
  , 474:79/50, 475:20/72, 476:74/65, 477:6f/73, 478:20/73, 479:72/20
  , 480:65/61, 481:73/6e, 482:74/79, 483:61/20, 484:72/6b, 485:74/65
  , 486:0d/79, 487:0a/20, 488:00/74, 489:00/6f, 490:00/20, 491:00/72
  , 492:00/65, 493:00/73, 494:00/74, 495:00/61, 496:00/72, 497:00/74
  , 498:00/0d, 499:00/0a, 506:bf/cb, 507:cc/d8
1) Copy original to backup
2) Copy backup to original
3) No action

i've tried all the three options nothing worked.

I've /dev/sda1 , /dev/sda5, /dev/sda6 on fat32 and /dev/sda7 on ext3

Atleast whats the problem with it and how do i stop this check every time.

Hi,

The changelog of util-linux 2.13-10ubuntu1 has

  - deliver hwclockfirst.sh on ubuntu as well. LP: #63175

Theodore, does this address your problem with the init scripts,
or is it a Debian problem as well as an Ubuntu one?

This change is only in Hardy, so is anyone able to
reproduce there?

Vijay, your problem appears to be different, as you have an
actual problem being reported by fsck, you may want to
open a separate bug report for that.

Thanks,

James

There is an open question about whether e2fsprogs still needs to work around the clock setting at fsck time because of a change that has now been made to util-linux, but regardless, e2fsprogs 1.40.8 has been merged into hardy now so I believe this bug is fixed.

If anyone is still seeing this behavior with current hardy, please reopen the bug for further investigation.

Now that the buggy init scripts have been fixed in util-linux, I suggest people affected by this bug change buggy_init_scripts option to 0 in /etc/e2fsck.conf. If nothing comes up, it's probably a good idea to let it default to 0. If util-linux does not initialize system time properly, fix it, instead of working around it in e2fsprogs, because other file systems may also have a problem with incorrect system time.

> Now that the buggy init scripts have been fixed in util-linux, I suggest
> people affected by this bug change buggy_init_scripts option to 0 in
> /etc/e2fsck.conf.

If you think further changes to e2fsprogs are needed, please open a separate bug report for that. This bug report is milestoned as being critical for the Ubuntu 8.04 release, and should only be reopened if the buggy behavior persists.

I have Ubuntu Hardy installed since the Beta release and I have all the updates. Since a week (or maybe two) fsck is checking my root partition on every (re)boot and breaks also the usplash boot to textual boot.

If you need further information on that, please let me know how I may help.

Hello,
I also have this buggy behaviour in 8.04 upgraded since Drapper.

Please fix this.

Tim, Franziskus,

     Its not clear that the problem you are seeing has the same root cause as previous reports that have been against this bug database. Can you send the full output of your fsck output?

This problem can be caused by a faulty CMOS clock, or the CMOS battery being dead, such that the time is incorrect at the time that fsck is run. So to test that, insert the following line in /etc/init.d/checkroot.sh after the line which reads "do_start () {":

        log_action_msg "Time at fsck time: $(/bin/date)"

If the time that gets displayed is not correct, then that's the cause of the problem.

This bug has been nominated for gutsy, but it seems unlikely that we're going to see any SRU activity for it given that there's been a subsequent Ubuntu release since then. Marking 'wontfix'.