Re: How to verify linux-next
On Sun, Oct 1, 2017 at 10:33 PM, Mike Galbraith wrote: > On Sun, 2017-10-01 at 09:48 -0700, Randy Dunlap wrote: >> On 10/01/17 09:44, Damian Tometzki wrote: >> >> > i resolved the issue with: >> > sudo /etc/init.d/apparmor stop >> >> or boot with: apparmor=0 > > or systemctl mask apparmor Ok, thanks everyone for your quick help. Stopping apparmor really helped to restore the connection. Mr. Tso, thanks for your help too for QEMU. After finishing my patch next I will looking into QEMU issues as per your suggestions. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to verify linux-next
Am Sonntag, den 01.10.2017, 21:58 +0530 schrieb Pintu Kumar: > On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o > 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to verify linux-next
On Sun, Oct 01, 2017 at 09:58:37PM +0530, Pintu Kumar wrote: > 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 How about compiling the kernel without apparmor? Here are some very minimal kernel configs that are designed to work with qemu and Google Compute Engine (if you use the 64-bit configs): https://github.com/tytso/xfstests-bld/tree/master/kernel-configs Grab the latest 4.9 kernel configs (e.g., [1]); it will work with 4.14-rc2, copy it into your kernel build tree as .config, and then run "make olddefconfig". That's why I use with qemu (32-bit and 64-bit) and Google Compute Engine using a minimal debian chroot, and it works Just Fine. [1] https://github.com/tytso/xfstests-bld/blob/master/kernel-configs/x86_64-config-4.9 If you want an example of how to build a automatically generated test appliance image (which is repeatably built, and can be used as part of a discplined release engineering process), please see: https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/gen-image Cheers, - Ted P.S. And here is an example of how a completely automated kernel testing report might look like. I ran a single command, and a few hours later, the following lands in my e-mail's inbox. Note the lack of using putty to manually configure a single test, and not a single terminal was opened during the entire test run. :-) TESTRUNID: ltm-20171001045435 KERNEL:kernel 4.14.0-rc2-ext4-5-gcdfa281a30f5 #513 SMP Sun Oct 1 00:52:09 EDT 2017 x86_64 CMDLINE: --kernel gs://gce-xfstests/bzImage full CPUS: 2 MEM: 7680 ext4/4k 337 tests, 23 skipped, 6 errors, 10569 seconds generic/233 generic/361 generic/388 generic/451 generic/456 generic/459 ext4/1k 337 tests, 35 skipped, 8 errors, 12440 seconds generic/018 generic/232 generic/273 generic/361 generic/388 generic/451 generic/456 generic/459 ext4/ext3 336 tests, 73 skipped, 6 errors, 10639 seconds generic/232 generic/361 generic/382 generic/388 generic/451 generic/459 ext4/encrypt 327 tests, 97 skipped, 8 errors, 6785 seconds ext4/022 ext4/028 generic/081 generic/361 generic/382 generic/388 generic/459 shared/298 ext4/nojournal 334 tests, 60 skipped, 6 errors, 6107 seconds ext4/301 generic/113 generic/232 generic/441 generic/451 generic/459 ext4/ext3conv 336 tests, 23 skipped, 4 errors, 10039 seconds generic/361 generic/388 generic/451 generic/459 ext4/adv 335 tests, 28 skipped, 8 errors, 8732 seconds generic/232 generic/233 generic/361 generic/388 generic/399 generic/451 generic/456 generic/459 ext4/dioread_nolock 336 tests, 23 skipped, 5 errors, 7434 seconds generic/081 generic/233 generic/388 generic/451 generic/459 ext4/data_journal 336 tests, 33 skipped, 5 errors, 13027 seconds generic/361 generic/371 generic/388 generic/441 generic/459 ext4/bigalloc_1k 317 tests, 44 skipped, 10 errors, 8506 seconds generic/204 generic/235 generic/269 generic/273 generic/361 generic/388 generic/422 generic/451 generic/456 generic/459 FSTESTIMG: gce-xfstests/xfstests-201709302211 FSTESTPRJ: gce-xfstests FSTESTVER: e2fsprogs v1.43.6-85-g7595699d0 (Wed, 6 Sep 2017 22:04:14 -0400) FSTESTVER: fio fio-2.21 (Thu, 15 Jun 2017 12:25:03 -0600) FSTESTVER: quota 16f31b1 (Tue, 5 Sep 2017 16:53:11 +0200) FSTESTVER: stress-ng 977ae35 (Wed, 6 Sep 2017 23:45:03 -0400) FSTESTVER: xfsprogs v4.12.0 (Thu, 20 Jul 2017 10:57:14 -0500) FSTESTVER: xfstests-bld 0d85f98 (Sat, 30 Sep 2017 21:42:59 -0400) FSTESTVER: xfstests linux-v3.8-1693-ga71d59bc (Fri, 29 Sep 2017 23:56:42 -0400) FSTESTSET: -g auto FSTESTOPT: aex ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to verify linux-next
On Sat, Sep 30, 2017 at 10:55 AM, Theodore Ts'o 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/generic/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? > - Ted ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
