[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#793786: initramfs-tools: fix the broken netconsole feature in initramfs-tools



On Mon, 2016-01-11 at 09:54 +0900, Roger Shimizu wrote:
> On Mon, Jan 11, 2016 at 8:13 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > On Sun, 2016-01-10 at 16:20 +0900, Roger Shimizu wrote:
> > > I find current v2 patch will sometimes fail because it load netconsole.ko before
> > > loading network driver.
> > 
> > So maybe we should run 'udevadm settle' before loading modules?
> 
> I don't understand this part.
> If you have patch, I can run it in my netconsole testable environment,
> then feedback the log.

--- a/init
+++ b/init
@@ -207,6 +207,7 @@ run_scripts /scripts/init-top
 
 maybe_break modules
 [ "$quiet" != "y" ] && log_begin_msg "Loading essential drivers"
+udevadm settle  # make sure network drivers are loaded
 [ -n "${netconsole}" ] && modprobe netconsole netconsole="${netconsole}"
 load_modules
 [ "$quiet" != "y" ] && log_end_msg
--- END ---

It won't be reliable for USB networking, but I think that's inevitable.

> > > I made some changes based on patch v3, can confirmed various scenarios,
> > > including "MODULES=most" you mentioned. So here's patch v4.
> > > (also in my github repo's netconsole branch:
> > > https://github.com/rogers0/initramfs-tools/tree/netconsole)
> > > 
> > > the fix already takes various cases into account:
> > > - MODULES=most (default) or MODULES={dep,list} (popular for embedded devices)
> > > - netconsole param may be inside conf/modules or come with bootloader's config
> > > 
> > > for "MODULES=most" case , netconsole.ko is included by default, so there's
> > > no need to list it in conf/modules, and netconsole param should be put into
> > > bootloader's config
> > > 
> > > for "MODULES={dep,list}" case, netconsole param can be either from
> > > conf/modules or bootloader, and the previous one is preferred if both are
> > > specified.
> > [...]
> > 
> > The kernel parameter should be preferred if both are specified.  (In
> > general, the most specific configuration source should take
> > precedence.)
> 
> Yes, I agree.
> I meant if both are *same* specific level, param from conf/modules
> will be preferred.
> It's what's the test case A2 for.

The kernel paramater is more specific, because that is something the
user can (usually) edit at boot time.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or apathy?
A.  I don't know and I couldn't care less.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: