On Thu, 2018-01-18 at 09:22 -0600, Benjamin Marzinski wrote:
> On Thu, Jan 18, 2018 at 09:11:02AM +0100, Martin Wilck wrote:
> > On Wed, 2018-01-17 at 21:50 -0600, Benjamin Marzinski wrote:
> >
> > > Now, I don't see how this could cause a boot to fail since this
> > > is a
> > > new
> > > device
On Thu, Jan 18, 2018 at 09:11:02AM +0100, Martin Wilck wrote:
> On Wed, 2018-01-17 at 21:50 -0600, Benjamin Marzinski wrote:
>
> > Now, I don't see how this could cause a boot to fail since this is a
> > new
> > device that isn't getting set up, but I really never test this,
> > because
> > when
On Wed, 2018-01-17 at 21:50 -0600, Benjamin Marzinski wrote:
> Now, I don't see how this could cause a boot to fail since this is a
> new
> device that isn't getting set up, but I really never test this,
> because
> when we create the initramfs in RedHat based distros, we edit the
>
Just a bit more information about how RedHat works with multipath
claiming devices in a find_multipaths setup.
Clearly, if you have a multipathed root device, it should be in the
wwids file from the time of installation. So, multipath will
automatically claim it right away when "-i" isn't used.
On Wed, Jan 17, 2018 at 10:38:42AM +0100, Julian Andres Klode wrote:
> On Tue, Jan 16, 2018 at 02:30:46PM -0600, Benjamin Marzinski wrote:
> >
> > RedHat also removes your patches to force ignore_wwids off and imply -n
> >
> > 64e27ec066a001012f44550f095c93443e91d845
> >
On Wed, Jan 17, 2018 at 01:43:47AM +0100, Martin Wilck wrote:
> On Tue, 2018-01-16 at 14:30 -0600, Benjamin Marzinski wrote:
> > On Mon, Jan 15, 2018 at 05:46:24PM +0100, Martin Wilck wrote:
> > > On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> > > > On Mon, Jan 15, 2018 at
On Tue, Jan 16, 2018 at 02:30:46PM -0600, Benjamin Marzinski wrote:
> On Mon, Jan 15, 2018 at 05:46:24PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> > > On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > > > On Mon, 2018-01-15 at
On Tue, 2018-01-16 at 14:30 -0600, Benjamin Marzinski wrote:
> On Mon, Jan 15, 2018 at 05:46:24PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> > > On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > > > On Mon, 2018-01-15 at 16:44
On Mon, Jan 15, 2018 at 05:46:24PM +0100, Martin Wilck wrote:
> On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> > On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > > On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> > > >
> > > > It was your commit
On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> > >
> > > It was your commit that made it imply -n that caused the test
> > > failure
> > > :)
> > > I
On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> >
> > It was your commit that made it imply -n that caused the test failure
> > :)
> > I understand your position on that, but reverted it for Ubuntu,
> > because,
> >
On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
>
> It was your commit that made it imply -n that caused the test failure
> :)
> I understand your position on that, but reverted it for Ubuntu,
> because,
> while it might be somewhat broken, it's at least the same level of
> broken
>
On Fri, Jan 12, 2018 at 11:18:01PM +0100, Martin Wilck wrote:
> "find_multipaths" is not a silver bullet to kill off multipath-related
> boot problems. It has advantages and disadvantages, depending on the
> use case. Anyway, I'm not aware of general problems with it in the
> later multipath
On Fri, 2018-01-12 at 22:47 +0100, Julian Andres Klode wrote:
> On Fri, Jan 12, 2018 at 09:35:39PM +0100, Martin Wilck wrote:
> > On Fri, 2018-01-12 at 09:38 +0100, Julian Andres Klode wrote:
> > >
> > > --- a/multipathd/main.c
> > > +++ b/multipathd/main.c
> > > @@ -1090,6 +1090,11 @@
On Fri, Jan 12, 2018 at 11:18:01PM +0100, Martin Wilck wrote:
> On Fri, 2018-01-12 at 22:47 +0100, Julian Andres Klode wrote:
> >
> > I don't know actually, I'm just updating the package :)
>
> The feature needs to be enabled explicitly, so indeed you weren't using
> it.
>
> > >I can say that
On Fri, 2018-01-12 at 22:47 +0100, Julian Andres Klode wrote:
>
> I don't know actually, I'm just updating the package :)
The feature needs to be enabled explicitly, so indeed you weren't using
it.
> >I can say that
> the tests were run with default configuration, normally we run with
>
On Fri, Jan 12, 2018 at 09:35:39PM +0100, Martin Wilck wrote:
> On Fri, 2018-01-12 at 09:38 +0100, Julian Andres Klode wrote:
> >
> > and then we get I/O error on the device and it's rendered unusable.
> > It's
> > also crashing in uev_pathfail_check() occassionally because
> >
On Fri, 2018-01-12 at 09:38 +0100, Julian Andres Klode wrote:
>
> and then we get I/O error on the device and it's rendered unusable.
> It's
> also crashing in uev_pathfail_check() occassionally because
> find_path_by_devt()
> returns NULL, so I applied the following patch to at least continue,
>
Hi,
I am working on updating Ubuntu's multipath-tools from 0.6.4 to 0.7.4, and
our tests report a weird failure. We first build a multipath device from 4
nodes, and then start removing nodes while performing I/O to the multipath
device. This works fine for one or two removals, but eventually we
19 matches
Mail list logo