On 10/01/17 09:44, Damian Tometzki wrote: > > 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@xxxxxxx> >> 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 or boot with: apparmor=0 -- ~Randy _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
