How to verify linux-next

[Damian Tometzki]

Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar:
> On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o <tytso at mit.edu>
> wrote:
> > 
> > On Sat, Sep 30, 2017 at 09:28:09AM +0530, Pintu Kumar wrote:
> > > 
> > > I need to submit a patch to mainline which should be verified
> > > against
> > > linux-next tree with latest API.
> > If you want to verify a patch that you intend to submit upstream,
> > my
> > suggestion is to *not* use linux-next, but rather use the latest
> > tagged -rc from Linus's tree.  So for example, you might want to
> > use
> > v4.14-rc2 as your base, and then apply your patch on top of v4.14-
> > rc2.
> > And then test v4.14-rc2.  That way you don't need to worry about
> > debugging problems that might be caused by code in other people's
> > development trees.
> > 
> > If you know which subsystem tree your commit is going to be sent
> > to,
> > you might use as your base the current development branch of that
> > subsystem tree.  But in general, it's fine to use something like
> > v4.14-rc2; if the subsystem maintainer you plan to be submitting
> > your
> > patch has other preference, he or she will let you know, or take
> > care
> > of rebasing your patch onto his subsystme tree.
> > 
> > > 
> > > My patch is related to some test utility based on client/server
> > > model.
> > > So, I need 2 terminal, one for server and one for client.
> > That implies you're running the commands to run the test by
> > hand.  In
> > the ideal world, tests should be automated, even those that are
> > using
> > client/server so that tests can be run unattended, over and over
> > again.
> > 
> > For example, here's an example of test involving a client and a
> > server
> > in xfstests:
> > 
> > https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/tests/g
> > eneric/131
> > 
> > See?  No terminal required, and certainly not two terminals!
> > 
> > Remember, it's important not just to run one test, because the risk
> > is
> > that fixing one bug might cause a test regression somewhere
> > else.  So
> > when I "validate" a kernel, I'm running thousands of tests, just to
> > test the ext4 file system.  For each bug that we fix, we try to add
> > a
> > new automated test, so we can be sure that some future change
> > doesn't
> > cause a bug to reappear.  And if you're running hundreds or
> > thousands
> > of tests, you certainly aren't going to be wanting to manually set
> > up
> > each test by using putty to login to the VM using ssh!
> > 
> > > 
> > > 1) How to resolve linux-next build error with ubuntu virtual box
> > > 5.1.28
> > Virtual box is not relevant.  What is relevant is the kernel config
> > file you are using, and what compiler version / distro are you
> > using
> > to build the kernel.  And as I said, you're better off using
> > something
> > like v4.14-rc2 instead of linux-next.
> > 
> Ok thank you so much for your reply.
> Now I am able to boot with v4.14-rc2. But now I am facing another
> problem.
> Now, I am not able to connect to internet from virtual box.
> When I switch back to the default 4.10 the internet works normally.
> I think the dlclient stopped working.
> I am getting continuous logs related to apparmor like this:
> apparmor="DENIED" comm=dhclient
> apparmor="DENIED" comm=cups-browsed
> 
> With 4.10, I tried installing apparmor-utils and then reboot with
> 4.14-rc2, but it did not help.
> Any suggestions on this?

Hello,

i resolved the issue with:
sudo /etc/init.d/apparmor stop

Damian

> 
> 
> > 
> >                                         - Ted