On Tue, Jun 09, 2015 at 03:56:34PM -0700, Paul Rogers wrote: > My desktop has two identical twin boxes. I've been building my > (B)LFS-7.2 on one of them. I think it's ready to be clonable, > distributable. I packaged it up (using the as-built binaries tarballs > made by my package manager immediately after compiling each package (a > basic process I've used through 4 previous builds and dozens of > clones)), and installed it on the other box. It runs. It has the > original LFS 3.5.2 kernel, and before I "got into" BLFS I'd patched the > kernel up to 3.9.11. But both kernels were configured for starting on a > generic box, with the intent that once "up" one would soon rebuild the > kernel for the specific box. I'm to that point. I brought the working > config file from the development box, and get the following: > > ___8<... > CC arch/x86/kernel/acpi/cstate.o > LD arch/x86/kernel/acpi/built-in.o > CC arch/x86/kernel/apic/apic.o > arch/x86/kernel/apic/apic.c: In function 'lapic_next_deadline': > arch/x86/kernel/apic/apic.c:475:2: error: 'MSR_IA32_TSC_DEADLINE' > undeclared (first use in this function) > arch/x86/kernel/apic/apic.c:475:2: note: each undeclared identifier is > reported only once for each function it appears in > make[3]: *** [arch/x86/kernel/apic/apic.o] Error 1 > make[2]: *** [arch/x86/kernel/apic] Error 2 > make[1]: *** [arch/x86/kernel] Error 2 > make: *** [arch/x86] Error 2 > If I've parsed that correctly, you are now trying to build with a .config specific to the second machine ? If that is not the case, I've no idea but google might have a pointer (try searching for error: MSR_IA32_TSC_DEADLINE undeclared ).
Daily, I try to sort-of keep up with the kernel list, and one of the things I *frequently* see is messages about undefined identifiers - mostly for linux-next, but some get through to released kernels. And the root cause is that a different .config exposes a kernel dependency which the person who made the change to the kernel code had not tested. If it was me, I would probably not be trying to roll-out such an old system. But if I needed to, I would be using a stable kernel. In this case, 3.10.current sounds like the way to go (it is still maintained). I forget the details now, but at some point the udev options changed : I'm > 99% certain that I have moved systems built with 3.8 and 3.9 kernels to 3.10, but less sure if 3.14 was ok there. And even with 3.10 it is possible that I had to "pay attention" to the help (for a sysfs change, I suppose). For preference, I would probably try 3.14.latest, see if it boots, and if not try 3.10.latest. If neither boot, you have probably decided to build an "uncommon" config and (arguably) got something wrong (been there, done that, most of the scars have healed ;) Although I have switched my server to 3.18, which is still receiving maintenance, I note that updates seem to be a bit slower than for 3.14 and 3.10 - with luck, when I upgrade my server I'll be able to use 4.1 which should suffice for longer than I plan to keep that system. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
