hello everyone!!!
i am a newbie to LFS,and i started the LFS-6.6 few days back...i have encountered few errors but i searched the LFS forum and got many of my doubts cleared....but now am stuck at glibc-2.11.1 installation..chapter 6.9

my glibc-check-log on grepping gives a whole list of errors
i don't know what happened...but when i saw the glibc-check-log , probably the error occurs first here.....similar type of error occur repeatedly..as log file is to big am attaching only the part where Error 2 first occured

i have highlighted the places i don't understand well....



I am using the SuperOS(ubuntu) 9.10 distribution..


Please,tell me what to do from here....Thanks in advance !!

As for your first code block, the errors start above it, so it's really not a great help. It's good to know that glibc in chapter 6 is the first really essential thing you're slapping together, so it's really a test of your work thus far. Now, what follows is my guesses at your errors

Clock skew detected. Your build may be incomplete.
This is a hardware thing where the clock(i.e. the system clock, not a time clock) is not clocking all parts of the m/b together,
Usually this is only something hardware engineers have to worry about. Try ignoring it, and hope it goes away. Stop overclocking. If it remains an issue, we may have to look into it.

Error 2
File or directory not found error

File `/dev/null' has modification time 1.4e+04 s in the future
This mjeans a compile has gone badly wrong and got out and relieved it's overfull bladder on your system :-/. /dev/null is like the famous joke 'write only memory' - the unix dustbin.check it's size - it should be 0 bytes like this one

crw-rw-rw- 1 root root 1, 3 2005-11-21 03:22 /dev/null

As you see, mine dates from 2005. Yours seems way off

1 members found this post helpful.

Hey business_kid !!
Thanks for the reply.....it was informative.
But what do you suggest i do from here....should i start the LFS project from start.
I am using the Ubuntu9.10 , will that create any problems??? and what if the host system requirement as described in LFS-6.6 book are met with a higher package version???



Thanks for your reply again !!

post the output of ls -l /dev/null - the one in the chroot.
It's long enough since I've done an LFS. I would try to validate the rest of the system by recompiling something that worked(Binutils?). Don't reinstall binutils. If that works, delete the glibc source & explode from tarball again. Otherwise, go back to chapter 5. It will be quicker in the long run. Watch for errors in ch 5 this time.

hello !!!
thanks again....the output as you asked is


Thanks for help, i'll start again..with chapter 5.

/dev/null looks good.
How the hell did it work out 'File `/dev/null' has modification time 1.4e+04 s in the future'

You're in ch.6 - chroot so a reboot would fix whatever happened, as /dev is not preserved and udev starts from lists. So it's the glibc build that went screwy. Do it line by line.

Thank you again,business_kid !!

yeah! am starting with glibc again.

Have you find the cause or overcome the problem? I'm encountering this as well.

HI you will need to post the errors from the log file. Also what Host distro are you using and what versionof lfs?

Its the same error I am getting. I am new to this linux domain. Please suggest some remedies.

CC lib/string.o
CC lib/vsprintf.o
AR lib/lib.a
make[1]: warning: Clock skew detected. Your build may be incomplete.
LD vmlinux.o
make[1]: Warning: File `vmlinux.o' has modification time 6.3 s in the future
MODPOST vmlinux.o
WARNING: modpost: Found 5 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: warning: Clock skew detected. Your build may be incomplete.
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
make[1]: Warning: File `vmlinux' has modification time 5.9 s in the future
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
AS arch/arm/boot/compressed/head.o
make[2]: Warning: File `arch/arm/boot/compressed/../Image' has modification time 6.5 s in the future
GZIP arch/arm/boot/compressed/piggy.gzip
AS arch/arm/boot/compressed/piggy.gzip.o
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
SHIPPED arch/arm/boot/compressed/lib1funcs.S
AS arch/arm/boot/compressed/lib1funcs.o
LD arch/arm/boot/compressed/vmlinux
make[2]: warning: Clock skew detected. Your build may be incomplete.
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
Image Name: Linux-2.6.35.7-00057-g41bac15-di
Created: Tue May 10 21:40:31 2011
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3140112 Bytes = 3066.52 kB = 2.99 MB
Load Address: 0x80008000
Entry Point: 0x80008000
Image arch/arm/boot/uImage is ready
make[1]: warning: Clock skew detected. Your build may be incomplete.
make: warning: Clock skew detected. Your build may be incomplete.

I am not sure if this will cause boot issues. I am building for Android and the boot stops specifying that few files in /system/bin is missing. The boot stops init.rc routines, the last message is "CPU1: Shutdown". I am not able to progress any further. A similar post said it could be due to NFS and yes,I am building over the NW and I am looking at NTP org website to see to resolve it.

However, if someone can tell me, if this can boot issues or not (which primarily is due to missing files in /system/bin)
Thanks.

Distant_guy: this thread started off on glibc in lfs. Now I'm seeing kernel errors, and you're mentioning andrid. I'm confused. Better to start a fresh thread and explain yourself fully.

That said, I would ignore time stamp errors, and feel unlucky if they nailed me later. But kernel builds don't go poking around in /system/bin looking for files unless they want to use them as a rule. That I would view as important. I am presuming you are cross compiling? A file in /system/bin would be an _arm_ executable which won't run on an x86 box without pain. Exactly what files does it want? For things like tar, bzip2, gzip, cp, I am sure you could symlink in the gnu x86 versions. Libc stuff I would be very careful about. But I wouldn't even bother trying a kernel unless the message was a warning nag (e.g. can't find bzip2; using gzip instead), as otherwise, a middle finger is implied, but they don't actually put it in.