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.
>
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 un
> 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
> happe
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
a
> 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 listma
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 compl
>> 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 g
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 ex
>> - 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
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
>
> 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
Am 08.08.2014 13:40, schrieb Jean-Michaël Celerier:
> On Mon, 4 Aug 2014 01:50:08 +0200 Marco d'Itri wrote:
>> On Aug 04, Cameron Norman 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 sta
On Mon, 4 Aug 2014 01:50:08 +0200 Marco d'Itri wrote:
> On Aug 04, Cameron Norman 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
On Aug 04, Cameron Norman 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 and
a dedicated un
El dom, 3 de ago 2014 a las 3:44 , Marco d'Itri escribió:
On Aug 04, Cameron Norman 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 filesyst
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 the
On Aug 04, Cameron Norman 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
> success/failure. Do you know i
On Sun, 03 Aug 2014 22:08:59 +0200 Michael Biebl
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.
> >
> > Af
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 verbo
19 matches
Mail list logo
