On 10 June 2015 at 01:22, Ken Moffat <[email protected]> wrote:
> 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. > I'm not sure that it's a kernel version problem, but I can only speak from from my own experience. I have a hybrid box which started out as LFS 7.2, and over time I've added various packages, both from the BLFS book and other packages not in the book. Its had a number of different kernel versions, and now It's running kernel 4.03 without any (kernel) issues. Personally, I never use kernel patches to update the kernel; I always re-build from scratch, but using the same .config where possible. I think that's the safer way to do things. Richard
-- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
