** Changed in: e2fsprogs (Ubuntu Gutsy)
Target: tribe-4 => tribe-5
--
Edgy Beta -- fsck on every (re)boot
https://bugs.launchpad.net/bugs/63175
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubu
** Changed in: e2fsprogs (Ubuntu Gutsy)
Target: tribe-3 => tribe-4
--
Edgy Beta -- fsck on every (re)boot
https://bugs.launchpad.net/bugs/63175
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubu
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
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 r
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
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 fi
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
Fresh installed feisty does the same thing, it runs fsck at every boot.
Do you think the reason is the same?
--
Edgy Beta -- fsck on every (re)boot
https://bugs.launchpad.net/bugs/63175
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu
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 timezo
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.
--
Edgy Beta -- fs
Bringing milestone forward
** Changed in: e2fsprogs (Ubuntu)
Target: 7.04-beta => ubuntu-7.04
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
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
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu
tune2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name:
Last mounted on:
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_rec
$ 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 200
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:
[EMAIL PROTECTED]:~$ date
Tue Mar 13 09:22:19 SGT 2007
[EMAIL PROTECTED]:~$
I'll attach the tune2fs output, as well as /var/l
gzipped /var/log/udev
** Attachment added: "gzipped /var/log/udev"
http://librarian.launchpad.net/6766355/udev.gz
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu
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
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
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/lo
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"
--
Edgy Beta -- fsc
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.
** Changed in: e2fsprogs (Ubuntu)
Assignee: Brian Murray => Michael Vogt
--
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 initr
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 t
Milestoning for beta to make sure this doesn't fall off the radar.
** Changed in: e2fsprogs (Ubuntu)
Target: None => beta
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/li
Adding checkfs file
** Attachment added: "fsck output (checkfs) - Daniel Wintschel"
http://librarian.launchpad.net/6580442/checkfs
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailma
Adding checkroot file
** Attachment added: "fsck output (checkroot) - Daniel Wintschel"
http://librarian.launchpad.net/6580441/checkroot
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/
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.
** Changed in: e2fsprogs (Ubuntu)
Assignee: (unassigned) =
I can confirm the same thing on my system, but in addition, I notice the
following output from tune2fs:
[EMAIL PROTECTED]:~$ sudo tune2fs -l /dev/hda1
tune2fs 1.39 (29-May-2006)
Filesystem volume name:
Last mounted on:
Filesystem UUID: 01489b91-7a70-4355-9108-b0b86ad2c4da
...
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 p
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.48] Out of Memory: Kill process 3528 (logsave) score 5361 and
children.
[17180557.48] Out of memory: Killed process 3529 (fsck).
and th
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 Ub
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
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lis
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.
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubunt
Same with me on a fresh Edgy install on a Sony Vaio FS415B, formatted as
ext3.
Possibly related:
On running
sudo tune2fs -l /dev/
Mount count: 13
Maximum mount count: 30
Last checked: Thu Jan 1 01:00:00 1970
Mmmm, that date looks suspicious!
--
Edgy Beta --
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,
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
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bu
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/
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.
--
Edgy Beta --
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
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https
Here is a bootchart from my system.
** Attachment added: "chart"
http://librarian.launchpad.net/4918059/edgy-20061021-1.png
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listi
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
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bug
** Changed in: e2fsprogs (Ubuntu)
Importance: Undecided => Medium
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Same problem. On amd64 with jfs fs.
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Changed in: Ubuntu
Sourcepackagename: None => e2fsprogs
** Changed in: e2fsprogs (Ubuntu)
Status: Unconfirmed => Confirmed
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman
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.
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.co
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.
--
Edgy Beta -- fsck on every (re)boot
https://launchpad.net/bugs/63175
--
ubuntu-bugs mailing list
ubuntu-bu
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/5658
47 matches
Mail list logo
