Discussion:
Skipping fsck during boot with systemd?
Eduardo Nogueira
2014-12-05 17:04:14 UTC
Permalink
With init, skipping a scheduled fsck during boot was easy, you just pressed
Ctrl+c, it was obvious! Today I was late for an online conference. I got
home, turned on my computer, and systemd decided it was time to run fsck on my
1TB hard drive. Ok, I just skip it, right? Well, Ctrl+c does not work, ESC
does not work, nothing seems to work. I Googled for an answer on my phone but
nothing. So, is there a mysterious set of commands they came up with to skip an
fsck or is it yet another flaw?
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@web121601.mail.ne1.yahoo.com
Brian
2014-12-05 18:05:15 UTC
Permalink
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just pressed
Ctrl+c, it was obvious! Today I was late for an online conference. I got
home, turned on my computer, and systemd decided it was time to run fsck on my
1TB hard drive. Ok, I just skip it, right? Well, Ctrl+c does not work, ESC
does not work, nothing seems to work. I Googled for an answer on my phone but
nothing. So, is there a mysterious set of commands they came up with to skip an
fsck or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
The Wanderer
2014-12-05 18:43:32 UTC
Permalink
Post by Brian
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just
pressed Ctrl+c, it was obvious! Today I was late for an online
conference. I got home, turned on my computer, and systemd decided
it was time to run fsck on my 1TB hard drive. Ok, I just skip it,
right? Well, Ctrl+c does not work, ESC does not work, nothing seems
to work. I Googled for an answer on my phone but nothing. So, is
there a mysterious set of commands they came up with to skip an
fsck or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
That lets you prevent systemd from running fsck in the first place.

Unless I'm greatly misunderstanding what I've read so far, it does not
let you cancel a systemd-initiated boot-time fsck which is already in
progress.

Discussion found via Google seems to indicate that even Ctrl-Alt-Delete
or the power button (short of the hard-power-off form, which can corrupt
the filesystem being checked) will be ignored by systemd while such a
fsck is in progress.

https://bugzilla.redhat.com/show_bug.cgi?id=719952 seems like it might
be related.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Alex Mestiashvili
2014-12-05 19:31:13 UTC
Permalink
Post by The Wanderer
Post by Brian
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just
pressed Ctrl+c, it was obvious! Today I was late for an online
conference. I got home, turned on my computer, and systemd decided
it was time to run fsck on my 1TB hard drive. Ok, I just skip it,
right? Well, Ctrl+c does not work, ESC does not work, nothing seems
to work. I Googled for an answer on my phone but nothing. So, is
there a mysterious set of commands they came up with to skip an
fsck or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
That lets you prevent systemd from running fsck in the first place.
Unless I'm greatly misunderstanding what I've read so far, it does not
let you cancel a systemd-initiated boot-time fsck which is already in
progress.
Discussion found via Google seems to indicate that even Ctrl-Alt-Delete
or the power button (short of the hard-power-off form, which can corrupt
the filesystem being checked) will be ignored by systemd while such a
fsck is in progress.
https://bugzilla.redhat.com/show_bug.cgi?id=719952 seems like it might
be related.
wow, systemd even disables SysRq by default: #725422
Good to know. Luckily it was fixed in Debian.
But this is imho insane, why one would override such stuff?? I start to
understand systemd haters :)
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@biotec.tu-dresden.de
Brian
2014-12-05 20:59:25 UTC
Permalink
Post by The Wanderer
Post by Brian
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just
pressed Ctrl+c, it was obvious! Today I was late for an online
conference. I got home, turned on my computer, and systemd decided
it was time to run fsck on my 1TB hard drive. Ok, I just skip it,
right? Well, Ctrl+c does not work, ESC does not work, nothing seems
to work. I Googled for an answer on my phone but nothing. So, is
there a mysterious set of commands they came up with to skip an
fsck or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
That lets you prevent systemd from running fsck in the first place.
True
Post by The Wanderer
Unless I'm greatly misunderstanding what I've read so far, it does not
let you cancel a systemd-initiated boot-time fsck which is already in
progress.
True

But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".

One could even set up two GRUB entries for the choices. An extra
keystroke or two and one get exactly what one wants. Isn't choice and
control a wonderful thing?

The OP wants, of course, to have some rescue route from having made a
bad choice. I wish it had been available when I used fdisk on the
wrong disk some time ago.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
Renaud (Ron) OLGIATI
2014-12-05 22:06:50 UTC
Permalink
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?

Cheers,

Ron.
--
Whoever said "laughter is the best medicine" never had lumbago.

-- http://www.olgiati-in-paraguay.org --
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ron.cerrocora.org
Brian
2014-12-05 23:16:47 UTC
Permalink
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
Lisi Reisz
2014-12-06 06:42:50 UTC
Permalink
Post by Brian
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again.
Eduardo was late! Haven't you ever been late for anything and wanted to speed
something up??

Most of us are human and make occasional mistakes.

Lisi
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Brian
2014-12-06 09:44:38 UTC
Permalink
Post by Lisi Reisz
Post by Brian
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again.
Eduardo was late! Haven't you ever been late for anything and wanted to speed
something up??
His lateness and the scheduled fsck do not appear to be correlated. A
technique to speed things up has been given.
Post by Lisi Reisz
Most of us are human and make occasional mistakes.
It is evident from this thread that the ability to abort an in-progress
fsck during boot may not be available yet (although the links given
indicate some untested possibilities). Another suggestion would be to
have a system detect an impending fsck and have it substitute a grub.cfg
with "fsck.mode=skip" in it for the next boot.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
Lisi Reisz
2014-12-06 10:10:05 UTC
Permalink
Post by Brian
Post by Lisi Reisz
Post by Brian
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One
can choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an
inconvenient moment ?
Remedial action is not needed because the right choice was made from
the grub menu. If it wasn't, you get to live with the consequences and
don't do it again.
Eduardo was late! Haven't you ever been late for anything and wanted to
speed something up??
His lateness and the scheduled fsck do not appear to be correlated. A
technique to speed things up has been given.
But his lateness and his desire to interrupt the fsck on that particular
occasion are directly causally linked. To say "Your mistake. You should
have done so and so. You must live with the consequences if you didn't." is
neither very pleasant nor very helpful. As I say, most of us are human and
make mistakes sometimes.

Eduardo probably usually wants fsck to run. Just not on that occasion. So
your "solution" didn't even solve the problem.

Lisi
Post by Brian
Post by Lisi Reisz
Most of us are human and make occasional mistakes.
It is evident from this thread that the ability to abort an in-progress
fsck during boot may not be available yet (although the links given
indicate some untested possibilities). Another suggestion would be to
have a system detect an impending fsck and have it substitute a grub.cfg
with "fsck.mode=skip" in it for the next boot.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Brian
2014-12-06 11:27:24 UTC
Permalink
Post by Lisi Reisz
Post by Brian
Post by Lisi Reisz
Post by Brian
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One
can choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an
inconvenient moment ?
Remedial action is not needed because the right choice was made from
the grub menu. If it wasn't, you get to live with the consequences and
don't do it again.
Eduardo was late! Haven't you ever been late for anything and wanted to
speed something up??
His lateness and the scheduled fsck do not appear to be correlated. A
technique to speed things up has been given.
But his lateness and his desire to interrupt the fsck on that particular
occasion are directly causally linked. To say "Your mistake. You should
have done so and so. You must live with the consequences if you didn't." is
neither very pleasant nor very helpful. As I say, most of us are human and
make mistakes sometimes.
Eduardo probably usually wants fsck to run. Just not on that occasion. So
your "solution" didn't even solve the problem.
Lisi
Post by Brian
Post by Lisi Reisz
Most of us are human and make occasional mistakes.
It is evident from this thread that the ability to abort an in-progress
fsck during boot may not be available yet (although the links given
indicate some untested possibilities). Another suggestion would be to
have a system detect an impending fsck and have it substitute a grub.cfg
with "fsck.mode=skip" in it for the next boot.
In what way does having two grub entries not answer the need to have
fsck run most of the time but not run on occasions which are deemed
inconvenient?

A third suggestion is to use grub's scripting to present the user with
a choice of a fsck or not.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
The Wanderer
2014-12-06 12:21:30 UTC
Permalink
(Quoting reordered slightly to make more what-replies-to-what sense.)
Post by Brian
Post by Lisi Reisz
Post by Brian
His lateness and the scheduled fsck do not appear to be
correlated. A technique to speed things up has been given.
But his lateness and his desire to interrupt the fsck on that
particular occasion are directly causally linked. To say "Your
mistake. You should have done so and so. You must live with the
consequences if you didn't." is neither very pleasant nor very
helpful. As I say, most of us are human and make mistakes
sometimes.
Eduardo probably usually wants fsck to run. Just not on that
occasion. So your "solution" didn't even solve the problem.
In what way does having two grub entries not answer the need to have
fsck run most of the time but not run on occasions which are deemed
inconvenient?
In that it doesn't help when you picked the wrong grub entry, whether
because you didn't know that a possible later fsck would not be
interruptible or because you forgot that a fsck might happen or because
you forgot that the option to pick the different grub entry might be
available or because you were in too much of a hurry or because you
simply missed the "automatically boot the default option" timeout.

Both the ability to decide against doing something in advance, and the
ability to abort that thing after the fact, are useful options to have.
They address different aspects of the same need and the same problem.

Being able to decide in advance "don't fsck this time" does not in any
way make it less useful, or less reasonable, to be able to cancel a fsck
which has already started. Both options are useful, and both are
reasonable choices to have.
Post by Brian
Post by Lisi Reisz
Post by Brian
It is evident from this thread that the ability to abort an
in-progress fsck during boot may not be available yet (although
the links given indicate some untested possibilities). Another
suggestion would be to have a system detect an impending fsck and
have it substitute a grub.cfg with "fsck.mode=skip" in it for the
next boot.
A third suggestion is to use grub's scripting to present the user
with a choice of a fsck or not.
I am dubious about whether reliably detecting an impending fsck in this
way is practical, or maybe even possible, from the environment which is
available from that stage of the boot process.

Do you have any suggestions about a way to actually implement this?
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Brian
2014-12-06 20:09:13 UTC
Permalink
Post by The Wanderer
(Quoting reordered slightly to make more what-replies-to-what sense.)
Post by Brian
Post by Lisi Reisz
Post by Brian
His lateness and the scheduled fsck do not appear to be
correlated. A technique to speed things up has been given.
But his lateness and his desire to interrupt the fsck on that
particular occasion are directly causally linked. To say "Your
mistake. You should have done so and so. You must live with the
consequences if you didn't." is neither very pleasant nor very
helpful. As I say, most of us are human and make mistakes
sometimes.
Eduardo probably usually wants fsck to run. Just not on that
occasion. So your "solution" didn't even solve the problem.
In what way does having two grub entries not answer the need to have
fsck run most of the time but not run on occasions which are deemed
inconvenient?
In that it doesn't help when you picked the wrong grub entry, whether
because you didn't know that a possible later fsck would not be
interruptible or because you forgot that a fsck might happen or because
you forgot that the option to pick the different grub entry might be
available or because you were in too much of a hurry or because you
simply missed the "automatically boot the default option" timeout.
I have the same reaction to the rm command (with or without the "-i"
option). Forgetfulness, lack of attention or haste have all lead to my
regretting hitting a key when I did.

People tell me pleasantly that one of life's little quirks is having to
live with the consequences of one's actions. I've been know to get a bit
shirty with that remark, but the passage of time has usually allowed me
to put some perspective on it.
Post by The Wanderer
Both the ability to decide against doing something in advance, and the
ability to abort that thing after the fact, are useful options to have.
They address different aspects of the same need and the same problem.
Being able to decide in advance "don't fsck this time" does not in any
way make it less useful, or less reasonable, to be able to cancel a fsck
which has already started. Both options are useful, and both are
reasonable choices to have.
I agree that both options are useful. The problem is that the second
option doesn't exist yet. Regession or not, this leaves a determined
user with seeking another solution.
Post by The Wanderer
Post by Brian
Post by Lisi Reisz
Post by Brian
It is evident from this thread that the ability to abort an
in-progress fsck during boot may not be available yet (although
the links given indicate some untested possibilities). Another
suggestion would be to have a system detect an impending fsck and
have it substitute a grub.cfg with "fsck.mode=skip" in it for the
next boot.
A third suggestion is to use grub's scripting to present the user
with a choice of a fsck or not.
I am dubious about whether reliably detecting an impending fsck in this
way is practical, or maybe even possible, from the environment which is
available from that stage of the boot process.
Do you have any suggestions about a way to actually implement this?
The system echos '#GRUB_FSCK="yes"' to /etc/default/grub when a fsck is
due. The code in grub.cfg checks for the existence of this line and
boots with "fsck.mode=skip" if it is found. An 'if..;then...;else...;fi'
should do it.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
Renaud (Ron) OLGIATI
2014-12-06 13:23:06 UTC
Permalink
On Sat, 6 Dec 2014 11:27:24 +0000
Post by Brian
A third suggestion is to use grub's scripting to present the user with
a choice of a fsck or not.
Another thing to consider: lets say that the system runs fsck once every 50 reboots (figure grabbed out of thin air), and that you may want to abort fsck once in 10 of the cases when fsck would be run. Remember the system cannot know before starting whether it will run fsck or not.

Means you will want to abort fsck once in 500 reboots.

The other 499 times, your proposed "user choice" will be a useless annoyance and waste of time to the user.

Better allow for the interruption of fsck to reduce the buggeration level all around.

Cheers,

