yahoo-eng-team team mailing list archive

[Dan Watkins <daniel.watkins@xxxxxxxxxxxxx>]

Public bug reported:

When debugging instance launch failures, one trick we use is to mount
the disk of the failed instance to another instance, and investigate the
logs there.  Most of the time, we can use chroot to run `cloud-init
collect-logs` in the failed instance's root.  However, if we are
attempting to debug across architectures (most recently, debugging arm64
AWS boot failures either locally or on an amd64 AWS instance), then
using chroot becomes decidedly non-trivial.

Could we add an option to specify the root in which collect-logs
operates, to make collecting this data easier in these cases?

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1809139

Title:
  Support collect-logs from a non-/ root

Status in cloud-init:
  New

Bug description:
  When debugging instance launch failures, one trick we use is to mount
  the disk of the failed instance to another instance, and investigate
  the logs there.  Most of the time, we can use chroot to run `cloud-
  init collect-logs` in the failed instance's root.  However, if we are
  attempting to debug across architectures (most recently, debugging
  arm64 AWS boot failures either locally or on an amd64 AWS instance),
  then using chroot becomes decidedly non-trivial.

  Could we add an option to specify the root in which collect-logs
  operates, to make collecting this data easier in these cases?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1809139/+subscriptions