Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David, >>Compiled and booted!! I apparently will work with "voluntary preemption" as >>well as "no premption". No oopses, flags. Next week I will start to play with >>it! > > >>Caveat: >>Unionfs will not compile against the patched sources (not using it yet so it >>can wait). > > > Get the following harmless quip on boot: > Dec 23 18:26:18 d_baron kernel: Testing NMI watchdog ... CPU#0: NMI appears > to > be stuck (0->0)! This means that on your motherboard/CPUs kernel was unable to setup NMI watchdog. nothing bad, except for kernel won't be able to detect it's hard deadlocks automatically in case of big problem (which should not happen normally anyway). > Get a series of these, also harmless on shutdown > "Uncharging too much " harmless, though would be helpfull to report exact messages. > This is probably no longer relevant to the bug, should probably discuss > "privately" with Vasily? yes. report other problems separately please for better handling. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David, > Compiled and booted!! I apparently will work with "voluntary preemption" as > well as "no premption". No oopses, flags. Next week I will start to play with > it! thanks a lot for patience and help! all the faced bugs will be fixed in next version. > Caveat: > Unionfs will not compile against the patched sources (not using it yet so it > can wait). I can help you with that, feel free to ask. Last time I took a look at it, it needed very simple modifications due to changed declarations of a couple of functions. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David, > Got it to build and even attempt to boot--no undefineds! thanks a lot for your help! the previous bugs are fixed: http://bugzilla.openvz.org/show_bug.cgi?id=411 > The thing listed a lot of oops codes, many involving the journaling, so I > panicked and stopped it. > > Additionally, there were items like: > BUG: Using SMP with preemptive > (or something like that.) > (I do not have multiple processors but the default kernels are SMP. I could > set that option to "n". I saw somewhere that a scheduler option needs to be > set to CPQ--I believe I have this Anticipatory now--could this be the > problem?) Mm, no, I don't think it is related to CFQ/AS schedulers. It is most likely related to CONFIG_PREEMPT. Set it to 'n' plz. The fix for this will be included in next build as well. Just too many option combinations which were not tested yet, sorry for this. > The one ominous thing in the build is this item: > Building modules, stage 2. > MODPOST > WARNING: drivers/acpi/processor.o - Section mismatch: reference to > .init.data: > from .text between 'acpi_processor_power_init' (at offset 0x1055) and > 'acpi_safe_halt' > WARNING: drivers/atm/he.o - Section mismatch: reference to .init.text: > from .text between 'he_start' (at offset 0x1f5d) and 'he_service_tbrq' > WARNING: modpost: module vzwdog.ko uses symbol 'next_online_pgdat' marked > UNUSED > WARNING: modpost: module vzwdog.ko uses symbol 'first_online_pgdat' marked > UNUSED > WARNING: "next_online_pgdat" [kernel/ve/vzwdog.ko] has no CRC! > WARNING: "first_online_pgdat" [kernel/ve/vzwdog.ko] has no CRC! > > I do not know whether the "mismatches" are related to openvz or is in other > builds as well. If I do not notice it and nothing bawks... I do not have acpi > working so might be using apm instead. Both are cited. No, these warnings are not critical at all. the latter 4 are OpenVZ related, but are fully ok, we just used the symbols which are marked as not used by any one. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David Baron wrote: > On Thursday 21 December 2006 08:16, Ola Lundqvist wrote: > >>Hi David >> >>When I compiled the kernel yesterday using the same version of the kernel >>and the openvz patch I did not need to do anything with symlinking. >> >>My compile line look something like this: >>export PATCH_THE_KERNEL=true >>untar xxx.tar.gz >>cd /usr/src/linux >>make-kpkg -rfakeroot --append-to-version -openvz --added_patches openvz \ >> --revision 02 --initrd >> >>I used the same .config file as in the upstream version. >>I built it for 486, 686 and k7. >> > > > Fine. Starting virgin or after "dist-clean", the symlink to asm-i### is > absent. For some reason, the initial scripts compiles do not place it and the > make-kpkg aborts. So, easy enough to work around. Don't need to? Even easier. > > I am not using an initrd. Got sick of all the problems, especially since > yaird > was introduced (old mkinitrd worked fine). Since unix.ko and some others come > up missing several symbols: > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/net/unix/unix.ko needs > unknown > symbol ub_skb_set_charge, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/net/unix/unix.ko needs unknown > symbol ub_sock_make_wreserv, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/net/unix/unix.ko needs unknown > symbol sock_alloc_send_skb2, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/net/unix/unix.ko needs unknown > symbol ub_sock_snd_queue_add, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/net/unix/unix.ko needs unknown > symbol ub_sock_get_wreserv, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/kernel/vzwdog.ko needs unknown > symbol first_online_pgdat, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/kernel/vzwdog.ko needs unknown > symbol next_online_pgdat, > WARNING: /lib/modules/2.6.18-davidb-ovz/kernel/fs/binfmt_misc.ko needs > unknown symbol reset_files_struct > I cannot boot the thing? What is in your initrd? Maybe I need to compile in a > couple more pieces :-) check that you have CONFIG_USER_RESOURCE=y CONFIG_UNUSED_SYMBOLS=y (known bug http://bugzilla.openvz.org/show_bug.cgi?id=287) I added this to the bug. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David, >>David, >>ahhh... I guess I know the answer. >>you simply set CONFIG_VE_CALLS to 'y', while IPV6 support is in module, >>so OpenVZ kernel has reference to symbols in module :/ > > >>Pleae check CONFIG_VE_CALLS, CONFIG_VZ_DEV and CONFIG_IPV6 options > These thing are indeed set to 'y', IPV6 to 'm' > > So it needs be something else. (Note that for some reason a while back, I had > to start to compile in soundcore or alsa drivers would fail to load due to > missing symbols so the match up is not perfect.) the rule is simple: if IPV6=y then VE_CALLS can be 'y' or 'm'. if IPV6=m then VE_CALLS can be only 'm', since it references IPV6. I've added OVZ bug at http://bugzilla.openvz.org/show_bug.cgi?id=411 >>can you attach your resulting .config file please? >> > > Here it is. thanks a lot! > By setting CONFIG_IPV6=y, I can get past the LDLD .tmp_vmlinux1 step.. so it compiles/works fine now? Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
> This would seem to indicate one (or more) pieces that need be compiled into > the kernel, would it not? (I do compile in all the ovz stuff rather than > leave as modules because I had missing symbols on boot the last time I > tried.) > > If someone could point me in the correct direction :-) ahhh... I guess I know the answer. you simply set CONFIG_VE_CALLS to 'y', while IPV6 support is in module, so OpenVZ kernel has reference to symbols in module :/ Pleae check CONFIG_VE_CALLS, CONFIG_VZ_DEV and CONFIG_IPV6 options Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403712: [Debian] Re: Bug#403712: kernel-patch-openvz: Cannot compile kernel, undefined symbols
David, can you attach your resulting .config file please? Thanks, Kirill >>>Hi >>> >>>I have built it now and I have no problem building. Not at least >>>with make-kpkg. >> >>I use this. >> >> >>>According to upstream you did not run make oldconfig for some reason? >> >>It does this anyway. I compied to .config from the non-patched kernel and was >>asked to fill in various new items inserted by the patch. > > >>>So my question to you (before I close this bug) is how exactly you >>>built the kernel? > > >>Here is the script that I use: >>#!/bin/sh >>export PATCH_THE_KERNEL=true >>cd /usr/src/linux >>sudo make-kpkg --append-to-version -davidb-ovz --added_patches openvz >>kernel_image >> >>Did you do as described in the README file or in some other way? > > >>I started over, fresh untar of the sources, the resultant .config from the >>previous attempt and (another bug, this in the current kernel sources), made >>the symlink in /usr/src/linux/include asm --> asm-i386 (or whatever one is >>using!) > > >>Reran the script. > > >>A few days ago when I filed the bug, the patch was followed by a series of >>deletions. This time, there were none, so just maybe it is OK > > >>Let you know. (I have never succeded in booting one of these but that is >>another issue!) > > > Got the undefine references once again. Here is the complete error > termination: > > LD .tmp_vmlinux1 > kernel/built-in.o: In function `ve_netdev_cleanup': > vecalls.c:(.text+0x32a16): undefined reference to `addrconf_ifdown' > kernel/built-in.o: In function `fini_ve_sysctl': > vecalls.c:(.text+0x3315a): undefined reference to `addrconf_sysctl_fini' > kernel/built-in.o: In function `fini_ve_proc': > vecalls.c:(.text+0x33187): undefined reference to `ve_snmp_proc_fini' > kernel/built-in.o: In function `real_do_env_free': > (.text+0x336d4): undefined reference to `addrconf_sysctl_free' > kernel/built-in.o: In function `env_cleanup': > vecalls.c:(.text+0x33c3c): undefined reference to `fini_ve_route6' > vecalls.c:(.text+0x33c4c): undefined reference to `ve_ndisc_fini' > kernel/built-in.o: In function `do_env_create': > vecalls.c:(.text+0x349a7): undefined reference to `ve_snmp_proc_init' > vecalls.c:(.text+0x34a96): undefined reference to `ve_ndisc_init' > vecalls.c:(.text+0x34ac2): undefined reference to `init_ve_route6' > vecalls.c:(.text+0x34c36): undefined reference to `fini_ve_route6' > vecalls.c:(.text+0x34c42): undefined reference to `ve_ndisc_fini' > vecalls.c:(.text+0x34e6a): undefined reference to `addrconf_sysctl_init' > make[1]: *** [.tmp_vmlinux1] Error 1 > make[1]: Leaving directory `/usr/src/ovz/linux-source-2.6.18' > make: *** [debian/stamp-build-kernel] Error 2 > > > ___ > Debian mailing list > [EMAIL PROTECTED] > https://openvz.org/mailman/listinfo/debian > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400675: kernel-patch-openvz: OpenVZ-Patch does not apply to Debian-Kernel
Hi, > On Monday 04 December 2006 16:32, Vasily Tarasov wrote: > >>and then will receive notifications. Practically each source-upload >>cause rejects. > > > If that patch is really that picky when it comes to versions of the > kernelsource, maybe you should depend on the very versions of the > kernel-source-* packet the patch was made for. it is not that picky much. we just have similar fixes, e.g. from stable branches or from security which we usually add faster than other vendors, so after debian kernel is updated it conflicts with the same fixes in our patch. or just a context changes which reject the patch. all these conflicts are usually trivial, but require human attention :/ > Another question: Once Etch is released, will there be security updates for > that patch? Since one can expect updates to debian's kernel from time to > time, will the security team support kernel-patch-openvz, too? Do you mean OpenVZ security team? Sure, 2.6.18-OVZ kernel will be a long supported one with regular updates (as it looks like at least RHEL5 and Etch are based on it). We participate in security@ mail ling list, so fix both mainstream and OpenVZ-specific issues when needed. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400675: kernel-patch-openvz: OpenVZ-Patch does not apply to Debian-Kernel
1. Kir, lets create debian@ ML with all us on CC being subscribed. 2. Ola subscribe us on these events please then. Kirill P.S. I wanted robo to check whether old patch applies on the new kernel sources. However, thinking about recent updates it looks like it almost never applies :/ Maybe later... > Hi > > That was exactly what I was about to propose, but you were faster. > > Will you be subscribed to that and notify me when anything changes, or > do you want me to be subscribed and notify you? Or should we all? > > Regards, > > // Ola > > On Mon, Dec 04, 2006 at 06:32:57PM +0300, Vasily Tarasov wrote: > >>There is a Package Tracking System in Debian: >>we can subscribe for certain events in package life (binary-upload, >>source-upload, etc.) >>and then will receive notifications. Practically each source-upload >>cause rejects. >> >>Vasily. >> >><http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system> >>Kir Kolyshkin wrote: >> >>>Could we set up some machinery in order to be notified ASAP about the >>>kernel-patch-openvz rejects? >>> >>>Ola Lundqvist wrote: >>> >>>>Hi >>>> >>>>On Mon, Dec 04, 2006 at 02:40:21PM +0300, Vasily Tarasov wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>When I was preparing previous patch only 2.6.18-5 was available from >>>>> >>>> >>>>I see. I forgot about that I requested -5 instead of -6. >>>> >>>> >>>> >>>>>Debian repository, >>>>>so the patch was for this version. >>>>>In 2.6.18-6 they have merged some fixes for mm from 2.6.19, therefore >>>>>rejects... >>>>> >>>>> >>>> >>>>Ohh. >>>> >>>> >>>> >>>>>You can download new patch from >>>>>http://7ka.mipt.ru/~vass/debian/patch-2.6.18.3-deb-6-028test006-cpt-sched-fix.gz >>>>> >>>>> >>>> >>>>Thanks a lot! >>>> >>>>Regards, >>>> >>>>// Ola >>>> >>>> >>>> >>>>>Thank you, >>>>>Vasily! >>>>> >>>>>Ola Lundqvist wrote: >>>>> >>>>> >>>>>>Hi >>>>>> >>>>>>I have now applied this file and I got a number of rejects... >>>>>> >>>>>>Attaching the apply logs. I patched the following debian version... >>>>>>2.6.18-6 >>>>>> >>>>>>Can you help me to correct these problems? >>>>>> >>>>>>Regards, >>>>>> >>>>>>// Ola >>>>>> >>>>>>On Wed, Nov 29, 2006 at 12:27:29PM +0300, Vasily Tarasov wrote: >>>>>> >>>>>> >>>>>>>Hello, >>>>>>> >>>>>>>028test006 patch (with lockup fix from xemul@) for Debian is ready. >>>>>>>You can download it from >>>>>>>http://7ka.mipt.ru/~vass/debian/patch-028test006-debian.tar.gz >>>>>>> >>>>>>>Thank you! >>>>>>> >>>>>>>Kirill Korotaev wrote: >>>>>>> >>>>>>> >>>>>>>>Vasiliy, >>>>>>>> >>>>>>>>please help Ola. 2.6.18-ovz028test006 has been released today >>>>>>>>and includes 2.6.18.3 patches. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Kirill >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi >>>>>>>>> >>>>>>>>>Thanks for the report. Yes 2.6.17 is not supported, because >>>>>>>>>2.6.18 is >>>>>>>>>the version that will be shipped in etch. >>>>>>>>> >>>>>>>>>I'll contact upstream about this issue. The kernel team have moved >>>>>>>>>to 2.6.18.3 according to the changelog in >>>>>>>>> >>>>>>>>>http://packages.qa.debian.org/l/linux-2.6/news/20061123T193153Z.html >>>>>>>>> >>>>>>>>> >>>>>>>>>Kir, Kiril or Vasily: Can you help me to get a applyable version >>>>>>>>>of the >>>>>>>>>kernel patch? >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>> >>>>>>>>>// Ola >>>>>>>>> >>>>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400675: kernel-patch-openvz: OpenVZ-Patch does not apply to Debian-Kernel
Vasiliy, please help Ola. 2.6.18-ovz028test006 has been released today and includes 2.6.18.3 patches. Thanks, Kirill > Hi > > Thanks for the report. Yes 2.6.17 is not supported, because 2.6.18 is > the version that will be shipped in etch. > > I'll contact upstream about this issue. The kernel team have moved > to 2.6.18.3 according to the changelog in > > http://packages.qa.debian.org/l/linux-2.6/news/20061123T193153Z.html > > Kir, Kiril or Vasily: Can you help me to get a applyable version of the > kernel patch? > > Regards, > > // Ola > > On Mon, Nov 27, 2006 at 11:28:58PM +0100, root wrote: > >>Package: kernel-patch-openvz >>Version: 028test002-3 >>Severity: grave >>Justification: renders package unusable >> >> >>The patch provided by this package is unappliable to the Kernels shipped >>with Debian. >> >>The patch has no support for 2.6.17 at all. >> >>Applying it to 2.6.18 doesn't work (see below). >>I used the Kernel of linux-source-2.6.18 (Version: 2.6.18-6) >> >> >>>make-kpkg --added-patches openvz configure >> >>[...] >>for patch in /usr/src/kernel-patches/all/apply/openvz ; do\ >> if test -x $patch; then\ >> if $patch; then \ >> echo "Patch $patch processed fine"; \ >> echo "$patch" >> applied_patches; \ >> else \ >> echo "Patch $patch failed."; \ >> echo "Hit return to Continue"; \ >> read ans; \ >> fi; \ >> fi; \ >>done >>START applying openvz patch (OpenVZ kernel patch for virtual server support) >>Testing whether "OpenVZ kernel patch for virtual server support" patch for >>2.6.18 applies (dry run): >>1 out of 7 hunks FAILED -- saving rejects to file mm/fremap.c.rej >>4 out of 45 hunks FAILED -- saving rejects to file mm/memory.c.rej >>1 out of 6 hunks FAILED -- saving rejects to file mm/mprotect.c.rej >>1 out of 15 hunks FAILED -- saving rejects to file net/core/sock.c.rej >>"OpenVZ kernel patch for virtual server support" patch for 2.6.18 does not >>apply cleanly >>Patch /usr/src/kernel-patches/all/apply/openvz failed. >>Hit return to Continue >>[...] >> >> >>-- System Information: >>Debian Release: 4.0 >> APT prefers testing >> APT policy: (500, 'testing') >>Architecture: i386 (i686) >>Shell: /bin/sh linked to /bin/bash >>Kernel: Linux 2.6.17-2-k7 >>Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) >> >>Versions of packages kernel-patch-openvz depends on: >>ii bash 3.1-5 The GNU Bourne Again SHell >>ii grep-dctrl2.9.3 Grep Debian package information >>- >>ii patch 2.5.9-4Apply a diff file to an original >> >>kernel-patch-openvz recommends no packages. >> >>-- no debconf information >> >> > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394820: findutils: libgnulib.a is compiled w/o #define _FILE_OFFSET_BITS 64
> Hello, > There is no gnulib/config.h in findutils' source code. And afaict at a > short glance gnulib/lib/* #includes the main config.h which does set > #define _FILE_OFFSET_BITS 64. gnulib/config.h is generated by gnulib/configure: # ./configure config.status: creating po/Makefile configure: configuring in gnulib configure: running /bin/sh './configure' --prefix=/usr/local --cache-file=/dev/null --srcdir=. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes and the output from gnulib/configure has nothign about _FILE_OFFSET_BITS... So after gnulib/config. is generated it is included in gnulib sources, not the root ./config.h ... > I also have not got the hard/software to test this. - Would you mind > checking whether the issue is fixed in newer versions, mainly > http://backports.org/debian/pool/main/f/findutils/findutils_4.2.28-1~bpo.1_i386.deb this binary works for me. but it looks like a binary from debian 4, not stable, yep? Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394820: findutils: libgnulib.a is compiled w/o #define _FILE_OFFSET_BITS 64
Package: findutils Version: 4.1.20-6 I suppose there is a bug in gnulib/configure script which leads to generation of gnulib/config.h file without #define _FILE_OFFSET_BITS 64 line. The same line present in root ./config.h file. Without this define 32-bit i386 'find' is unable to work on some partitions (e.g. NFS) with x86-64 kernel, since it calls readdir() -> getdirents64(), but glibc is unable to convert 64bit inode numbers to 32bit fields required in readdir() and readdir() returns EOVERFLOW. If compiled with this define it starts to work fine. NOTE: The same bug doesn't happen with 'ls', as it has _FILE_OFFSET_BITS==64. Thanks, Kirill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