Ron.
--
I shall pass through this world but once.
Any good therefore that I can do, let me do now,
For I shall not pass this way again.
-- Stephen Grellet

-- http://www.olgiati-in-paraguay.org --
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ron.cerrocora.org
Jarle Aase
2014-12-06 07:23:24 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Brian
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an
inconvenient moment ?
Post by Brian
Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again.
This is exactly the kind of arrogance that have made Windows 8 a total
disaster for Microsoft. I once convinced Windows 8 to stop a forced,
non-interruptible upgrade, by slamming the laptop in the table until the
hard-disk died.

Such arrogance will probably work just fine for systemd as well.

Jarle

- --
Jarle Aase email: ***@jgaa.com
Author of Free Software. http://www.jgaa.com

War FTP Daemon: http://www.warftp.org
Other free software: http://products.jgaa.com

NB: If you reply to this message, please include all relevant
information from the conversation in your reply. Thanks.
<<< no need to argue - just kill'em all! >>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUgq7sAAoJECdIPpCNC8tyJEMQAI3s7D1CuDBvoTZkHeGL6C1Y
O6OTo2u2o3gJd5mByTfE1O/1GTkxRQYV+NMhmlp52E9mVTMokVjJ9r+3835GHD3l
LjGEauQZs3zAQp3/Y2Go8OfL/xCYwSBVLcZou+zudBbeyJcVQp13Zqyp30D2zehw
HPFO0TVCrf/n+1nHCER6T+yI9EpbfUiN72ImpWi374yrYrHyK2zsA3YC1y6lntLn
2JjGT2Cc+AGhKydUVr6Y+W+YQ4OdyHtvZM56f41GscF2OXZeXM23oECDA6GwqyU/
KQFTN5OumRjnBEGsMmmh3axCCIQvuC3GNuAw0w3+Y69+ILSKwJVccoUhw8fpUDiO
wQvRiVS3NGKVzc5vp9ks1XYHmylWxESBnFjwGOBc3KCAK9bJht0Mo5p3E//fB8sD
MlWGsnyg9qssNMcGiS4qiyVG1x/CCJieJUxAp4kqezNZJicQP2ko0bTtlZzFWHiO
Id26ac3eZqoxZCrMtl6lyHroHuOE+hcx2IyC5SJ5i0Bpzxbyetu+p0qTUJKqQsTh
9o6lqbWPwdfNB394NG4YO/RnvYdALBemPNqqgPWEdkp5MndZsZlFalZ0KLRbc2ZM
AxHOZE9noKB4SyDVISMZxLaSnh7iegpN1kadqesEfUnqXGS7YNyhiVPvB4masIdQ
Ccz1OwFA9Oym3csWxR9P
=84Mp
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@jgaa.com
Curt
2014-12-06 10:29:40 UTC
Permalink
Post by Jarle Aase
This is exactly the kind of arrogance that have made Windows 8 a total
disaster for Microsoft. I once convinced Windows 8 to stop a forced,
non-interruptible upgrade, by slamming the laptop in the table until the
hard-disk died.
This is a clear demonstration of maturity in dealing with life's little
contrarieties; I only wanted to point out that you might have obtained an
even more definitive and successful result if you had used your head.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@einstein.electron.org
Bonno Bloksma
2014-12-08 10:51:01 UTC
Permalink
Hi Brian,
Post by Renaud (Ron) OLGIATI
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Remedial action is not needed because the right choice was made from the grub menu. If it wasn't, you get to live with the consequences and don't do it again.
I guess you never were in a hurry to get a system up and running again during production hours where a fschk takes a looong time. As normally a reboot takes place at night and I DO want a fschk to be performed at that time if needed this is the default boot option.

So in your opinion everyone with a production system needs a third grub line apart from the 2 default lines. If that many people NEED it then why is it not a default 3rd line in all installations?
Also, just about "never" will that fschk start when I do a manual reboot so why would I remember to choose option 3 at the reboot.
Also... a server nowadays takes minutes for the hardware check to complete a reboot, after that I have only 5 seconds to select the proper boot option in your scenario. Or do you want me to lengthen ALL reboots by lengthening the Grub boot screen?

All of this was never necessary as we could cancel an unneeded fschk that was merely performed because a certain number of days had passed. That was the proper way, to take action when it is needed. Not to allways take action in preemptive way in a short (seconds) windows when it is almost never needed.

I hope this clarifies things a bit, I hope we get the option back to stop a scheduled fschk that is performed at an inconvenient moment.


Met vriendelijke groet,
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@EinExch-01.tio.nl
Brian
2014-12-08 14:40:30 UTC
Permalink
Post by Bonno Bloksma
Hi Brian,
Post by Brian
Post by Renaud (Ron) OLGIATI
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Remedial action is not needed because the right choice was made from
the grub menu. If it wasn't, you get to live with the consequences
and don't do it again.
I guess you never were in a hurry to get a system up and running again
during production hours where a fschk takes a looong time. As normally
a reboot takes place at night and I DO want a fschk to be performed at
that time if needed this is the default boot option.
I think you might want to investigate using GRUB's datehook module, It
will allow changing the default boot option depending on the date and
the time of day. It looks ideal for doing what you describe.
Post by Bonno Bloksma
So in your opinion everyone with a production system needs a third
grub line apart from the 2 default lines. If that many people NEED it
then why is it not a default 3rd line in all installations? Also,
just about "never" will that fschk start when I do a manual reboot so
why would I remember to choose option 3 at the reboot. Also... a
server nowadays takes minutes for the hardware check to complete a
reboot, after that I have only 5 seconds to select the proper boot
option in your scenario. Or do you want me to lengthen ALL reboots by
lengthening the Grub boot screen?
No, that is not my opinion. The solution you refer to may not suit
everyone. But there are another five to consider. :)
Post by Bonno Bloksma
All of this was never necessary as we could cancel an unneeded fschk
that was merely performed because a certain number of days had passed.
That was the proper way, to take action when it is needed. Not to
allways take action in preemptive way in a short (seconds) windows
when it is almost never needed.
I hope this clarifies things a bit, I hope we get the option back to
stop a scheduled fschk that is performed at an inconvenient moment.
I too hope it comes back. Meanwhile, you are stll faced with preventing
a scheduled fsck from going ahead.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
Ric Moore
2014-12-06 05:27:35 UTC
Permalink
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
What is wrong with an fsck?? You've never had an fsck happen without
your permission before at boot time?? Isn't it a good thing to have
happen once in a blue moon?? Jimminy Crickets, be glad you aren't
defragging like Win users have had to put up with for eons. Just think
of it as a "prophylactic measure" and play safe. Be glad, instead, that
someone is looking out for you. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
The Wanderer
2014-12-06 12:30:21 UTC
Permalink
Post by Ric Moore
Post by Renaud (Ron) OLGIATI
Post by Brian
But remember our current slogan "Linux is all about choice". One
can choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an
inconvenient moment ?
What is wrong with an fsck?? You've never had an fsck happen without
your permission before at boot time?? Isn't it a good thing to have
happen once in a blue moon??
The problem is not an fsck, but having a fsck happen _right then_, when
you need the computer for something else. Schedules and deadlines are a
thing.

E.g., if you're booting up to deliver a presentation at an important
meeting, the VIPs who are present are unlikely to be impressed or
patient if you have to wait ten minutes or more for the fsck to
complete.

I've seen people complain about that exact scenario in bug reports,
including I think in the Debian bug report which someone identified
earlier in this thread.

Or, as with the OP in this thread, if you're booting up to attend a
live-streaming realtime event (such as a voice-chat meeting) which is
scheduled to happen at a specific time).

Yes, you could potentially have avoided that by passing the new "skip
fsck" option on the kernel command line - but even if you didn't do that
for whatever reason (including simply having forgotten about it,
possibly due to being in a hurry), you should still have the option to
cancel the in-progress fsck, just as has been possible under sysvinit
for most of a decade at least.


From the perspective of systemd, this may be a request for a new
feature, and hence a wishlist-level bug.

But from the perspective of a Debian user (who, as people have
repeatedly reminded us, may not know or care what init system their
computer is using), this is a regression, in that a feature which Debian
used to provide is no longer available. That regression status is, or at
least IMO should be considered, enough to qualify what would otherwise
be a wishlist item as a more serious bug.
Post by Ric Moore
Jimminy Crickets, be glad you aren't defragging like Win users have
had to put up with for eons.
Unless things have changed from Win7 to Win8, current Windows
defragmentation doesn't prevent you from using your computer while it's
going on; it just slows the computer down while the defrag is in
progress. I use Windows 7 at work, and I can say that I've literally
never noticed a scheduled defragmentation occurring - either on Win7 or
on WinXP.

And even Windows boot-time CHKDSK or whatever they call it nowadays
gives you a few seconds of warning before it starts, with the option to
cancel (or, rather, postpone) the disk check. IIRC from bug discussion,
current systemd doesn't even provide that.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Mart van de Wege
2014-12-06 13:58:57 UTC
Permalink
Post by The Wanderer
Post by Ric Moore
Post by Renaud (Ron) OLGIATI
Post by Brian
But remember our current slogan "Linux is all about choice". One
can choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
What is wrong with an fsck?? You've never had an fsck happen without
your permission before at boot time?? Isn't it a good thing to have
happen once in a blue moon??
The problem is not an fsck, but having a fsck happen _right then_, when
you need the computer for something else. Schedules and deadlines are a
thing.
(all instances of 'you' and 'your' are meant generically)

Well, it is not as if fscks happen out of the blue. Either you weren't
paying attention and you were hit with the periodic fsck, or you make a
habit of doing dirty shutdowns, and you know the fsck is going to happen
anyway.

Yes, if you were not paying attention, it may feel as a surprise. And if
you are used to the bad habit of interrupting fsck, then not being able
to may feel as a bad surprise, but the problem is still *your* bad
habits.

Mistakes happen, we're all human. Blaming your tools for your own
mistakes is another bad habit though.

Imagine his file system was corrupted. Interrupting fsck wouldn't have
helped, his computer would have been unavailable anyway.

Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gaheris.avalon.lan
seeker5528
2014-12-07 05:22:15 UTC
Permalink
Post by Mart van de Wege
Well, it is not as if fscks happen out of the blue. Either you weren't
paying attention and you were hit with the periodic fsck, or you make
a habit of doing dirty shutdowns, and you know the fsck is going to
happen anyway.
Assuming your partitions are set to fsck every X number of days, unless
you keep track of how many boots you
have done, I would say it is out of the blue.

Don't know when/where I was presented the option about how often the
fsck should be ran, but I didn't want all
my partitions set to fsck on the same day, so I chose a different number
of days for each partition. Sometimes it
might be 1 boot between, sometimes 28. That is assuming the X number of
days setting didn't get reset to some
default along the way.
Post by Mart van de Wege
Yes, if you were not paying attention, it may feel as a surprise. And if
you are used to the bad habit of interrupting fsck, then not being able
to may feel as a bad surprise, but the problem is still *your* bad
habits.
Skipping one time because you are late for something doesn't make a habit.

Personally I'm more annoyed that instead of only sending me to single
user mode if something is hinky with the
root partition, now if I I forget to plug in one of my secondary drives,
or delete a partition and don't take it out of
the fstab before I reboot, I am sent to a single user login. D'oh.

Later, Seeker
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@comcast.net
Curt
2014-12-07 10:23:42 UTC
Permalink
Post by seeker5528
Post by Mart van de Wege
Well, it is not as if fscks happen out of the blue. Either you weren't
paying attention and you were hit with the periodic fsck, or you make
a habit of doing dirty shutdowns, and you know the fsck is going to
happen anyway.
Assuming your partitions are set to fsck every X number of days, unless
you keep track of how many boots you
have done, I would say it is out of the blue.
Holy shit what a hacker.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@einstein.electron.org
Mart van de Wege
2014-12-07 23:37:01 UTC
Permalink
Post by seeker5528
Post by Mart van de Wege
Well, it is not as if fscks happen out of the blue. Either you
weren't paying attention and you were hit with the periodic fsck, or
you make a habit of doing dirty shutdowns, and you know the fsck is
going to happen anyway.
Assuming your partitions are set to fsck every X number of days,
unless you keep track of how many boots you
have done, I would say it is out of the blue.
Look, if you reboot a laptop instead of suspending/hibernating it,
sooner or later you're going to have to think "Hmm, it hasn't fscked for
a while". It shouldn't be a surprise when it does.

It is a small mistake, not worth bothering about, unless of course you
persist in disclaiming your own responsibility and blaming your tools.

Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gaheris.avalon.lan
The Wanderer
2014-12-08 01:29:37 UTC
Permalink
Post by Mart van de Wege
Post by seeker5528
Post by Mart van de Wege
Well, it is not as if fscks happen out of the blue. Either you
weren't paying attention and you were hit with the periodic fsck,
or you make a habit of doing dirty shutdowns, and you know the
fsck is going to happen anyway.
Assuming your partitions are set to fsck every X number of days,
unless you keep track of how many boots you have done, I would say
it is out of the blue.
Look, if you reboot a laptop instead of suspending/hibernating it,
sooner or later you're going to have to think "Hmm, it hasn't fscked
for a while". It shouldn't be a surprise when it does.
Of course not.

But you may not be expecting it to happen *this* time - just that it
will happen at some point.

And you should still be able to cancel / abort it when it does happen,
and just have it happen again next time - just in case that's the best
option for the circumstances at hand.

If that results in you shooting yourself in the foot over the long term,
then that's your problem, because you made the decision to prioritize
the immediate benefit of cancelling the fsck over the long-term benefit
of letting it run.

