All,
here is my update on this issue.
Please look at the branches called mount-fail and remove-netdev on the
OpenRC repository.
I would like to commit these before the next release if there are no
major issues.
The first makes it possible for netmount and localmount to fail if some
of the files
All,
This is my previous post, added on the right thread this time.
as I have always said, my views can evolve with civil discussion, and
there has been some good feedback on this.
I also got a suggestion for handling network file systems that would mean we
wouldn't have to keep track of the spe
On Wed, Aug 5, 2015 at 8:09 PM, James Cloos wrote:
>> "WH" == William Hubbs writes:
> WH> What do folks think of these changes?
>
> For local filesystems, mount -a is exactly right and should remain. At
> least for those of us who prefer only ever halving to edit fstab(5).
> --
> James Cloos
> "WH" == William Hubbs writes:
WH> The other change I want to make, considering that the mount.* scripts
WH> will actually do the work of mounting the file systems, is to turn
WH> localmount and netmount into wrappers which will do nothing other than
WH> pull in the appropriate mounts. The s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/08/15 04:40 PM, William Hubbs wrote:
> On Tue, Aug 04, 2015 at 02:05:12PM -0400, Ian Stakenvicius wrote:
>> 1 - if localmount fails, the you end up with everything that
>> currently 'need's localmount failing -- this means if you have a
>> head
On Tue, Aug 04, 2015 at 02:05:12PM -0400, Ian Stakenvicius wrote:
> 1 - if localmount fails, the you end up with everything that currently
> 'need's localmount failing -- this means if you have a headless server
> someplace that reboots, you may not end up with an sshd to connect
> into it just to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/08/15 11:29 AM, William Hubbs wrote:
> All,
>
> it seems that we have mostly agreed that this proposal is a good
> one, so I want to focus the discussion on the specific behaviour of
> localmount and netmount.
>
> Currently, they mount all fi
All,
it seems that we have mostly agreed that this proposal is a good one, so
I want to focus the discussion on the specific behaviour of localmount
and netmount.
Currently, they mount all file systems in mass and exit successfully
regardless of whether the mounts are successful. I feel this is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/28/2015 06:57 AM, William Hubbs wrote:
> On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg)
> wrote:
>> What would a migration be like? For example, I manage
>> filesystems exclusively through fstab (to my knowledge). Would
>> this
On Tue, Jul 28, 2015 at 08:45:30PM +0300, Diamond wrote:
> On Mon, 27 Jul 2015 17:26:10 -0500
> William Hubbs wrote:
>
> > - Currently, we have to skip over certain file systems that we can't
> > unmount during shutdown. With the new approach, if the mount script
> > mounts a file system duri
All,
I got a clarification on irc that I would like to respond to, and I'll
also respond to a couple of other things.
On Mon, Jul 27, 2015 at 05:26:10PM -0500, William Hubbs wrote:
> All,
>
> I have been looking over this bug for some time attempting to find a
> good solution [1].
>
> The origi
On Mon, 27 Jul 2015 17:26:10 -0500
William Hubbs wrote:
> - Currently, we have to skip over certain file systems that we can't
> unmount during shutdown. With the new approach, if the mount script
> mounts a file system during boot, it will be able to unmount the
> same filesystem during shut
On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg) wrote:
> What would a migration be like? For example, I manage filesystems
> exclusively through fstab (to my knowledge). Would this be useful for,
> say, mounting over the network? What would managing FSes with openrc
> look like?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/27/2015 03:26 PM, William Hubbs wrote:
> All,
>
> I have been looking over this bug for some time attempting to find
> a good solution [1].
>
> The original proposal is to add a "want" dependency which would
> work like "need" but would not f
On Mon, Jul 27, 2015 at 6:26 PM, William Hubbs wrote:
>
> Some of the advantages of this approach are listed in the bug. Here are
> a few more I can think of.
>
As we discussed this is similar to the approach taken by systemd
(though it parses fstab and creates service files dynamically).
Some o
On Tue, Jul 28, 2015 at 02:54:56AM +0300, Alon Bar-Lev wrote:
> On 28 July 2015 at 01:26, William Hubbs wrote:
> > The proposal in [3], on the other hand, is to create a mount script that
> > works like netifrc. It would mount a single file system, which would be
> > determined by the link it was
On 28 July 2015 at 01:26, William Hubbs wrote:
> The proposal in [3], on the other hand, is to create a mount script that
> works like netifrc. It would mount a single file system, which would be
> determined by the link it was called from, much like how netifrc
> determines which interface to wor
All,
I have been looking over this bug for some time attempting to find a
good solution [1].
The original proposal is to add a "want" dependency which would work
like "need" but would not fail if the services wanted did not start [2].
I agree that the "want" dependency is a valid feature request
18 matches
Mail list logo
