On Monday 2013-10-07 14:25, Karel Zak wrote:
>On Tue, Sep 10, 2013 at 04:55:19PM +0100, Colin Guthrie wrote:
>> 'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble:
>> > On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt wrote:
>> >>
>> >> On Tuesday 2013-09-10 13:52, Dave Reisner
On Tue, Sep 10, 2013 at 04:55:19PM +0100, Colin Guthrie wrote:
> 'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble:
> > On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt wrote:
> >>
> >> On Tuesday 2013-09-10 13:52, Dave Reisner wrote:
> the FUSE program knows
> nothin
'Twas brillig, and Tom Gundersen at 10/09/13 13:45 did gyre and gimble:
> On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt wrote:
>>
>> On Tuesday 2013-09-10 13:52, Dave Reisner wrote:
the FUSE program knows
nothing about the systemd-specific "nofail" or "x-*".
>>>
>>> This should only be
On Tue, 10.09.13 12:23, Robert Schiele (rschi...@gmail.com) wrote:
>
> Hi,
>
> On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering
> wrote:
> > On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
> >> I was choosing the interface described above since according to my
> >> observa
On Tue, Sep 10, 2013 at 2:31 PM, Jan Engelhardt wrote:
>
> On Tuesday 2013-09-10 13:52, Dave Reisner wrote:
>>> the FUSE program knows
>>> nothing about the systemd-specific "nofail" or "x-*".
>>
>>This should only be a problem if you directly use the FUSE mount helper.
>>If you instead invoke mou
On Tuesday 2013-09-10 13:52, Dave Reisner wrote:
>> the FUSE program knows
>> nothing about the systemd-specific "nofail" or "x-*".
>
>This should only be a problem if you directly use the FUSE mount helper.
>If you instead invoke mount with -t fuse.$fusetype, then this isn't an
>issue. mount(8) *
On Tue, Sep 10, 2013 at 1:52 PM, Dave Reisner wrote:
> On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote:
>>
>> On Tuesday 2013-09-10 02:41, Lennart Poettering wrote:
>> >On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
>> >
>> >One possibility might be to add a new
On Tue, Sep 10, 2013 at 01:40:32PM +0200, Jan Engelhardt wrote:
>
> On Tuesday 2013-09-10 02:41, Lennart Poettering wrote:
> >On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
> >
> >One possibility might be to add a new extended mount option (i.e. as
> >listed in fstab's fourth c
On Tuesday 2013-09-10 02:41, Lennart Poettering wrote:
>On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
>
>One possibility might be to add a new extended mount option (i.e. as
>listed in fstab's fourth column) that systemd
>would interpret. i.e. "x-systemd.yesfsck" or so. That s
Hi,
On Tue, Sep 10, 2013 at 2:41 AM, Lennart Poettering
wrote:
> On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
>> I was choosing the interface described above since according to my
>> observation this seems closest to how interfaces were constructed in
>> this area before. I
On Fri, 06.09.13 14:53, Robert Schiele (rschi...@gmail.com) wrote:
> In some situations it is desirable to set the fsck fix level from "-a"
> to "-y". This for instance might be a reasonable decision on embedded
> systems where a user dealing with emergency mode is not available and
> we prefer t
In some situations it is desirable to set the fsck fix level from "-a"
to "-y". This for instance might be a reasonable decision on embedded
systems where a user dealing with emergency mode is not available and
we prefer the risk of destroying the file system by an incorrect fsck
action over the r
12 matches
Mail list logo