But you should still be able to shoot yourself in the foot that way,
precisely because what is shooting yourself in the foot in one situation
can be exactly the right thing to do in another.

Linux (and *nix in general, AFAIK) has never tried to prohibit the
sysadmin from shooting him- or herself in the foot. Warn against it,
maybe, although not always even that (try 'rm -rf /' as root on a
machine you don't care about sometime; make sure you don't have any
network shares mounted!) - but prohibit or otherwise outright prevent
it, no.
Post by Mart van de Wege
It is a small mistake, not worth bothering about,
That depends on its consequences, which in some circumstances can be
significant enough to be worth caring about.
Post by Mart van de Wege
unless of course you persist in disclaiming your own responsibility
and blaming your tools.
Huh??

This seems almost backwards.

If you can abort the in-progress fsck, then by doing so you assume
responsibility for the consequences of doing it.

If you can't abort the in-progress fsck, then where does "your
responsibility" come into it?
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
seeker5528
2014-12-08 02:37:48 UTC
Permalink
Post by Mart van de Wege
Look, if you reboot a laptop instead of suspending/hibernating it,
sooner or later you're going to have to think "Hmm, it hasn't fscked
for a while". It shouldn't be a surprise when it does.
That brings up a whole different question about whether the better
option would be fsck after X number of
days instead of X number of boots.
Post by Mart van de Wege
Of course not.
But you may not be expecting it to happen *this* time - just that it
will happen at some point.
And you should still be able to cancel / abort it when it does happen,
and just have it happen again next time - just in case that's the best
option for the circumstances at hand.
If that results in you shooting yourself in the foot over the long term,
then that's your problem, because you made the decision to prioritize
the immediate benefit of cancelling the fsck over the long-term benefit
of letting it run.
If the option to cancel is there, then the resulting failure to do a
complete fsck should mean that fsck get run
again on the next boot. So there should be no foot shooting unless the
choice is consciously made to cancel
the fsck on every following boot.

Later, Seeker
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@comcast.net
Martin Read
2014-12-08 11:38:15 UTC
Permalink
Post by The Wanderer
If that results in you shooting yourself in the foot over the long term,
then that's your problem, because you made the decision to prioritize
the immediate benefit of cancelling the fsck over the long-term benefit
of letting it run.
My experience of running Linux on my personal local interactive (rather
than server) systems over the past eighteen years leads me to believe
that the long-term benefit of *prophylactic* fsck invocations triggered
by mount-count or interval-since-check is approximately zero, since
*those* invocations of fsck have never discovered FS corruption on my
systems.

I mean, sure, I've *had* filesystem corruption on my personal local
interactive Linux systems - but it was always in a scenario of "hardware
failure" or "unclean shutdown".

Other people's experience may, of course, be different.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@zen.co.uk
Brian
2014-12-08 11:39:03 UTC
Permalink
Post by The Wanderer
Post by Mart van de Wege
It is a small mistake, not worth bothering about,
That depends on its consequences, which in some circumstances can be
significant enough to be worth caring about.
Indeed. And caring enough about it implies doing something positive
about it.
Post by The Wanderer
Post by Mart van de Wege
unless of course you persist in disclaiming your own responsibility
and blaming your tools.
Huh??
This seems almost backwards.
If you can abort the in-progress fsck, then by doing so you assume
responsibility for the consequences of doing it.
If you can't abort the in-progress fsck, then where does "your
responsibility" come into it?
By not using the tools already in your possession to do something about
it.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
Stefan Monnier
2014-12-08 02:11:24 UTC
Permalink
Post by Mart van de Wege
Look, if you reboot a laptop instead of suspending/hibernating it,
sooner or later you're going to have to think "Hmm, it hasn't fscked for
a while". It shouldn't be a surprise when it does.
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...

So, yes, if I can't remember it happening last month I wouldn't find it
suspicious if it happens today, but maybe it actually won't happen for
another year and I wouldn't find it suspicious either.
Post by Mart van de Wege
It is a small mistake, not worth bothering about, unless of course you
persist in disclaiming your own responsibility and blaming your tools.
Having to wait half-an-hour just because the "do an fsck every once in
a while" happen to decide that "yeah, well, maybe we could do I today"
is just ridiculous.

The old "you can skip fsck by hitting C-c" was fine. Preventing it is
obnoxious. If they want to "clean up" the behavior, I could live with
a change such that when the time is up (either number of mounts, or time
since last fsck), the reboot could prompt the user (with a timeout since
there's always the chance that there's no human available to respond)
whether to perform the fsck this time or to postpone it to next reboot.


Stefan
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/jwvy4qioq1w.fsf-monnier+***@gnu.org
Curt
2014-12-08 08:44:07 UTC
Permalink
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?

http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@einstein.electron.org
Christian Groessler
2014-12-08 09:12:55 UTC
Permalink
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept the
fact.

After all, it's *my* computer, and *I* want to be in control of it.

