On Wed, Jan 18, 2017 at 8:43 AM, Ante Karamatić <
<email address hidden>> wrote:
> Yes, failures are consistent and happen even after 'erase disks' is enabled
> in MAAS. They also happen on all nodes. I'm afraid I can't get any more
> logs than this. This is all that MAAS can capture in this environment.
>
Hrm, it would be *really* helpful to have the complete install log. In
particular, curtin dumps
out the storage relationship of the disks before attempting to apply the
storage config
For example, when I attempt to recreate this by redeploying the same config
to the same disks
I can see this output:
Which shows the relationship that was discovered and cleared. We then clear
the tree from the bottom up; wiping md superblocks and metadata,
wiping partitions, and then devices. Resulting in a successful clearing
out of
previous on-disk storage configuration. And install succeeds. Something
is different between these systems and lack of debug info is going to
prevent
us from coming to a resolution.
The full log details the steps and the lists of current block device
holders.
If we have access to a node, then I'd like to get a node in failed state to
inspect.
If you can, then after a failed curtin install, getting at
/var/log/curtin/install.log
will contain everything we need to investigate further.
> On Wed, Jan 18, 2017 at 3:00 PM Ryan Harper <email address hidden>
> wrote:
>
> > Is it possible to include the entire installation.log?
> >
> > Do repeat deploys to the same node and same configuration fail
> > consistently?
> >
> > On Wed, Jan 18, 2017 at 6:50 AM, Ante Karamatić <
> > <email address hidden>> wrote:
> >
> > > ** Attachment added: "installation.log"
> > > https://bugs.launchpad.net/curtin/+bug/1618429/+
> > > attachment/4805810/+files/installation.log
> > >
> > > --
> > > You received this bug notification because you are subscribed to the
> bug
> > > report.
> > > https://bugs.launchpad.net/bugs/1618429
> > >
> > > Title:
> > > Curtin doesn't clean up previous MD configuration
> > >
> > > To manage notifications about this bug go to:
> > > https://bugs.launchpad.net/curtin/+bug/1618429/+subscriptions
> > >
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1618429
> >
> > Title:
> > Curtin doesn't clean up previous MD configuration
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/curtin/+bug/1618429/+subscriptions
> >
> --
> Ante Karamatić
> <email address hidden>
> Canonical
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1618429
>
> Title:
> Curtin doesn't clean up previous MD configuration
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/curtin/+bug/1618429/+subscriptions
>
On Wed, Jan 18, 2017 at 8:43 AM, Ante Karamatić <
<email address hidden>> wrote:
> Yes, failures are consistent and happen even after 'erase disks' is enabled
> in MAAS. They also happen on all nodes. I'm afraid I can't get any more
> logs than this. This is all that MAAS can capture in this environment.
>
Hrm, it would be *really* helpful to have the complete install log. In
particular, curtin dumps
out the storage relationship of the disks before attempting to apply the
storage config
For example, when I attempt to recreate this by redeploying the same config
to the same disks
I can see this output:
Current device storage tree:
vdc
|-- vdc1
|-- vdc2
| `-- md0
`-- vdc3
`-- md1
vdd
|-- vdd1
|-- vdd2
| `-- md0
`-- vdd3
`-- md1
Which shows the relationship that was discovered and cleared. We then clear
the tree from the bottom up; wiping md superblocks and metadata,
wiping partitions, and then devices. Resulting in a successful clearing
out of
previous on-disk storage configuration. And install succeeds. Something
is different between these systems and lack of debug info is going to
prevent
us from coming to a resolution.
The full log details the steps and the lists of current block device
holders.
If we have access to a node, then I'd like to get a node in failed state to
inspect.
https:/ /gist.github. com/smoser/ 2610e9b78b8d7b5 4319675d9e3986a 1b
That has details on how to stop a deployment node:
ssh ubuntu@$HOST_IP sudo touch /run/block- curtin- poweroff
If you can, then after a failed curtin install, getting at curtin/ install. log
/var/log/
will contain everything we need to investigate further.
> On Wed, Jan 18, 2017 at 3:00 PM Ryan Harper <email address hidden> /bugs.launchpad .net/curtin/ +bug/1618429/ + 4805810/ +files/ installation. log /bugs.launchpad .net/bugs/ 1618429 /bugs.launchpad .net/curtin/ +bug/1618429/ +subscriptions /bugs.launchpad .net/bugs/ 1618429 /bugs.launchpad .net/curtin/ +bug/1618429/ +subscriptions /bugs.launchpad .net/bugs/ 1618429 /bugs.launchpad .net/curtin/ +bug/1618429/ +subscriptions
> wrote:
>
> > Is it possible to include the entire installation.log?
> >
> > Do repeat deploys to the same node and same configuration fail
> > consistently?
> >
> > On Wed, Jan 18, 2017 at 6:50 AM, Ante Karamatić <
> > <email address hidden>> wrote:
> >
> > > ** Attachment added: "installation.log"
> > > https:/
> > > attachment/
> > >
> > > --
> > > You received this bug notification because you are subscribed to the
> bug
> > > report.
> > > https:/
> > >
> > > Title:
> > > Curtin doesn't clean up previous MD configuration
> > >
> > > To manage notifications about this bug go to:
> > > https:/
> > >
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https:/
> >
> > Title:
> > Curtin doesn't clean up previous MD configuration
> >
> > To manage notifications about this bug go to:
> > https:/
> >
> --
> Ante Karamatić
> <email address hidden>
> Canonical
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Curtin doesn't clean up previous MD configuration
>
> To manage notifications about this bug go to:
> https:/
>