All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>, netdev@vger.kernel.org
Subject: Re: netconsole fun
Date: Sat, 15 Dec 2012 09:13:58 -0500	[thread overview]
Message-ID: <1355580838.2467.39.camel@thor> (raw)
In-Reply-To: <20121214142018.GA24846@shamino.rdu.redhat.com>

On Fri, 2012-12-14 at 09:20 -0500, Neil Horman wrote:
> Ah!  I'm sorry, I didn't realize this was really about getting netconsole up
> early in the boot, rather than just getting it up robustly using the startup
> script.

Well, it's both but I should have been clearer here. Sorry about that.

> If thats the case, then I would recommend that you modify the initramfs
> to do something simmilar to the startup script (since thats where the netconsole
> module will get loaded anyway).  You can write a script there that will let you
> specify the destination ip address and figure out the output dev based on the
> routing tables.  If you're using dracut to build your initramfs, then this
> should be pretty straightforward.

When I get some more free time I'll experiment with this approach.

Just to clarify something from earlier in the discussion:

On Thu, 2012-12-13 at 13:08 -0500, Neil Horman wrote:
> On Thu, Dec 13, 2012 at 09:49:31AM -0500, Peter Hurley wrote:
....
> > There is an unforeseen consequence of the patch: it breaks device
> > renaming because the device will already be in use by netconsole. Which
> > is the whole problem with userspace device renaming to begin with...
> > 
> That is bad, but see above, the netconsole service can work around this for you,
> allowing you to never have to specify a particular device at all.

The breakage is a normal consequence of being able to load netconsole
before the udev rules that do device renaming. The same thing would
happen modifying initramfs.

Basically, once netconsole attaches to a device, that device cannot be
renamed. Unfortunately, the default udev behavior messes things up
further because it will try to do this:
  eth0->eth1
  eth1->eth0
which means neither device will be renamed.

Maybe the net core should just implement persistent device names ;)

Thanks again for all your time,
Peter Hurley

  reply	other threads:[~2012-12-15 14:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10 14:17 netconsole fun Peter Hurley
2012-12-11  4:51 ` Cong Wang
2012-12-11 14:19   ` Peter Hurley
2012-12-11 14:30     ` Neil Horman
2012-12-11 15:16       ` Peter Hurley
2012-12-11 16:45         ` Neil Horman
2012-12-11 17:17           ` Peter Hurley
2012-12-11 21:19             ` Neil Horman
2012-12-12 20:59           ` Peter Hurley
2012-12-13 10:33             ` Cong Wang
2012-12-13 12:36             ` Neil Horman
2012-12-13 14:49               ` Peter Hurley
2012-12-13 18:08                 ` Neil Horman
2012-12-13 19:27                   ` Peter Hurley
2012-12-13 21:17                     ` Neil Horman
2012-12-13 22:24                       ` Peter Hurley
2012-12-14 14:20                         ` Neil Horman
2012-12-15 14:13                           ` Peter Hurley [this message]
2012-12-17 14:20                             ` Neil Horman
2013-04-29 17:28                               ` Peter Hurley
2013-04-29 18:21                                 ` Neil Horman
2013-04-30  2:44                                   ` Cong Wang
2013-05-03 19:07                                   ` Peter Hurley
  -- strict thread matches above, loose matches on Subject: below --
2012-12-10 18:00 Peter Hurley
2013-05-05  0:59 Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1355580838.2467.39.camel@thor \
    --to=peter@hurleysoftware.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.