regards,
chris
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@groessler.org
Renaud (Ron) OLGIATI
2014-12-08 09:59:13 UTC
Permalink
On Mon, 08 Dec 2014 10:12:55 +0100
Post by Christian Groessler
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept the
fact.
After all, it's *my* computer, and *I* want to be in control of it.
Because their mind-set is "We are Systemd of Borg, resistance is futile..." ?
(Or to go back further to the Immortal Bard's Hamlet: "The insolence of office")

But remember, while it is their ball, nothing can force us to continue playing with them once they impose their choice.

Just now I am giving Slackware a good look-over...

Cheers,

Ron.
--
Boob's Law:
You always find something in the last place you look.

-- http://www.olgiati-in-paraguay.org --
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ron.cerrocora.org
Andrei POPESCU
2014-12-08 10:29:54 UTC
Permalink
Post by Renaud (Ron) OLGIATI
On Mon, 08 Dec 2014 10:12:55 +0100
Post by Christian Groessler
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept the
fact.
After all, it's *my* computer, and *I* want to be in control of it.
Because their mind-set is "We are Systemd of Borg, resistance is futile..." ?
(Or to go back further to the Immortal Bard's Hamlet: "The insolence of office")
But remember, while it is their ball, nothing can force us to continue
playing with them once they impose their choice.
Just now I am giving Slackware a good look-over...
Reading two related bugs[1][2] on this issue it rather seems to me like
nobody has bothered to implement this, although it's on the TODO
list[3].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=719952
[2] https://bugzilla.redhat.com/show_bug.cgi?id=799574
[3] http://cgit.freedesktop.org/systemd/systemd/tree/TODO

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Brian
2014-12-08 11:08:47 UTC
Permalink
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
Please could we stick to the technical aspects of this problem. Attempts
to apportion responsibilty rarely lead anywhere.
Post by Christian Groessler
After all, it's *my* computer, and *I* want to be in control of it.
Curt's link brings the number of discussable solutions to four. Here is
a fifth (which might utilise the mountinfo script):

GRUB is made aware of an impending fsck. Booting thows it into a submenu
with the choice of doing a fsck or not. You control which route to take.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
Joel Rees
2014-12-09 00:04:38 UTC
Permalink
Post by Brian
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
Please could we stick to the technical aspects of this problem. Attempts
to apportion responsibilty rarely lead anywhere.
Technical? What exactly do you mean by technical?

It seems lately that the word "technical" in some contexts seems to have
developed the meaning "achievable by appropriate incantation."

That is not what I mean when I say "technical", at any rate.
Post by Brian
Post by Christian Groessler
After all, it's *my* computer, and *I* want to be in control of it.
Curt's link brings the number of discussable solutions to four. Here is
None of which address the real issue.

Some developer made a seemingly minor, seemingly "logical" change in
things, and the effect is that some user who had been depending on debian
stable to be stable found his computer unusable without advance warning in
a situation where he needed it.

Sure, in the real world, especially with consumer grade OSses, things like
this do sometimes happen. In the "real" world, expectations of high
availabilty have to be bought with expensive service contracts from
companies that are supposed to do all sorts of testing so that this kind of
thing doesn't happen to the paying customer.

Fedora users have been a volunteer group of testers, paid, essentially,
in-kind for their testing.

So debian users have been living in a dream world. Systemd marks the end of
that dream world.

That much, I'll grant you.
Post by Brian
GRUB is made aware of an impending fsck. Booting thows it into a submenu
with the choice of doing a fsck or not. You control which route to take.
This kind of thinking requires grub to be able to communicate with the OS
which it is booting after it releases control. In other words, grub has to
become a minimalistic OS. The grub group has been discussing that for
several years. Xen is one of the results of that discussion. But grub,
itself, is not there yet.

What I want to know is why you don't seem to be aware that your suggestion
is dependent on a possible future direction for grub, and cannot help
anyone now who wants to be able to predict when an fsck becomes impending,
to avoid an undesirable situation which had not existed before the upgrade
to Jesse with the recommended stock init for Jesse.

This is why we can call it unexpected: The fsck was expected, sure. But
being unable to stop the fsck was not expected, unless you happened to have
experienced it when it hit Fedora as part of systemd.

Not everyone here is a Fedora refugee.

Before you start crying about personal attacks, let me tell you that I
have, as a professional engineer, faced similar criticisms of my technical
choices at work. Facing this kind of criticism comes with the territory
when you choose an engineering field, because every engineer makes
mistakes. If an engineer reacts by blaming the user, he generally is told
he can look for another job, preferably in another field.

--
Joel Rees
Christian Groessler
2014-12-10 12:41:51 UTC
Permalink
It seems the discussion revolves around methods to disable an automatic
fsck when it
is not wanted.

It went away from an obvious solution (^C a running fsck) and suggests
compilcated and/or
convoluted workarounds, which have to be implemented or enabled proactively.

I want to get back to the root of the problem and claim, that I want to
be able to interrupt *any* startup
command, not just fsck.

Example:

On one of my machines, which tracks "unstable", the reboot after an
dist-upgrade
would hang when it tried to bring up the network interfaces. It waited
endlessly for
the network to come up. No possibilty to interrupt that, or to get to a
shell.
The only thing left was to hit the power button.

To get the machine to boot again, I had to enter the BIOS, disable the
network card there,
and reboot. After rebooting I disabled the interface in
/etc/network/interfaces.
Then I re-enabled the interface in the BIOS and after booting, I brought
the interface up
manually.

Quite a dance instead of just typing "^C"....

(The problem disappeared after a few days or weeks, so it probably was a
fallout on
"unstable". At least, I don't remember that I changed something to fix
it. Currently it's
booting fine with the interface enabled in /etc/network/interfaces.)

regards,
chris
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@groessler.org
Gian Uberto Lauri
2014-12-10 13:10:17 UTC
Permalink
Post by Christian Groessler
To get the machine to boot again, I had to enter the BIOS, disable the
network card there,
Hmmm... you could have tried with a single user mode bootstrap, that
could have avoided you going to the BIOS.
Post by Christian Groessler
Quite a dance instead of just typing "^C"....
^C could be unresponsive nevertheless, the process being stuck in kernel
space and thus completely oblivious of the signals thrown at it.
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mail.eng.it
Mart van de Wege
2014-12-08 11:04:36 UTC
Permalink
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
I understand it just fine. I just don't understand why this is a big
deal, as it could have been easily avoided.

This is a case of "Doctor, it hurts when I do this". "Well, don't do
that then".

Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gaheris.avalon.lan
Christian Groessler
2014-12-08 11:41:06 UTC
Permalink
Post by Mart van de Wege
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
I understand it just fine. I just don't understand why this is a big
deal, as it could have been easily avoided.
This is a case of "Doctor, it hurts when I do this". "Well, don't do
that then".
What shouldn't I do? Boot my system?

regards,
chris
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@groessler.org
Brian
2014-12-08 14:19:27 UTC
Permalink
Post by Christian Groessler
Post by Mart van de Wege
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
I understand it just fine. I just don't understand why this is a big
deal, as it could have been easily avoided.
This is a case of "Doctor, it hurts when I do this". "Well, don't do
that then".
What shouldn't I do? Boot my system?
Devise another way of working until the issue is eventually addressed?
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
Ric Moore
2014-12-08 18:08:44 UTC
Permalink
Post by Christian Groessler
Post by Mart van de Wege
Post by Christian Groessler
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
I understand it just fine. I just don't understand why this is a big
deal, as it could have been easily avoided.
This is a case of "Doctor, it hurts when I do this". "Well, don't do
that then".
What shouldn't I do? Boot my system?
use a journaling file system like ext4 ?? Of course that would require a
major backup and restore, but that would get you the closest to where
you want to be. How big is that harddrive any way?? It must be a monster
drive for fsck to be an major issue. like for this guy:
http://grokbase.com/t/centos/centos/119dg0by5y/how-to-stop-an-in-progress-fsck-that-runs-at-boot

...it is suggested there to use tune2fs (man tune2fs) before you shut
down to go do your public display and reset the fsck counter. So, you
can be in charge of your computer if you do it the way it likes you to
be in charge. I've been married 3 1/2 times and I can tell you from my
vast experience that a computer is little different from an ex-wife. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Henrique de Moraes Holschuh
2014-12-08 14:42:45 UTC
Permalink
Post by Christian Groessler
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
Handwaving issues away is intolerable behavior in a professional capacity,
but in this particular case you can just ignore the handwaving entirely, as
it is not being done professionaly, nor is it being done by either the
debian maintainers or upstream.

This thread should have died off the moment it became clear that handling
the interrupt signal in fsck _is_ in systemd's upstream todo file and also
reported as a bug that is still open and _not_ tagged wontfix in Debian.

The useful thing to do now is to come up with tested patches, file them on
the bug report, and start the process to get them reviewed and accepted.

We broke the signal delivery in sysvinit as well for a while, when we added
parallel execution (startpar). People would ^C and the signal would hit
some unintended process because there were several running at the same time,
all with the console open. This could break the boot horribly, of course.

The initial "fix" blocked all handlign of the interrupt signal, with pretty
much the same consequences as the current issue in systemd-fsck. I am not
sure how well it got fixed in the end on the sysvinit+startpar+fsck side, it
was some time ago.

The truth is that keyboard-raised signal delivery can be hard to get right
when you have both "parallel execution" and "console". And it can get
either much more difficult or much easier to do right when you have a
initsystem IO multiplexer front-end on top (i.e. stuff like plymouth).
Post by Christian Groessler
After all, it's *my* computer, and *I* want to be in control of it.
Yes, that's perfectly understandable.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@khazad-dum.debian.net
Lisi Reisz
2014-12-08 15:34:35 UTC
Permalink
Post by Henrique de Moraes Holschuh
We broke the signal delivery in sysvinit as well for a while, when we added
parallel execution (startpar).  People would ^C and the signal would hit
some unintended process because there were several running at the same
time, all with the console open.  This could break the boot horribly, of
course.
Thank you, Henrique!

Perhaps I wasn't being so thick when I couldn't interrupt fsck. :-/

I tried for a bit, but thenm gave up anf accepted taht it was notr piossible.

I can now use it until I go over to Jessie - and possibly quite soon after
that. I don't often want to do it anyway! But, unlike some people on this
list, I do occasionally make mistakes. :-(

Lisi
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Jerry Stuckle
2014-12-08 15:46:24 UTC
Permalink
Post by Henrique de Moraes Holschuh
Post by Christian Groessler
Why don't the systemd proponents understand that someone might want to
interrupt a running fsck? Don't scrutinize the reasons, just accept
the fact.
Handwaving issues away is intolerable behavior in a professional capacity,
but in this particular case you can just ignore the handwaving entirely, as
it is not being done professionaly, nor is it being done by either the
debian maintainers or upstream.
This thread should have died off the moment it became clear that handling
the interrupt signal in fsck _is_ in systemd's upstream todo file and also
reported as a bug that is still open and _not_ tagged wontfix in Debian.
I disagree. The original bug was filed on 2011-07-08 - almost 3.5 years
ago, and nothing has been done on it. And on 2012-05-06, there was an
acknowledgement that it is on the upstream's TODO list. That's over 2.5
years ago.

It obviously is causing a lot of people problems, and is not being fixed
in a timely manner. And if people don't talk about the problems it is
causing, chances are it's not going to be fixed in the near future.
Post by Henrique de Moraes Holschuh
The useful thing to do now is to come up with tested patches, file them on
the bug report, and start the process to get them reviewed and accepted.
That would be great if I had the time to learn systemd, figure out how
(and why) the ability to interrupt fsck was disabled, how to re-enable
it and ensure there are no side effects. Note that while I develop
custom device drivers and applications, I've never dug into the init
system, so it would be a large learning curve. That's days, if not
weeks that I don't have.

Or, the developer of systemd, who should be intimately familiar with his
code, could probably do it in a few minutes, or at most, a couple of
hours. But it's obviously not a high priority.
Post by Henrique de Moraes Holschuh
We broke the signal delivery in sysvinit as well for a while, when we added
parallel execution (startpar). People would ^C and the signal would hit
some unintended process because there were several running at the same time,
all with the console open. This could break the boot horribly, of course.
The initial "fix" blocked all handlign of the interrupt signal, with pretty
much the same consequences as the current issue in systemd-fsck. I am not
sure how well it got fixed in the end on the sysvinit+startpar+fsck side, it
was some time ago.
The truth is that keyboard-raised signal delivery can be hard to get right
when you have both "parallel execution" and "console". And it can get
either much more difficult or much easier to do right when you have a
initsystem IO multiplexer front-end on top (i.e. stuff like plymouth).
Hence the side effects I spoke of above.
Post by Henrique de Moraes Holschuh
Post by Christian Groessler
After all, it's *my* computer, and *I* want to be in control of it.
Yes, that's perfectly understandable.
I haven't been bitten by this bug yet, because I'm not running Jessie.
But it's just another reason why it's not good for servers, and even
causes major problems for users.

Jerry
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Frédéric Marchal
2014-12-08 09:28:47 UTC
Permalink
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
I'm joining in as Gentoo doesn't allow me to cancel fsck and it is a real
PITA. I much prefer the flexibility offered by Debian. If I'm in a hurry, I just
cancel fsck and restart the computer later to let it run fsck completely.

On my Gentoo box, the ext partition is set to scan the disk every 34 boots or
after 180 days. There is no way I can keep track of the number of boots as
three other people use that computer and turn it on when I'm not around. A
script wouldn't help either. What would it have to report to be of any use in
letting me know that the *next* boot will take one hour? Even I can't tell
when someone will need the computer.

With Debian, fsck starting during boot is the indicator that the next boot is
going to take a lot of time unless I can afford to let it run right now.

Please keep it that way!

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@wowtechnology.com
claude juif
2014-12-08 10:44:14 UTC
Permalink
2014-12-08 10:28 GMT+01:00 Frédéric Marchal <
Post by Frédéric Marchal
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
I'm joining in as Gentoo doesn't allow me to cancel fsck and it is a real
PITA. I much prefer the flexibility offered by Debian. If I'm in a hurry, I just
cancel fsck and restart the computer later to let it run fsck completely.
On my Gentoo box, the ext partition is set to scan the disk every 34 boots or
after 180 days. There is no way I can keep track of the number of boots as
three other people use that computer and turn it on when I'm not around. A
script wouldn't help either. What would it have to report to be of any use in
letting me know that the *next* boot will take one hour? Even I can't tell
when someone will need the computer.
Maybe you just have to make partitions. Il your rootfs is 1To it's gonna
take 2 hours to run fsck, but if you have smaller partition like
- / => 10G
- /usr => 10G
...
/data => 1To, it's gonna take 5 mins.

Just update your fsck to check only / and /usr so you know your system is
clean. And you can run run fsck yourself for /data.

So you are in control !

You can't ask developer to handle every single case of your life.

Regards,

Claude
Post by Frédéric Marchal
With Debian, fsck starting during boot is the indicator that the next boot is
going to take a lot of time unless I can afford to let it run right now.
Please keep it that way!
Frederic
--
with a subject of "unsubscribe". Trouble? Contact
Bonno Bloksma
2014-12-08 12:06:33 UTC
Permalink
Hello Claude,
Actually, it's *always* a surprise.  These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Maybe you just have to make partitions. Il your rootfs is 1To it's gonna take 2 hours to run fsck, but if you have smaller partition like
- /        => 10G
- /usr    => 10G
...
/data => 1To, it's gonna take 5 mins.
Just update your fsck to check only / and /usr so you know your system is clean. And you can run run fsck yourself for /data.
So how would I schedule a fsck of a single partition when I, and my other users, are asleep?
Write a script to do a umount, fsck, mount and start it with crond? When would I run that script, each day / week / month / ...? How much unneeded downtime would that create?
So you are in control !
You can't ask developer to handle every single case of your life. 
Actually, THAT is the very reason we ask for the option to be able to cancel a running fsck. You can never predict EVERY situation when fsck would be run but needed to be avoided.
Maybe I asked a non tech to simply turn on the machine, how technical does one need to be to do that. I would most certainly instruct such a person to NOT make any choices during boot but let it run with the default.
All those suggestions with auto changing the boot options would not help and the system would run fsck. With modern harddisk sizes that would pretty much guarantee that the disk would be >500GB or even >1TB. That person would then call me and I would know exactly what is going on but my only choice would be to say, touch luck, just wait. Too bad you will now be too late for .....

BTW I have been misspelling fsck as fschk in the few mails I sent today, that might give you some idea of how often I have to type that command. ;-)

Bonno Bloksm
claude juif
2014-12-08 12:45:39 UTC
Permalink
Hello Bonno (my bad i forget to say hello :( )

If you have some kind of monitoring system, you can monitor tune2fs output
and raise an alert if mount count is close to maximum mount count. So you
will be warned about fsck on next reboot, and you can delay it by adjusting
maximum mount count, or reset counter.

Anyway, i'm agree with you on some point, but the problem is only about
auto fsck, not about fsck on system failure.
Post by Bonno Bloksma
Hello Claude,
Post by claude juif
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay
set
Post by claude juif
Post by Stefan Monnier
to 172 days vs 194 days vs 98 days vs ...
Maybe you just have to make partitions. Il your rootfs is 1To it's gonna
take 2 hours to run fsck, but if you have smaller partition like
Post by claude juif
- / => 10G
- /usr => 10G
...
/data => 1To, it's gonna take 5 mins.
Just update your fsck to check only / and /usr so you know your system
is clean. And you can run run fsck yourself for /data.
So how would I schedule a fsck of a single partition when I, and my other
users, are asleep?
Write a script to do a umount, fsck, mount and start it with crond? When
would I run that script, each day / week / month / ...? How much unneeded
downtime would that create?
Post by claude juif
So you are in control !
You can't ask developer to handle every single case of your life.
Actually, THAT is the very reason we ask for the option to be able to
cancel a running fsck. You can never predict EVERY situation when fsck
would be run but needed to be avoided.
Maybe I asked a non tech to simply turn on the machine, how technical does
one need to be to do that. I would most certainly instruct such a person to
NOT make any choices during boot but let it run with the default.
All those suggestions with auto changing the boot options would not help
and the system would run fsck. With modern harddisk sizes that would pretty
much guarantee that the disk would be >500GB or even >1TB. That person
would then call me and I would know exactly what is going on but my only
choice would be to say, touch luck, just wait. Too bad you will now be too
late for .....
BTW I have been misspelling fsck as fschk in the few mails I sent today,
that might give you some idea of how often I have to type that command. ;-)
Bonno Bloksma
Ric Moore
2014-12-08 18:23:31 UTC
Permalink
Post by Bonno Bloksma
Actually, THAT is the very reason we ask for the option to be able to cancel a running fsck. You can never predict EVERY situation when fsck would be run but needed to be avoided.
Maybe I asked a non tech to simply turn on the machine, how technical does one need to be to do that. I would most certainly instruct such a person to NOT make any choices during boot but let it run with the default.
All those suggestions with auto changing the boot options would not help and the system would run fsck. With modern harddisk sizes that would pretty much guarantee that the disk would be >500GB or even >1TB. That person would then call me and I would know exactly what is going on but my only choice would be to say, touch luck, just wait. Too bad you will now be too late for .....
Keep in mind that interrupting fsck is regarded as a very very bad
practice by every link brought by a google search using key words
"interrupting fsck". All sorts of doom to your file system is predicted
in each. It's been that way since I first installed Linux via Slackware
floppies. I can't imagine ALL of them being stupid. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Henrique de Moraes Holschuh
2014-12-08 22:07:56 UTC
Permalink
Post by Ric Moore
Keep in mind that interrupting fsck is regarded as a very very bad
practice by every link brought by a google search using key words
Interrupting ext2/3/4 fsck while it is reading data structures is "safe" as
in it is not going to make anything worse.

I will not say the same about other filesystems, as I have no particular
knowledge of any others (well, there's XFS, but XFS has a do-nothing fsck,
and you'd have to run xfs_repair manually if you want its fsck-equivalent).

Interrupting fsck when it is *fixing* something is not safe on any
filesystem, nor is it a good idea to skip fsck when it is happening because
an unclean shutdown.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@khazad-dum.debian.net
Frédéric Marchal
2014-12-08 13:39:20 UTC
Permalink
2014-12-08 10:28 GMT+01:00 Frédéric Marchal
Post by Frédéric Marchal
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
I'm joining in as Gentoo doesn't allow me to cancel fsck and it is a real
PITA. I much prefer the flexibility offered by Debian. If I'm in a hurry, I just
cancel fsck and restart the computer later to let it run fsck completely.
On my Gentoo box, the ext partition is set to scan the disk every 34 boots or
after 180 days. There is no way I can keep track of the number of boots as
three other people use that computer and turn it on when I'm not around. A
script wouldn't help either. What would it have to report to be of any use in
letting me know that the *next* boot will take one hour? Even I can't tell
when someone will need the computer.
Maybe you just have to make partitions. Il your rootfs is 1To it's gonna
take 2 hours to run fsck, but if you have smaller partition like
- / => 10G
- /usr => 10G
...
/data => 1To, it's gonna take 5 mins.
Just update your fsck to check only / and /usr so you know your system is
clean. And you can run run fsck yourself for /data.
/, /var and /tmp already are very small partitions. The 1TB disk is
the home partition where all the important data are. I can't split it
up and I don't feel comfortable with the idea of running fsck only
when and if I remember to do it. The computer is there to serve me,
not the other way around!
So you are in control !
That's not being in control. That's doing chores the system is making
more difficult to deal with. I would rather spend the time doing
something with the computer than for the computer.
You can't ask developer to handle every single case of your life.
A feature was lost and I say it was useful to me and, apparently, a
bunch of people.

The proposals so far imply more bookkeeping and/or maintenance tasks
on my part. Maintenance tasks are necessary. But, in the case
discussed here, there used to be a simpler solution. I don't want the
developers to assume the current non-interruptible fsck solution is
satisfactory to everyone. Nor is the no-fsck-at-all solution
acceptable to everybody.

Now, I would accept a solution simpler than "let fsck run
automatically from time to time or press ctrl+c to run it later" but
none comes to my mind.

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/CAJ7R-8TEFj9Hzmw6dwM5yYH-Rqfd464pvdOx-ELsU82-***@mail.gmail.com
Martin Read
2014-12-08 11:41:51 UTC
Permalink
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay set
to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human
memory, like this little hacker here did?
There is *no legitimate basis* for arguing with the OP's complaint. The
systemd transition has caused a user interface regression, which should
be fixed.

I like systemd, but I do wish certain of its non-coding proponents would
stop indulging in incendiary defence of it against legitimate complaints.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@zen.co.uk
The Wanderer
2014-12-08 13:31:57 UTC
Permalink
Post by Martin Read
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long
enough intervals, that I can never know if it was "4 months ago"
or "7 months ago", and neither can I remember which
laptop/desktop has the delay set to 172 days vs 194 days vs 98
days vs ...
Can't you write a small script to obviate the limitations of your
human memory, like this little hacker here did?
There is *no legitimate basis* for arguing with the OP's complaint.
The systemd transition has caused a user interface regression, which
should be fixed.
I like systemd, but I do wish certain of its non-coding proponents
would stop indulging in incendiary defence of it against legitimate
complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Lisi Reisz
2014-12-08 14:09:19 UTC
Permalink
Post by The Wanderer
Post by Martin Read
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long
enough intervals, that I can never know if it was "4 months ago"
or "7 months ago", and neither can I remember which
laptop/desktop has the delay set to 172 days vs 194 days vs 98
days vs ...
Can't you write a small script to obviate the limitations of your
human memory, like this little hacker here did?
There is *no legitimate basis* for arguing with the OP's complaint.
The systemd transition has caused a user interface regression, which
should be fixed.
I like systemd, but I do wish certain of its non-coding proponents
would stop indulging in incendiary defence of it against legitimate
complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
I just wish that the subject were able to be rationally discussed, and that
people could have problems in Jessie and ask for help without starting a
systemd flame war, whether systemd in fact has anything to do with it or not.

Anyhow, I've gained something from this thread. I didn't know that I could
get rid of fsck by the simple expedient of C^c. Yes, I know that it is
obvious, and I can't believe that I didn't even try it, but I clearly didn't.

Lisi
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Ric Moore
2014-12-08 21:13:16 UTC
Permalink
Post by Lisi Reisz
Anyhow, I've gained something from this thread. I didn't know that I could
get rid of fsck by the simple expedient of C^c. Yes, I know that it is
obvious, and I can't believe that I didn't even try it, but I clearly didn't.
Maybe, like me, it's because you've been told it's a bad thing to do
since the days of Slackware installs from floppy disks. I have never
tried to interrupt it. But, I use the old Caldera scheme of keeping all
personal data on /opt which is on it's own partition. All of my /home
major directories (video, desktop, music. documents) are links to
/opt/ric. So, an fsck on / isn't as painful as it could be.

If I had tb's of data storage, I would be miffed too by an unexpected
fsck at the wrong time. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Brian
2014-12-08 14:15:32 UTC
Permalink
Post by The Wanderer
Post by Martin Read
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long
enough intervals, that I can never know if it was "4 months ago"
or "7 months ago", and neither can I remember which
laptop/desktop has the delay set to 172 days vs 194 days vs 98
days vs ...
Can't you write a small script to obviate the limitations of your
human memory, like this little hacker here did?
There is *no legitimate basis* for arguing with the OP's complaint.
The systemd transition has caused a user interface regression, which
should be fixed.
I like systemd, but I do wish certain of its non-coding proponents
would stop indulging in incendiary defence of it against legitimate
complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
Sorry, I see no "defence" ("incendiary" or otherwise) of any init system
being made in this thread. What I do see is people trying to help with a
solution to a problem. One by Curt is referenced above. By all means
criticise it but to see something like that as some some sort "proponent"
argument is not warranted.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
The Wanderer
2014-12-08 14:40:03 UTC
Permalink
Post by Brian
Post by The Wanderer
Post by Martin Read
There is *no legitimate basis* for arguing with the OP's
complaint. The systemd transition has caused a user interface
regression, which should be fixed.
I like systemd, but I do wish certain of its non-coding
proponents would stop indulging in incendiary defence of it
against legitimate complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
Sorry, I see no "defence" ("incendiary" or otherwise) of any init
system being made in this thread. What I do see is people trying to
help with a solution to a problem. One by Curt is referenced above.
By all means criticise it but to see something like that as some some
sort "proponent" argument is not warranted.
This thread is about complaints about not being able to interrupt /
abort / cancel an already-started boot-time fsck.

Several people in this thread (including, I think, you?) are responding
to those complaints by saying "It's your own fault, for not doing X",
rather than by saying "Yes, it's systemd's fault, for not doing /
letting you do Y".

I.e., they're turning a criticism of systemd around into an attack on
the criticizers.

That is, as indicated, a defense of systemd - and one of a sort which is
likely to fan the flames of dispute, rather than letting them cool.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Brian
2014-12-08 16:25:51 UTC
Permalink
Post by The Wanderer
Post by Brian
Sorry, I see no "defence" ("incendiary" or otherwise) of any init
system being made in this thread. What I do see is people trying to
help with a solution to a problem. One by Curt is referenced above.
By all means criticise it but to see something like that as some some
sort "proponent" argument is not warranted.
This thread is about complaints about not being able to interrupt /
abort / cancel an already-started boot-time fsck.
Ok; but simply complaining doesn't get things done.
Post by The Wanderer
Several people in this thread (including, I think, you?) are responding
to those complaints by saying "It's your own fault, for not doing X",
rather than by saying "Yes, it's systemd's fault, for not doing /
letting you do Y".
Sorry again; I see nothing which translates as "It's your own fault...".

An analogy is probably a bad idea; but here goes:

The airline you had booked for travel to destination X, Cheapo Air, goes
bust. The travel agent offers alternative routes by land, sea and
air. Instead of saying "thank you" and accepting or not accepting one of
the offers, she is berated for not vociferously condemning Cheapo Air's
attitude and behaviour.
Post by The Wanderer
I.e., they're turning a criticism of systemd around into an attack on
the criticizers.
That is, as indicated, a defense of systemd - and one of a sort which is
likely to fan the flames of dispute, rather than letting them cool.
I see ideas being examined and criticised. I see no attacks on anyone.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
The Wanderer
2014-12-08 16:56:56 UTC
Permalink
Post by Brian
Post by The Wanderer
Post by Brian
Sorry, I see no "defence" ("incendiary" or otherwise) of any
init system being made in this thread. What I do see is people
trying to help with a solution to a problem. One by Curt is
referenced above. By all means criticise it but to see something
like that as some some sort "proponent" argument is not
warranted.
This thread is about complaints about not being able to interrupt
/ abort / cancel an already-started boot-time fsck.
Ok; but simply complaining doesn't get things done.
Post by The Wanderer
Several people in this thread (including, I think, you?) are
responding to those complaints by saying "It's your own fault, for
not doing X", rather than by saying "Yes, it's systemd's fault, for
not doing / letting you do Y".
Sorry again; I see nothing which translates as "It's your own
fault...".
To my eye, "You should have put in the "don't run a fsck" option at the
kernel command line, before booting" (which has been said several times
in this thread, in different ways and I think by different people) is
another way of saying "The fact that it's running a fsck at boot time is
your fault for not putting in that option before booting".
Post by Brian
The airline you had booked for travel to destination X, Cheapo Air,
goes bust. The travel agent offers alternative routes by land, sea
and air. Instead of saying "thank you" and accepting or not accepting
one of the offers, she is berated for not vociferously condemning
Cheapo Air's attitude and behaviour.
I think that's a poor analogy.

A slightly better one might be if the travel agent offered alternative
routes by land and sea, but no other air-travel options to the same
destination - and then reacted condescendingly when the traveller
insisted that they really do need air travel in this case.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Curt
2014-12-08 17:30:27 UTC
Permalink
Post by The Wanderer
I think that's a poor analogy.
A slightly better one might be if the travel agent offered alternative
routes by land and sea, but no other air-travel options to the same
destination - and then reacted condescendingly when the traveller
insisted that they really do need air travel in this case.
But all air traffic has been currently shut down due to the eruption of
the systemd volcano, and the weary, wary traveller must make do with the
proverbial straw-resistant camel to cross the sizzling deserts of the
real.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@einstein.electron.org
Ric Moore
2014-12-08 21:19:51 UTC
Permalink
Post by The Wanderer
A slightly better one might be if the travel agent offered alternative
routes by land and sea, but no other air-travel options to the same
destination - and then reacted condescendingly when the traveller
insisted that they really do need air travel in this case.
I thought the original complaint was that after a full upgrade to Jessie
and systemd, that it was not possible to halt the following fsck. Heck,
that could be by design?? Before that entire process was complete,
someone decided a complete fsck was in order and not to be screwed with
by user? Could happen, That would sound like a sane choice. I'm reduced
to trouble shooting with a shotgun now. :) Ric
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
John Hasler
2014-12-08 17:14:08 UTC
Permalink
Post by Brian
I see ideas being examined and criticised. I see no attacks on anyone.
I did.
--
John Hasler
***@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@thumper.dhh.gt.org
Bonno Bloksma
2014-12-10 06:22:11 UTC
Permalink
Hi John,
Post by Erwan David
Post by Brian
I see ideas being examined and criticised. I see no attacks on anyone.
I did.
Well, I am one of the participants in the discussion and did not see any attacks.
We are merely discussing why it is a good idea to have the option to cancel a running fsck. Others are advising to not rely on that but make sure the fsck does not start when it is not convenient, my side tries to tell that such an occasion is so rare one will forget to use that option.

Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@EinExch-01.tio.nl
Lisi Reisz
2014-12-08 17:14:58 UTC
Permalink
Post by Brian
Post by The Wanderer
Several people in this thread (including, I think, you?) are responding
to those complaints by saying "It's your own fault, for not doing X",
rather than by saying "Yes, it's systemd's fault, for not doing /
letting you do Y".
Sorry again; I see nothing which translates as "It's your own fault...".
"Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again." (You)

And that is just the first. You have been very condemnatory from the
beginning until recently.

Lisi
Post by Brian
The airline you had booked for travel to destination X, Cheapo Air, goes
bust. The travel agent offers alternative routes by land, sea and
air. Instead of saying "thank you" and accepting or not accepting one of
the offers, she is berated for not vociferously condemning Cheapo Air's
attitude and behaviour.
Post by The Wanderer
I.e., they're turning a criticism of systemd around into an attack on
the criticizers.
That is, as indicated, a defense of systemd - and one of a sort which is
likely to fan the flames of dispute, rather than letting them cool.
I see ideas being examined and criticised. I see no attacks on anyone.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Brian
2014-12-08 19:00:36 UTC
Permalink
Post by Lisi Reisz
Post by Brian
Post by The Wanderer
Several people in this thread (including, I think, you?) are responding
to those complaints by saying "It's your own fault, for not doing X",
rather than by saying "Yes, it's systemd's fault, for not doing /
letting you do Y".
Sorry again; I see nothing which translates as "It's your own fault...".
"Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again." (You)
Would you please read

https://lists.debian.org/***@copernicus.demon.co.uk

again?

One could even set up two GRUB entries for the choices. An extra
keystroke or two and one get exactly what one wants. Isn't choice and
control a wonderful thing?

This is a proposed solution to having an fsck run only when chosen.

Renaud OLGIATI responded

What about the choice to stop fsck it if it has started at an inconvenient moment ?

Then I responded as you quote above. It is obvious I am referring back
to the solution, where two choices are available. Making a mistake and
not choosing the right option is a human thing to do (cf: the rm
command) but I went on to point out a fact of life - if booting is
broken, you get to keep the pieces.
Post by Lisi Reisz
And that is just the first. You have been very condemnatory from the
beginning until recently.
There are others? It would be only fair to give references so I have the
opportunity to correct any further misimpressions.

But now it seems that one has to issue a Health Warning - "Yes, it's
systemd's fault, for not doing / letting you do Y" - before tackling a
problem associated with it. Dream on. There is enough information in
this thread for a user to do something about the lack of a previously
existing feature other than complain.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
Lisi Reisz
2014-12-08 23:13:45 UTC
Permalink
Post by Brian
Post by Lisi Reisz
Post by Brian
Post by The Wanderer
Several people in this thread (including, I think, you?) are
responding to those complaints by saying "It's your own fault, for
not doing X", rather than by saying "Yes, it's systemd's fault, for
not doing / letting you do Y".
Sorry again; I see nothing which translates as "It's your own fault...".
"Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again." (You)
Would you please read
again?
One could even set up two GRUB entries for the choices. An extra
keystroke or two and one get exactly what one wants. Isn't choice and
control a wonderful thing?
This is a proposed solution to having an fsck run only when chosen.
Renaud OLGIATI responded
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Then I responded as you quote above. It is obvious I am referring back
to the solution, where two choices are available. Making a mistake and
not choosing the right option is a human thing to do (cf: the rm
command) but I went on to point out a fact of life - if booting is
broken, you get to keep the pieces.
Post by Lisi Reisz
And that is just the first. You have been very condemnatory from the
beginning until recently.
There are others? It would be only fair to give references so I have the
opportunity to correct any further misimpressions.
But now it seems that one has to issue a Health Warning - "Yes, it's
systemd's fault, for not doing / letting you do Y" - before tackling a
problem associated with it. Dream on. There is enough information in
this thread for a user to do something about the lack of a previously
existing feature other than complain.
Yet again you are saying that it is the OP's fault.

Lisi
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Brian
2014-12-09 19:15:21 UTC
Permalink
Post by Lisi Reisz
Post by Brian
Post by Lisi Reisz
"Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again." (You)
Would you please read
again?
One could even set up two GRUB entries for the choices. An extra
keystroke or two and one get exactly what one wants. Isn't choice and
control a wonderful thing?
This is a proposed solution to having an fsck run only when chosen.
Renaud OLGIATI responded
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Then I responded as you quote above. It is obvious I am referring back
to the solution, where two choices are available. Making a mistake and
not choosing the right option is a human thing to do (cf: the rm
command) but I went on to point out a fact of life - if booting is
broken, you get to keep the pieces.
Post by Lisi Reisz
And that is just the first. You have been very condemnatory from the
beginning until recently.
There are others? It would be only fair to give references so I have the
opportunity to correct any further misimpressions.
But now it seems that one has to issue a Health Warning - "Yes, it's
systemd's fault, for not doing / letting you do Y" - before tackling a
problem associated with it. Dream on. There is enough information in
this thread for a user to do something about the lack of a previously
existing feature other than complain.
Yet again you are saying that it is the OP's fault.
There is no mention of the OP or of his experience in anything quoted
above. My comment was in the context of making one choice out of two
from a GRUB menu. In the case of aborting a fsck there is no choice
available from the menu. I do not know how you can correctly claim I
have said anything was his fault.

As a general point, you appear to believe that the consequences
resulting from making a choice from two GRUB entries lies with other
than the user. If that is so, we will just have to agree to disagree.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
t***@googlemail.com
2014-12-09 07:11:45 UTC
Permalink
Post by Brian
Post by Lisi Reisz
Post by Brian
Post by The Wanderer
Several people in this thread (including, I think, you?) are responding
to those complaints by saying "It's your own fault, for not doing X",
rather than by saying "Yes, it's systemd's fault, for not doing /
letting you do Y".
Sorry again; I see nothing which translates as "It's your own fault...".
"Remedial action is not needed because the right choice was made from the
grub menu. If it wasn't, you get to live with the consequences and don't
do it again." (You)
Would you please read
again?
One could even set up two GRUB entries for the choices. An extra
keystroke or two and one get exactly what one wants. Isn't choice and
control a wonderful thing?
This is a proposed solution to having an fsck run only when chosen.
Renaud OLGIATI responded
What about the choice to stop fsck it if it has started at an inconvenient moment ?
Then I responded as you quote above. It is obvious I am referring back
to the solution, where two choices are available. Making a mistake and
not choosing the right option is a human thing to do (cf: the rm
command) but I went on to point out a fact of life - if booting is
broken, you get to keep the pieces.
Post by Lisi Reisz
And that is just the first. You have been very condemnatory from the
beginning until recently.
There are others? It would be only fair to give references so I have the
opportunity to correct any further misimpressions.
But now it seems that one has to issue a Health Warning - "Yes, it's
systemd's fault, for not doing / letting you do Y" - before tackling a
problem associated with it. Dream on. There is enough information in
this thread for a user to do something about the lack of a previously
existing feature other than complain.
Hello all,

Brian you seem to miss a point here, your roundabout solution to systemd
introduced regression implies that when you boot your computer you get
to know in advance if you can afford a fsck to run on those big data
drives. I live in a country with very unreliable power, and there are
quite a few around the planet. We still do computing, and have UPS, but
even UPS and solar powered batteries cannot get the computer to run for
ever. If I start booting and fsck runs, and I get a power cut, what am I
to do ? I can wait with my fingers crossed that fsck will complete
before I run out of power, at which point the system is going to crash
badly, or interrupt it and shut down more or less cleanly.
I gave up on systemd for my main computers because my systems where
taking so long to power down ("waiting for service "blah" to shutdown")
that I was at risk of running out of batteries, now I get the same
during boot.

Have a good day (or night).
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@googlemail.com
Brian
2014-12-09 19:11:28 UTC
Permalink
Post by t***@googlemail.com
Brian you seem to miss a point here, your roundabout solution to
systemd introduced regression implies that when you boot your
computer you get to know in advance if you can afford a fsck to run
on those big data drives. I live in a country with very unreliable
power, and there are quite a few around the planet. We still do
computing, and have UPS, but even UPS and solar powered batteries
cannot get the computer to run for ever. If I start booting and fsck
runs, and I get a power cut, what am I to do ? I can wait with my
fingers crossed that fsck will complete before I run out of power,
at which point the system is going to crash badly, or interrupt it
and shut down more or less cleanly.
GRUB can be told about an upcoming fsck and display a message inviting
you to choose to do it or not. So you get to know about it in advance;
which presumably you didn't know before.

You, as the person best placed, can decide whether the fsck can be
afforded based on the status of the power supply. The ability to
interupt the fsck after a power cut is of dubious value but, assuming
you are aware of your present power reserves and what is drawn from them
by an fsck, you could maybe uncross your fingers.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@copernicus.demon.co.uk
t***@googlemail.com
2014-12-10 05:53:08 UTC
Permalink
Post by Brian
Post by t***@googlemail.com
Brian you seem to miss a point here, your roundabout solution to
systemd introduced regression implies that when you boot your
computer you get to know in advance if you can afford a fsck to run
on those big data drives. I live in a country with very unreliable
power, and there are quite a few around the planet. We still do
computing, and have UPS, but even UPS and solar powered batteries
cannot get the computer to run for ever. If I start booting and fsck
runs, and I get a power cut, what am I to do ? I can wait with my
fingers crossed that fsck will complete before I run out of power,
at which point the system is going to crash badly, or interrupt it
and shut down more or less cleanly.
GRUB can be told about an upcoming fsck and display a message inviting
you to choose to do it or not. So you get to know about it in advance;
which presumably you didn't know before.
If grub could tell me if I am going to have electricity supply for the
next coming hours, that could be a workaround. Otherwise it is not a
substitute to being able to interrupt the fsck.
Post by Brian
You, as the person best placed, can decide whether the fsck can be
afforded based on the status of the power supply. The ability to
interupt the fsck after a power cut is of dubious value but, assuming
you are aware of your present power reserves and what is drawn from them
by an fsck, you could maybe uncross your fingers.
You must be living in rainbow pony and candy trees world. To calculate
the remaining time you need to know how much power is drown by any
specific drive in the raid array being checked, you need to know if your
batteries have had time to fully recharge after the last cut, you need
to know their self-discharge level and the maximum power they can hold
given their age. You also need to know if more than one array is going
to be checked during this specific boot, and the power drown by any
other device sharing the same power source (systemd can send me
donations if it wants me to have dedicated power backup for every
appliance and device). All this just because you won't admit that
systemd took away a feature, and that it is systemd's business to bring
it back. I am just having fun with you giving my specific use case, to
see how deep you can entrenched in your denial and fanaticism regarding
systemd's shortcomings. With friends like you systemd doesn't need enemies.
Jessie won't hold together with tape and flaky excuses for systemd's
lack of readiness in Debian. So me, (quoting you) "as the person best
placed, can decide wether" I want to interrupt fsck or not, and don't
need systemd to hold my hand and keep me "safe" just to pathetically try
to hide the fact that it introduced bugs and regressions. I try systemd,
fill bugs, try to keep current regarding it's features and sketchy
documentation, but I admit that the most annoying thing about systemd
transition isn't its bugs, or its more vocal opponents, but the zealots
and "devil's advocate" [1] one have to face with every bit of criticism
one dare to express toward systemd's shortcomings (see [2] for example
of shortcomings).

