On Sb, 23 aug 14, 17:17:05, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Aug 23, 2014 at 09:33:56AM -0400, Stefan Monnier wrote:
Yes, you can configure such behaviour.
I already have plenty of ways to configure the behavior I need.
This discussion is about the default behavior.
Exactly.
On Tue, Aug 26, 2014 at 12:44:07AM -0400, Stefan Monnier wrote:
Exactly. I hope the reasoning behind current defaults has been explained
adequately.
Not sure what you mean by adequately. I understand your argument, but
I disagree with it. Do you understand my argument?
Yes, I understand
Exactly. I hope the reasoning behind current defaults has been explained
adequately.
Not sure what you mean by adequately. I understand your argument, but
I disagree with it. Do you understand my argument?
That said, it would be great to improve reporting if something like this
happens.
Yes, you can configure such behaviour.
I already have plenty of ways to configure the behavior I need.
This discussion is about the default behavior.
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Sat, Aug 23, 2014 at 09:33:56AM -0400, Stefan Monnier wrote:
Yes, you can configure such behaviour.
I already have plenty of ways to configure the behavior I need.
This discussion is about the default behavior.
Exactly. I hope the reasoning behind current defaults has been explained
- If a mount fails, keep on booting. And then do your best to try and
bring this problem to the attention of someone (mentioning the
nofail option in that same message). Only stop the boot if the
partition is explicitly marked as critical or stoponfail.
Well, 'fail', which is the default,
On Fri, Aug 22, 2014 at 10:30:47AM -0400, Stefan Monnier wrote:
- If a mount fails, keep on booting. And then do your best to try and
bring this problem to the attention of someone (mentioning the
nofail option in that same message). Only stop the boot if the
partition is explicitly
In which way is it safe and correct to interrupt the boot in this case?
In the way that missing some mounts may indicate a serious problem and
could lead to incorrect behaviour or data loss.
Haven't heard many complaints about that over the years, so it shouldn't
be a super-top-priority goal,
On Fri, Aug 22, 2014 at 01:51:56PM -0400, Stefan Monnier wrote:
In which way is it safe and correct to interrupt the boot in this case?
In the way that missing some mounts may indicate a serious problem and
could lead to incorrect behaviour or data loss.
Haven't heard many complaints
On Sat, Aug 09, 2014 at 04:36:50PM -0400, Stefan Monnier wrote:
Well, I consider the sysvinit behaviour buggy and unfortunately this
lead to broken fstab configurations in the past.
There are 2 changes here:
1- systemd seems to *wait* for the device to be available, whereas the
old
Well, I consider the sysvinit behaviour buggy and unfortunately this
lead to broken fstab configurations in the past.
There are 2 changes here:
1- systemd seems to *wait* for the device to be available, whereas the
old scripts just failed right away if the device was absent.
2- if the mount
On Mon, 4 Aug 2014 01:50:08 +0200 Marco d'Itri m...@linux.it wrote:
On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:
What do you mean by fix your fstab? Adding this option is even
beneficial
if there is nothing wrong with the fstab, as services can be started
before
non-essential
Am 08.08.2014 13:40, schrieb Jean-Michaël Celerier:
On Mon, 4 Aug 2014 01:50:08 +0200 Marco d'Itri m...@linux.it wrote:
On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:
What do you mean by fix your fstab? Adding this option is even
beneficial
if there is nothing wrong with the
Control: -1 important
Am 03.08.2014 12:21, schrieb Tony Green:
Since my machine recently updated to using systemd, I have experienced a
number
of occasions when it would just hang at a blank screen when booting.
After some searching I managed to work out how to get back to having verbose
On Sun, 03 Aug 2014 22:08:59 +0200 Michael Biebl bi...@debian.org
wrote:
Control: -1 important
Am 03.08.2014 12:21, schrieb Tony Green:
Since my machine recently updated to using systemd, I have
experienced a number
of occasions when it would just hang at a blank screen when
booting.
On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:
With mountall/Upstart, there is a nobootwait option supported. I believe the
behavior is similar to nofail, except that mountall will emit the filesystem
event before finishing mounting the filesystem as well as not GAF about
I can see that this is a tricky issue.
I would suggest that at the very least, when systemd is installed to
replace the old init system, the changelogs generated and emailed to the
sysadmin ought to warn of potential problems with remote or removable
filesystems and recommend adding nofail to
El dom, 3 de ago 2014 a las 3:44 , Marco d'Itri m...@linux.it escribió:
On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:
With mountall/Upstart, there is a nobootwait option supported. I
believe the behavior is similar to nofail, except that mountall will
emit the filesystem event
On Aug 04, Cameron Norman camerontnor...@gmail.com wrote:
What do you mean by fix your fstab? Adding this option is even beneficial
if there is nothing wrong with the fstab, as services can be started before
non-essential fs's are up.
If you really want this then it can be arranged with noauto
19 matches
Mail list logo
