Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop

[Al Viro]

On Tue, Dec 16, 2014 at 06:09:52AM -0800, Jeremiah Mahler wrote:
> >  		ramdisk_execute_command = NULL;
> >  		prepare_namespace();
> > +		{
> > +		/* HACK */
> > +			struct path old, new;
> > +			get_fs_root(current->fs, &new);
> > +			get_fs_root(&init_fs, &old);
> > +			chroot_fs_refs(&old, &new);
> > +			path_put(&old);
> > +			path_put(&new);
> > +		}
> >  	}
> >  
> >  	/*
> 
> I tested the bad commit with your patch applied but it made no
> difference, the wireless is still down.

Interesting...  What happens if you move that added piece (i.e. call of
chroot_fs_refs()) just after that if, instead of the end of the body of
the if?

> Not sure if it helps, but the dmesg is included below.  There are errors
> about not being able to load the firmware that look interesting.

Errors about not being able to load the firmware clearly indicate that we
have an attempt to load it (from a kernel thread of some sort, e.g.
workqueue worker) getting failing with ENOENT.  So we have init_fs stuck
behind, presumably still on initramfs under the overmounting rootfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/