Have a good day (or night).


[1] https://xkcd.com/1432/

[2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd;dist=unstable
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@googlemail.com
Andrei POPESCU
2014-12-10 11:04:16 UTC
Permalink
Post by t***@googlemail.com
All this just because you
won't admit that systemd took away a feature, and that it is systemd's
business to bring it back.
Mmm, I'll have to chime in here. The fact is, systemd never implemented
this feature, while your statement sounds like this did work at some
time but those evil systemd developers disabled it on purpose, which I'm
sure is not you intention :)

Also, the systemd developers have no obligation whatsoever to implement
any particular feature, regardless if that particular feature was
implemented by sysvinit or not.

To (try to) get back on topic, due to the freeze it's quite obvious that
even if a patch implementing this would be made available today it won't
make it into Jessie, so if you care about this and consider using Jessie
with systemd your best bet at the moment are workarounds.

Speaking of which, did anyone here test the two proposed in the Fedora
bugs?

1. Add "Conflicts=shutdown.target" to the [Unit] section of
***@.service

This should at least make Ctrl-Alt-Del work, not sure what happens on
next reboot though (is the fsck counter reset?).

https://bugzilla.redhat.com/show_bug.cgi?id=719952

2. Add "StandardInput=tty" to ***@.service.

In theory this should allow cancellation of the fsck, but might have
undesired effects if a fsck is started after boot is completed (with
'systemctl start fsck@<device>'?).

