This was fixed a release or two ago.
** Changed in: partman-ext3 (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/3581
Title:
New ext3 partit
** Changed in: partman-ext3 (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/3581
Title:
New ext3 partitions should not have max-mount count
To
An ext4 partition I have on my EeePC 900 with a 10.04 install has both a
max mount count of 38 and a forced check after date of six months. Nasty
on a headless machine but the laptop case is vastly improved (if a bit
broken when the splash screen is skipped).
** Changed in: partman-ext3 (Baltix)
The way this issue is handled in Lucid is much better. No need to change
anything now, in my view.
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
Thank you for posting this bug.
Is this an issue in Lucid?
** Changed in: partman-ext3 (Ubuntu)
Status: Confirmed => Incomplete
** Changed in: partman-ext3 (Baltix)
Status: New => Incomplete
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/35
It's integrated into the boot splash screen, with an option to cancel
the check.
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs m
I haven't tried Hardy - how was this solved? Is a message displayed how
to skip or cancel a running check? Does it fall back to the text console
or is it integrated in the boot splash thing?
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received t
** Attachment added: "signature.asc"
http://launchpadlibrarian.net/13020756/signature.asc
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
u
The Hardy interface for this is quite slick - at least it gives one the
impression of being cleanly executed. We should still figure out how to
handle it more gracefully than blocking-on-boot.
Mark
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You
Is his still a problem ? In Hardy it is possible to either skip or
cancel a running fsck (bug #22460).
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscrib
Can we at least make this configurable for the user? I mean configurable
for everybody (i.e. a module in the settings window) and not by fiddling
around in some config file. I just recently had the pleasure to enjoy a
fsck on my 200GB laptop 4200rpm drive. It took over 20 minutes and I
really neede
(Still here in Hardy (development branch) on a freshly made partition:
# tune2fs -l /dev/hdc1
tune2fs 1.40.8 (13-Mar-2008)
Filesystem volume name:
[...]
Mount count: 2
Maximum mount count: 36
Last checked: Sat Mar 29 19:20:52 2008
Check interval: 15552000
The notification bubble is an interesting idea.
But honestly, with a new Ubuntu version being released, what?, every 6
... 9 months or so? then does it really matter whether the partition is
verified or not?
When upgrading to a new release, if the disk is formatted then it
doesn't matter. If it's
Another idea is to warn the user that he is in the 25..29th mount after
he logs in and offer a read-only, valid check *whenever the user wants
but before the 30th mount*. And, if the check proves the disk to need
r/w to fix something, to provide an option to schedule the check for the
next reboot.
I've just stumbled across this mailing list thread discussing it
https://www.redhat.com/archives/ext3-users/2008-January/msg00027.html
(although the conversation quickly turns to the creation of a LVM based
cron script). The suggestion is that people use LVM snapshotting and
then check the snapshot
** Also affects: partman-ext3 (Baltix)
Importance: Undecided
Status: New
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs
I've done some research, and there's no way to use fsck (well, we're
really looking at e2fsck here) in the targeted manner you described -
that's not to say it can't be done, just that it can't be done with the
current e2fsck, we'll need a rewrite, or a new tool altogether. That's
beyond my skills
So it does look like it would be better to have a set of "known issues"
to point fsck at. I wonder how amenable fsck is to that sort of "just
fix these issues" approach?
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notificati
Of course I started fiddling with the aim of throwing together something
that could do that, but found a problem.
I ran fsck with -n on my root partition, it said there was an inode
problem, so I touched /forcefsck and rebooted to run a full fsck. After
rebooting I ran fsck -n again to see what i
Using the -n switch, fsck can check a mounted filesystem (-n tells it
not to make any changes, so it wont do any repairs). So the quick way
to implement this would be to have a scheduled 'fsck -n', if it comes
back clean, fine, if it comes back dirty, schedule a full check to run
(on shutdown, wit
My understanding is that *finding* errors can be done read-only, and
*fixing* errors requires r/w. What I'd like to see is:
- the ability to run scheduled "error finding" checks, that log the
places to be fixed somewhere
- the ability to check those logs on boot, and fix errors quickly based
I was wondering if solving the problem was worth while, or whether we'd
be better of just scrapping the check altogether, so a while ago I asked
a couple of ext3 devs:
Does fsck need to be run on ext3 partitions?
Andrew Morton:
Theoretically: no.
Practically: yes. There are software bugs and ha
I know AutoFsck was mentioned already, but I think it's worth mentioning
with regard to the last comment.
AutoFsck doesn't interfere with the start up check (if it's called for
some reason, it'll still run), and prompts the user on shutdown (no user
confirmation, no check run), which means it does
Regarding the check-on-shut-down:
It is an interesting idea, but care should be taken in special cases such as
UPS initiated shut-down or low battery laptops - it would be awful to lose
power in the middle of a fsck.
Another idea would be to have a time-based forced fsck. This should be
benefici
I've just done a fresh openSUSE 10.3 install and I can confirm that
ma2412ma is right - ext3 partitions seemingly do not have their mount
count/check dates disabled by default on SUSE. However, the max mount
count on the partition newly made during install was 500 and the check
interval was set for
An alternative idea:
https://wiki.ubuntu.com/AutoFsck
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@li
First off, a periodic fsck does not address the problem of data
integrity. It's there to make sure that the filesystem is consistent.
It's just a repair _attempt_ that occurs long after the damage has been
done.
Anyway, both data integrity and filesystem consistency are just fine with Ext3
on mod
(Subscribing feld so that reply is seen
To new people (not feld!) who contribute to this bug - if you are participating
in this discussion by posting comments that might lead to follow ups please
subscribe yourself to this bug so that people have a means in which to follow
up)
feld:
Do you disa
Data integrity is SO 2007.
Let's keep it that way.
Disabling this is risking instability and loss of data if there are
hardware faults.
This minor "inconvenience" could save someone. Better safe than sorry.
Speed should NEVER be sacrificed for correctness or data integrity.
If this check is too
ehh I meant that the other way around.
Correctness and data integrity should NEVER be sacrificed for speed.
You get the point.
Do the right thing devs.
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are
Well, Ubuntu is not the only distribution - openSUSE is also doing it
(I'm gonna have to file a bug report there as well). Other than that, I
fully agree with Florin. What about creating an option in the control
center that allows the user to enable and disable the periodic fsck? The
default value
This is truly very annoying and completely pointless. Ext3 on modern kernels is
very robust. There's no need for extra paranoia every 30 reboots.
In fact, Ubuntu is the only distribution that I'm using that does this. If
periodic fsck would truly be needed, I would notice file system corruption o
All good points. Ok, back to the drawing board. Thanks Sitsofe :-)
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
u
(I still say that turning off the fsck is the "modern" thing to do
though)
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
I think any suggestion about warning the user before doing the fsck is
probably better off in Bug #22460 . However since people are discussing
stuff here...
Mark:
Oof. This sounds a dangerous because if an fsck stops that almost certainly
means it needed user intervention to work out what to do n
Running fsck on shutdown is an interesting idea, if it can easily be
quit and done the next time, and the user is told of any problems on the
next boot.
In general, you should be able to walk away from the shutdown and know
that the shutdown will actually complete regardless.
If the user gets th
In my opinion, the best solution is to make fsck run on *shutdown*
rather than on boot-up. The rationale behind this is that people usually
turn on their computers to do something with it. At those times, people
want their computers to boot up as fast as possible.
Conversely, people usually do not
If the disk checking behavior cannot be changed (forcing you to wait 10
minutes or more during boot), then the default should be off. No force
disk checking every Xth time you boot.
There are times when you need to use your computer now. For example a
presentation or a class. In fact that is th
** Tags added: ext3
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu
** Changed in: partman-ext3 (Ubuntu)
Assignee: Colin Watson => (unassigned)
--
New ext3 partitions should not have max-mount count
https://bugs.launchpad.net/bugs/3581
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs m
Still here on a system with a disk whose partition table was created
from scratch with the Ubuntu Feisty herd 5 alternate install CD.
--
New ext3 partitions should not have max-mount count
https://launchpad.net/bugs/3581
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubu
41 matches
Mail list logo