If somebody intends to test this it should probably be done on a spare
machine and with partitions that you can afford to loose.

https://bugzilla.redhat.com/show_bug.cgi?id=799574

Of course, there's also the option of completely disabling automatic
fsck (there are several ways to do this), as I understand is the default
for new enough filesystems. This would make more sense for me on systems
with bad power (you'd still get the "bad shutdown" check).


Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Andrei POPESCU
2014-12-10 11:26:57 UTC
Permalink
Post by Andrei POPESCU
Of course, there's also the option of completely disabling automatic
fsck (there are several ways to do this), as I understand is the default
for new enough filesystems. This would make more sense for me on systems
with bad power (you'd still get the "bad shutdown" check).
I was curious about this so I tested on a filesystem created with
'dd if=/dev/zero of=testfile' and 'mkfs.ext4 testfile'. dumpe2fs reports

Maximum mount count: -1
Check interval: 0 (<none>)

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Doug
2014-12-08 19:25:21 UTC
Permalink
/snip/
Post by The Wanderer
This thread is about complaints about not being able to interrupt /
abort / cancel an already-started boot-time fsck.
/snip/

It has been remarked that systemd is an approach similar to Windows,
and it would seem that the "problem" of not being able to stop it
from arbitrarily delaying your boot is just like Windows, when
you try to boot and it says "Installing upgrades. Do not turn off
your computer."
If that's what you want, you've got it!

dm
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@optonline.net
Frédéric Marchal
2014-12-09 08:48:58 UTC
Permalink
Post by The Wanderer
This thread is about complaints about not being able to interrupt /
abort / cancel an already-started boot-time fsck.
This thread is about using one's computer quickly after turning it on. An
unexpected un-interruptible fsck is seen as an obstacle to this.

To summarize the best solution proposed so far, I have to

1) adjust automatic fsck to my taste: tune2fs -c X -i Y /dev/whatever

2) add "fsck.mode=skip" to the default grub entry.

3) add an entry to the grub menu to run fsck as it used to be (that is without
the fsck.mode option).

Steps 2 and 3 may be automated with some changes to /etc/grub.d.

To use my computer on any average day, I let it boot without any check using
the default grub entry. New Debian installs don't check ext partitions at all
(at least on the computer I'm using right now) so there is no loss of
functionality.

When I feel the need to check my file system and I have enough time to do so, I
boot the computer with the alternate boot option. If the file system was
checked recently, it will just boot as quickly as the default grub option. But
if it is time to run fsck, it will do so but I don't mind as I knew it was a
possibility.

That procedure seems perfectly fine to me unless i completely forget about
running fsck. To this the mountinfo script
(http://nwalsh.com/hacks/mountinfo/) was proposed by Curt. It is a solution
but I would prefer a desktop widget for this purpose. If any one is capable of
creating one, please let me know.

Now, is it possible to run fsck during shutdown? Users have been asking for
this for at least 10 years. Is it now acceptable, possible, tolerated?

Frederic
Curt
2014-12-09 10:53:58 UTC
Permalink
This thread is about using one's computer quickly after turning it on. An=20
unexpected un-interruptible fsck is seen as an obstacle to this.
To summarize the best solution proposed so far, I have to
1) adjust automatic fsck to my taste: tune2fs -c X -i Y /dev/whatever
2) add "fsck.mode=skip" to the default grub entry.
or 'fastboot'? Is that equivalent?

There's '/etc/fstab' I guess (zero value in the last field and the file
system will not be checked).
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@einstein.electron.org
Joel Rees
2014-12-09 12:15:11 UTC
Permalink
Post by Frédéric Marchal
[...]
That procedure seems perfectly fine to me unless i completely forget
about running fsck. To this the mountinfo script (
http://nwalsh.com/hacks/mountinfo/) was proposed by Curt. It is a solution
but I would prefer a desktop widget for this purpose. If any one is capable
of creating one, please let me know.
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been asking
for this for at least 10 years. Is it now acceptable, possible, tolerated?
switch to a virtual console (ctrl-alt-Fn), telinit s, uhm, I mean sytemctl
target=uhm, something-single-user, umount the partition, fsck by hand?

boot drive, of course, is an exercise left to the reader. ;-)
Chris Bannister
2014-12-09 15:09:31 UTC
Permalink
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been asking for
this for at least 10 years. Is it now acceptable, possible, tolerated?
That sounds like a recipe for disaster. Do you mean *before* shutdown?
--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@tal
The Wanderer
2014-12-09 15:36:53 UTC
Permalink
Post by Chris Bannister
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
That sounds like a recipe for disaster. Do you mean *before*
shutdown?
Obviously, "during shutdown" means "during the shutdown process", i.e.,
during the sequence of shutting-down-the-system steps which takes place
in response to a "shutdown" command.

That sequence already does several things prior to actually shutting
down the system; perhaps most obviously, it tells various "services" to
stop cleanly, kills other processes, and unmounts filesystems. There
seems as if there should be no conceptual reason why it shouldn't be
possible to add an additional "run a fsck" step into that sequence,
probably after the unmount and before the final shutdown itself.

...except that fsck of root during the boot process is possible only
because root hasn't been mounted yet, because we're still in the
initramfs and haven't pivoted into the real root yet. So making that
possible during shutdown would probably require setting up another
ramdisk during the shutdown process (which sounds like a bad idea),
pivoting into it, unmounting the original root, and then triggering the
fsck...

All in all, while it *might* be possible, I don't think it sounds like
that would be worth the trouble.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Frédéric Marchal
2014-12-10 06:30:53 UTC
Permalink
Post by The Wanderer
Post by Chris Bannister
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
That sounds like a recipe for disaster. Do you mean *before*
shutdown?
Obviously, "during shutdown" means "during the shutdown process", i.e.,
during the sequence of shutting-down-the-system steps which takes place
in response to a "shutdown" command.
That sequence already does several things prior to actually shutting
down the system; perhaps most obviously, it tells various "services" to
stop cleanly, kills other processes, and unmounts filesystems. There
seems as if there should be no conceptual reason why it shouldn't be
possible to add an additional "run a fsck" step into that sequence,
probably after the unmount and before the final shutdown itself.
...except that fsck of root during the boot process is possible only
because root hasn't been mounted yet, because we're still in the
initramfs and haven't pivoted into the real root yet. So making that
possible during shutdown would probably require setting up another
ramdisk during the shutdown process (which sounds like a bad idea),
pivoting into it, unmounting the original root, and then triggering the
fsck...
The partition only need to be remounted read only. if I'm understanding it
correctly.

That's what /etc/init.d/umountroot does during the shutdown sequence. So
everything is in place to run fsck just before /etc/rc0.d/K10halt.

Now two questions remain:

1) how to invoke an additional hypothetical /etc/rc0.d/K10fsck on demand?

2) is it wise to run fsck at that time? I have seen strong opposition in the
past. Mostly turning around the risk that the user would switch the power off
or the power supply would fail resulting in a damaged partition. As the risk
seems as high during the boot sequence, I don't understand the opposition.
Post by The Wanderer
All in all, while it *might* be possible, I don't think it sounds like
that would be worth the trouble.
That's probably right too...

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@wowtechnology.com
t***@googlemail.com
2014-12-10 07:05:49 UTC
Permalink
Post by Frédéric Marchal
Post by The Wanderer
Post by Chris Bannister
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
That sounds like a recipe for disaster. Do you mean *before*
shutdown?
Obviously, "during shutdown" means "during the shutdown process", i.e.,
during the sequence of shutting-down-the-system steps which takes place
in response to a "shutdown" command.
That sequence already does several things prior to actually shutting
down the system; perhaps most obviously, it tells various "services" to
stop cleanly, kills other processes, and unmounts filesystems. There
seems as if there should be no conceptual reason why it shouldn't be
possible to add an additional "run a fsck" step into that sequence,
probably after the unmount and before the final shutdown itself.
...except that fsck of root during the boot process is possible only
because root hasn't been mounted yet, because we're still in the
initramfs and haven't pivoted into the real root yet. So making that
possible during shutdown would probably require setting up another
ramdisk during the shutdown process (which sounds like a bad idea),
pivoting into it, unmounting the original root, and then triggering the
fsck...
The partition only need to be remounted read only. if I'm understanding it
correctly.
That's what /etc/init.d/umountroot does during the shutdown sequence. So
everything is in place to run fsck just before /etc/rc0.d/K10halt.
1) how to invoke an additional hypothetical /etc/rc0.d/K10fsck on demand?
2) is it wise to run fsck at that time? I have seen strong opposition in the
past. Mostly turning around the risk that the user would switch the power off
or the power supply would fail resulting in a damaged partition. As the risk
seems as high during the boot sequence, I don't understand the opposition.
Post by The Wanderer
All in all, while it *might* be possible, I don't think it sounds like
that would be worth the trouble.
That's probably right too...
Frederic
In the case of regularly failing power it would probably be more often
inconvenient to run fsck at shutdown. In general when we choose to
shutdown it is for good reasons I guess, so a long wait may has more
risk to be a nuisance then than during boot?
But I don't see why we couldn't get a nagging prompt to run fsck at any
of boot or shutdown time when it's due, with option to cancel it. After
all I think even Windows gives you this control and allow the user to
opt-out of a disk check for a short time before starting it (at least
it's what I remember from the Windows 7 I have used).
In the long run better file-systems and online check may relegate all
this to the museum of horrors, but in the meantime being able to
interrupt fsck seems like the best and only option covering all use cases.
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@googlemail.com
Frédéric Marchal
2014-12-10 08:07:52 UTC
Permalink
Post by t***@googlemail.com
Post by Frédéric Marchal
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
2) is it wise to run fsck at that time? I have seen strong opposition in
the past. Mostly turning around the risk that the user would switch the
power off or the power supply would fail resulting in a damaged
partition. As the risk seems as high during the boot sequence, I don't
understand the opposition.
In the case of regularly failing power it would probably be more often
inconvenient to run fsck at shutdown.
Power failures are as likely to occur during boot, don't they?

As suggested in another post, a computer running on battery (whether a laptop
or a computer running on UPS) must not run fsck anyway.
Post by t***@googlemail.com
In general when we choose to
shutdown it is for good reasons I guess, so a long wait may has more
risk to be a nuisance then than during boot?
You are right. I hadn't thought about that.

When I shutdown the computer it means I don't need it anymore and, with ACPI
power supply, the power supply is turned off without me standing around. I
don't have to wait until fsck completes.

But I sometimes need the computer to quickly turn off when it is a laptop I
must take away. with me. I'd hate to stay late one full hour at the office while
fsck is running :-)

Maybe unplugging the power cable before shutting down the OS would take care
of that. It doesn't look very professional though.

No matter what, running fsck without the user's consent looks like a bad idea.
Post by t***@googlemail.com
But I don't see why we couldn't get a nagging prompt to run fsck at any
of boot or shutdown time when it's due, with option to cancel it. After
all I think even Windows gives you this control and allow the user to
opt-out of a disk check for a short time before starting it (at least
it's what I remember from the Windows 7 I have used).
Instead of a nagging prompt, I prefer to have an entry in the desktop
environment shutdown menu. Along with Shutdown, Reboot, Logout, and the like.

A standalone software to be executed explicitly to run fsck and then turn the
computer off would do too.
Post by t***@googlemail.com
In the long run better file-systems and online check may relegate all
this to the museum of horrors, but in the meantime being able to
interrupt fsck seems like the best and only option covering all use cases.
Whoa! A file system that never need to be checked! Thanks for sharing your
dream :-)

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@wowtechnology.com
Gian Uberto Lauri
2014-12-10 08:49:51 UTC
Permalink
Post by Frédéric Marchal
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
2) is it wise to run fsck at that time? I have seen strong opposition in
Usually on shutdown you run sync that flushes the cache to the disk,
cleanly preparing the disk for unmounting. The mount command should
'run' sync automatically when unmounting.

You run fsck on power up because the 'system does not remember' if it
was shut-off cleanly or not. If the disks are clean and the last check
is not too old, fsck just report this and does nothing. Else it takes
care of the safety of your data.

fsck may take time. Relax, it needs that time.

"The bearing of a child takes nine months, no matter how many women
are assigned." ["The Mythical Man-Month", Frederick P. Brooks, Jr.]

"Ghe voe tempo, se speta" ["it takes time, just wait", old Venice
saying]
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mail.eng.it
Frédéric Marchal
2014-12-10 10:10:52 UTC
Permalink
Post by Gian Uberto Lauri
Post by Frédéric Marchal
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been
asking for this for at least 10 years. Is it now acceptable,
possible, tolerated?
2) is it wise to run fsck at that time? I have seen strong opposition in
Usually on shutdown you run sync that flushes the cache to the disk,
cleanly preparing the disk for unmounting. The mount command should
'run' sync automatically when unmounting.
You run fsck on power up because the 'system does not remember' if it
was shut-off cleanly or not. If the disks are clean and the last check
is not too old, fsck just report this and does nothing. Else it takes
care of the safety of your data.
Are you implying that the only purpose of fsck at boot is to recover from an
unclean shutdown?

To my understanding, errors creeping into the file system are unavoidable in
the real world, even without serious system crashes.

On the computer I'm using here (Debian Wheezy), automatic fsck at boot has
been disabled from the beginning. At this time, the root partition has been
mounted 249 times since the last check. Presumably, fsck assumed, from a
casual glance at boot time, that there was nothing to fix.

Yet, running e2fsck -n -f /dev/disk/by-uuid/whatever reports several errors
such as orphaned inode list, block bitmap differences, wrong free blocks count,
inode bitmap differences, wrong free inodes count.

Are these errors not supposed to be fixed by a periodic deeper file system
check?

Maybe I don't understand what fsck at boot is meant to fix then…
Post by Gian Uberto Lauri
fsck may take time. Relax, it needs that time.
"The bearing of a child takes nine months, no matter how many women
are assigned." ["The Mythical Man-Month", Frederick P. Brooks, Jr.]
"Ghe voe tempo, se speta" ["it takes time, just wait", old Venice
saying]
I understand all these. The question here is about controlling when this time
is taken and postpone the routine deep check a bit when it is inconvenient to
do it during this particular boot sequence.

Unless, of course, someone says that the small errors creeping into the file
system are not meant to be fixed at boot time. In that case, I'll ask what is
the correct procedure to fix them.

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@wowtechnology.com
Gian Uberto Lauri
2014-12-10 11:13:27 UTC
Permalink
Post by Frédéric Marchal
Post by Gian Uberto Lauri
Usually on shutdown you run sync that flushes the cache to the disk,
cleanly preparing the disk for unmounting. The mount command should
'run' sync automatically when unmounting.
You run fsck on power up because the 'system does not remember' if it
was shut-off cleanly or not. If the disks are clean and the last check
is not too old, fsck just report this and does nothing. Else it takes
care of the safety of your data.
Are you implying that the only purpose of fsck at boot is to recover from an
unclean shutdown?
Theoretically yes. Indeed errors happen, so the policy to force the file
file system check is wise. If my memory does not fail me, it's not something
that's here from the beginning of times (aka 01/01/1970 :) :) :) ).
Post by Frédéric Marchal
To my understanding, errors creeping into the file system are unavoidable in
the real world, even without serious system crashes.
On the computer I'm using here (Debian Wheezy), automatic fsck at boot has
been disabled from the beginning.
I never did such thing. I prefer to keep my machine running on the
basis that what wears out solid state electronic is the warm up/cool
down, and a broken computer is bad for both my wallet and the
environment.

Nevertheless, my machines do reboot, and sometimes I get a "check
forced". But I don't recall getting one of these errors during one of
these forced check.
Post by Frédéric Marchal
Maybe I don't understand what fsck at boot is meant to fix then…
These errors too. A File system may be not the most complex data
structure in the world, but a good maintenance is a good thing to do,
like checking the oil level in an engine. Fail to check the oil level
and to perform the appropriate changes and prepare (not) to get
fun....
Post by Frédéric Marchal
Post by Gian Uberto Lauri
fsck may take time. Relax, it needs that time.
"The bearing of a child takes nine months, no matter how many women
are assigned." ["The Mythical Man-Month", Frederick P. Brooks, Jr.]
"Ghe voe tempo, se speta" ["it takes time, just wait", old Venice
saying]
I understand all these. The question here is about controlling when this time
When you do fsck at boot there is only the kernel using the machine.

No other users (multiuser machines are rare now, i know) no other
services running (and in these days there are more daemons in a
running laptop than in an Armageddon movie :), it is the perfect time
to do cleanup, fsck can run without any other thing trying to access the
disk.

Just like floor cleaning. Better to schedule it when nobody is likely
to pass on the given floor.

And yes, the sooner you fix an error, the better.
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mail.eng.it
Frédéric Marchal
2014-12-10 11:41:14 UTC
Permalink
Post by Frédéric Marchal
Post by Gian Uberto Lauri
You run fsck on power up because the 'system does not remember' if it
was shut-off cleanly or not. If the disks are clean and the last check
is not too old, fsck just report this and does nothing. Else it takes
care of the safety of your data.
Are you implying that the only purpose of fsck at boot is to recover from
an unclean shutdown?
To my understanding, errors creeping into the file system are unavoidable
in the real world, even without serious system crashes.
On the computer I'm using here (Debian Wheezy), automatic fsck at boot has
been disabled from the beginning. At this time, the root partition has been
mounted 249 times since the last check. Presumably, fsck assumed, from a
casual glance at boot time, that there was nothing to fix.
Yet, running e2fsck -n -f /dev/disk/by-uuid/whatever reports several errors
such as orphaned inode list, block bitmap differences, wrong free blocks
count, inode bitmap differences, wrong free inodes count.
Are these errors not supposed to be fixed by a periodic deeper file system
check?
Following this post, I restarted the computer in single user mode. I had to
ifdown eth0 before I could mount -o remount,ro /dev/sda3 but then I could run
e2fsck -f /dev/sda3 on the boot/root partition.

And surprise! No error at all!

I restarted the computer in normal mode and, for sure, e2fsck -n -f /dev/sda3
reports the same errors as above.

Is it an artifact induced by the ext4 journal?

Frederic
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@wowtechnology.com
Renaud (Ron) OLGIATI
2014-12-10 10:35:23 UTC
Permalink
On Wed, 10 Dec 2014 09:49:51 +0100
Post by Gian Uberto Lauri
fsck may take time. Relax, it needs that time.
What if I do not have that time, and an un-interruptible fsck is launched automatically ?

This regression must be got rid of.

Cheers,

Ron.
--
Progress in physics is achieved
by denying the obvious
and accepting the impossible.
-- Robert Heinlein

-- http://www.olgiati-in-paraguay.org --
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ron.cerrocora.org
Gian Uberto Lauri
2014-12-10 11:20:45 UTC
Permalink
Post by Renaud (Ron) OLGIATI
On Wed, 10 Dec 2014 09:49:51 +0100
Post by Gian Uberto Lauri
fsck may take time. Relax, it needs that time.
What if I do not have that time,
Find it (this includes planning - of infrastructure and procedures if
required).

No other choices.

Let fsck run and pray it does not halts claiming it can't fix the
problem.

By the way, you can replace fsck with a small program that does
exit(0) and gamble all your data on a russian roulette.
--
/\ ___ Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____ African word
//--\| | \| | Integralista GNUslamico meaning "I can
\/ coltivatore diretto di software not install
già sistemista a tempo (altrui) perso... Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@mail.eng.it
Renaud (Ron) OLGIATI
2014-12-10 10:32:07 UTC
Permalink
On Wed, 10 Dec 2014 09:07:52 +0100
Post by Frédéric Marchal
Post by t***@googlemail.com
In the case of regularly failing power it would probably be more often
inconvenient to run fsck at shutdown.
Power failures are as likely to occur during boot, don't they?
In my case no, more likely during shut-down, since the only time I shut down my box is when there is a power cut, and I have to shut it down quickly, before the UPS gives up. So I certainly do not want an unwanted automatic fsck at that time.

Cheers,

Ron.
--
Progress in physics is achieved
by denying the obvious
and accepting the impossible.
-- Robert Heinlein

-- http://www.olgiati-in-paraguay.org --
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@ron.cerrocora.org
Andrei POPESCU
2014-12-10 11:10:15 UTC
Permalink
Post by Renaud (Ron) OLGIATI
In my case no, more likely during shut-down, since the only time I
shut down my box is when there is a power cut, and I have to shut it
down quickly, before the UPS gives up. So I certainly do not want an
unwanted automatic fsck at that time.
That would be easy to implement, assuming you computer "knows" it's
running on batteries.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
Henrique de Moraes Holschuh
2014-12-10 12:05:31 UTC
Permalink
Post by Andrei POPESCU
Post by Renaud (Ron) OLGIATI
In my case no, more likely during shut-down, since the only time I
shut down my box is when there is a power cut, and I have to shut it
down quickly, before the UPS gives up. So I certainly do not want an
unwanted automatic fsck at that time.
That would be easy to implement, assuming you computer "knows" it's
running on batteries.
That's unfortunately a bigger "if" than it should be, but it is easy to do
if you assume anyone with a broken platform that does it wrong gets to pick
up the pieces.

(sample code we used in Debian Lenny, since disabled due to #526398. Yes,
we have "on_ac_power", it is on package "powermgmt-base").

if which on_ac_power >/dev/null 2>&1
then
on_ac_power >/dev/null 2>&1
if [ $? -eq 1 ]
then
<we are on battery>
else
<we are on AC power>
fi
else
<we do not know power supply state>
fi

However, do NOT even THINK about skipping *boot* fsck in the general case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526398

So, you cannot "move" fsck from boot to shutdown without endangering user
data.

There is a reason why Linux system administration 101 teaches you to disable
periodic fsck for ext2/3/4 *on the filesystem* using tune2fs on boxes that
cannot take the time hit on boot. You still run fsck on every boot, but it
will not "force" a check every n days/n mounts.

Now, we certainly could address disabling periodic fsck for ext2/3/4 by
default (I don't think other filesystems have this feature).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@khazad-dum.debian.net
Henrique de Moraes Holschuh
2014-12-09 16:30:20 UTC
Permalink
Post by Chris Bannister
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been asking for
this for at least 10 years. Is it now acceptable, possible, tolerated?
It was proposed that we do this sometime ago, there's a bug open somewhere
(likely either in sysvinit, initscripts).
Post by Chris Bannister
That sounds like a recipe for disaster. Do you mean *before* shutdown?
It is not a disaster, but you must not do it if the platform reports it is
on battery, or when it is doing an UPS-initiated shutdown, or any other sort
of emergency shutdown.

(UPS: http://en.wikipedia.org/wiki/Uninterruptible_power_supply).

So far, so good, that's no show-stopper. We could make it optional, or we
could implement the gross hacks we already have to detect ups-initiated
shutdowns and skip the fsck-on-shutdown. We can properly detect "laptop on
battery" as well in most devices/platforms.

But nobody got around to writing the code. It is simple as that.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@khazad-dum.debian.net
Henrique de Moraes Holschuh
2014-12-10 12:17:23 UTC
Permalink
Post by Henrique de Moraes Holschuh
Post by Chris Bannister
Post by Frédéric Marchal
Now, is it possible to run fsck during shutdown? Users have been asking for
this for at least 10 years. Is it now acceptable, possible, tolerated?
It was proposed that we do this sometime ago, there's a bug open somewhere
(likely either in sysvinit, initscripts).
Post by Chris Bannister
That sounds like a recipe for disaster. Do you mean *before* shutdown?
It is not a disaster, but you must not do it if the platform reports it is
on battery, or when it is doing an UPS-initiated shutdown, or any other sort
of emergency shutdown.
Ehh, I better explain this further.

It is not a disaster if you move the "periodic" fsck on supposedly-clean
filesystems that exists only on ext2/3/4 to the shutdown path.

You must NOT, on pain of data loss, mess with the fsck on boot that detects
unclean filesystems and repair those before mounting them. NEVER SKIP THESE.

Refer to:
https://bugs.debian.org/526398
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@khazad-dum.debian.net
Lisi Reisz
2014-12-08 14:45:56 UTC
Permalink
Post by Brian
Post by The Wanderer
Post by Martin Read
Post by Curt
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long
enough intervals, that I can never know if it was "4 months ago"
or "7 months ago", and neither can I remember which
laptop/desktop has the delay set to 172 days vs 194 days vs 98
days vs ...
Can't you write a small script to obviate the limitations of your
human memory, like this little hacker here did?
There is *no legitimate basis* for arguing with the OP's complaint.
The systemd transition has caused a user interface regression, which
should be fixed.
I like systemd, but I do wish certain of its non-coding proponents
would stop indulging in incendiary defence of it against legitimate
complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
Sorry, I see no "defence" ("incendiary" or otherwise) of any init system
being made in this thread. What I do see is people trying to help with a
solution to a problem.
"There's none so blind as those who will not see."

Lisi
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
The Wanderer
2014-12-08 15:24:01 UTC
Permalink
Post by Brian
Post by The Wanderer
Post by Martin Read
I like systemd, but I do wish certain of its non-coding
proponents would stop indulging in incendiary defence of it
against legitimate complaints.
Exactly. It's at least as bad as the people who blame systemd for
everything that they see go wrong after the changeover.
Sorry, I see no "defence" ("incendiary" or otherwise) of any init
system being made in this thread. What I do see is people trying to
help with a solution to a problem. One by Curt is referenced above.
To address this more specifically:

The "prevent the fsck from starting in the first place" approaches are
not solutions to the presented problem.

The presented problem is about cancelling / interrupting the fsck once
it's started.

The approaches being suggested are about ways of preventing the problem
from occurring, not about ways of fixing it once it has occurred.

If you'd said "Yeah, systemd broke that, but it looks like they're
planning on fixing it at some point. In the meantime, here are some
possible workarounds.", that might have been reasonable.

But the responses so far have instead been presented with a tone and
attitude which reads to me as "There's nothing wrong with the systemd
behavior; you're the one in the wrong for wanting to do what you asked
about doing.", which is hard to see as anything but blindly pro-systemd
hostility.
--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Bonno Bloksma
2014-12-08 11:44:13 UTC
Permalink
Hi,
Post by Stefan Monnier
Actually, it's *always* a surprise. These fsck happen at long enough
intervals, that I can never know if it was "4 months ago" or "7 months
ago", and neither can I remember which laptop/desktop has the delay
set to 172 days vs 194 days vs 98 days vs ...
Can't you write a small script to obviate the limitations of your human memory, like this little hacker here did?
http://nwalsh.com/hacks/mountinfo/
http://nwalsh.com/hacks/mountinfo/mountinfo
Hmm, nice if it is just one system, your own laptop. You will get a nice warning that the next time, probably sometime this week, it will run fschk.
Unfortunately pretty useless if you are handling multiple systems and are not the only one managing them and reboots take weeks / months apart . :-(

Nope, I still want the option to cancel a running fschk and have it performed again at the next boot.
That one I can then schedule, for instance for the following night using shutdown and the time option. Might even throw in the -F option. ;-)

Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@EinExch-01.tio.nl
Erwan David
2014-12-06 19:21:46 UTC
Permalink
Post by Ric Moore
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an
inconvenient moment ?
What is wrong with an fsck?? You've never had an fsck happen without
your permission before at boot time?? Isn't it a good thing to have
happen once in a blue moon?? Jimminy Crickets, be glad you aren't
defragging like Win users have had to put up with for eons. Just think
of it as a "prophylactic measure" and play safe. Be glad, instead,
that someone is looking out for you. :) Ric
You've never had to reboot a room of 100 servers with a specific odrder
and see that the second one just began a 2h long fsck ?

I did...
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@rail.eu.org
Ric Moore
2014-12-06 20:03:27 UTC
Permalink
Post by Erwan David
Post by Ric Moore
Post by Renaud (Ron) OLGIATI
On Fri, 5 Dec 2014 20:59:25 +0000
Post by Brian
But remember our current slogan "Linux is all about choice". One can
choose to boot with or without "fsck.mode=skip".
What about the choice to stop fsck it if it has started at an inconvenient moment ?
What is wrong with an fsck?? You've never had an fsck happen without
your permission before at boot time?? Isn't it a good thing to have
happen once in a blue moon?? Jimminy Crickets, be glad you aren't
defragging like Win users have had to put up with for eons. Just think
of it as a "prophylactic measure" and play safe. Be glad, instead,
that someone is looking out for you. :) Ric
You've never had to reboot a room of 100 servers with a specific odrder
and see that the second one just began a 2h long fsck ?
I run all virtualized proxmox server clusters. If one dumps out, to play
with itself fsck'ing, the others pick up the slack if there are 3 or
more nodes. :) Ric

"Nice, nice, very very nice, they all fit together in the same device."
~ Bokonon
--
My father, Victor Moore (Vic) used to say:
"There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome." R.I.P. Dad.
Linux user# 44256
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@gmail.com
Bonno Bloksma
2014-12-08 11:07:54 UTC
Permalink
Hi Rick,
Post by Erwan David
Post by Brian
But remember our current slogan "Linux is all about choice". One
can choose to boot with or without "fsck.mode=skip".
You've never had to reboot a room of 100 servers with a specific
odrder and see that the second one just began a 2h long fsck ?
I run all virtualized proxmox server clusters. If one dumps out, to play with itself fsck'ing, the others pick up the slack if there are 3 or more nodes. :) Ric
That nice for you :) But I do not have that luxury. I run several Debian machines on iron and not in a cluster.
That may be a risc but... Debian has been very stable and the hardware has a good reputation and support contract. In the past 10 years we have had only 2 incidents at all our sites that were "inconvenient". Trying to get it all running in a cluster on virtual hardware would have probably created more problems than it would have solved due to increased system management. :-(
"Nice, nice, very very nice, they all fit together in the same device."
~ Bokonon
All other stuff does indeed run virtualized on a VMware platform, just not the stuff we primarily use
Stefan Monnier
2014-12-05 19:00:40 UTC
Permalink
Post by Brian
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just
pressed Ctrl+c, it was obvious! Today I was late for an online
conference. I got home, turned on my computer, and systemd decided
it was time to run fsck on my 1TB hard drive. Ok, I just skip it,
right? Well, Ctrl+c does not work, ESC does not work, nothing seems
to work. I Googled for an answer on my phone but nothing. So, is
there a mysterious set of commands they came up with to skip an fsck
or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
Pretty damn inconvenient and un-discoverable if you ask me.
So I think this deserves a bug report.


Stefan
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/jwvwq65x6qe.fsf-monnier+***@gnu.org
Brian
2014-12-05 19:42:28 UTC
Permalink
Post by Stefan Monnier
Post by Brian
Post by Eduardo Nogueira
With init, skipping a scheduled fsck during boot was easy, you just
pressed Ctrl+c, it was obvious! Today I was late for an online
conference. I got home, turned on my computer, and systemd decided
it was time to run fsck on my 1TB hard drive. Ok, I just skip it,
right? Well, Ctrl+c does not work, ESC does not work, nothing seems
to work. I Googled for an answer on my phone but nothing. So, is
there a mysterious set of commands they came up with to skip an fsck
or is it yet another flaw?
"fsck.mode=skip" on the kernel command line.
Pretty damn inconvenient and un-discoverable if you ask me.
So I think this deserves a bug report.
Don't get carried away and start typing.

#758902
--
To UNSUBSCRIBE, email to debian-user-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: https://lists.debian.org/***@desktop.copernicus.demon.co.uk
Continue reading on narkive:
Loading...