Re: make installworld fails on RELEASE6.4 amd64
On Tue, 17 Mar 2009 13:05:17 +0700 (ICT) Olivier Nicole wrote: > > > I am facing a problem that I cannot solve when trying to reinstall > > > wolrd on 6.4 amd 64. > > More about this issue. > > Regarding adjkerntz -i. > > Places that are ahead of UTC don't need to do the adjkerntz -i after > rebooting in single user. That's certainly not my experiance here (UTC+11 currently). That got well burnt into my brain after y2k with FreeBSD 2.2.6, having to patch /etc/rc (on advice) to deal with a BIOS that thought 2000 was 1994 :) > Suppose you are in a time zone at UTC +7. > > Boot in multiuser: > > Wall clock=7:00 > CMOS clock=7:00 > TZ time= 7:00 > UTC= 0:00 Right. It appears that /etc/wall_cmos_clock exists there, yes? > >From 7:00 to 7:30 you build world, file created will have a creation > date of 0:00 to 0:30 UTC. Well yes as UTC, but with wall_cmos_clock everything will show these files as local time (07:xx), just as any other files created multiuser. > Reboot in single user: > > Wall clock=7:30 > CMOS clock=7:30 > UTC= 7:30 (no adjkerntz) That's exactly WHY you want to run adjkerntz -i then, before anything that creates files is run, ie mergemaster, installworld .. but it only makes any difference if /etc/wall_cmos_clock does exist then of course. So if you'd run adjkerntz -i, times would show the same as in multiuser. > Make install world, the install will be done with a UTC at 7:30, that > is after the build time of 0:00 to 0:30. > > Reboot in multiuser: > > Wall clock=7:45 > CMOS clock=7:45 > TZ time= 7:45 > UTC= 0:45 > > Now if you look at the newly installed world, it will be in the > future, ahead by 7 hours: a file installed at 7:35 will be listed with > a time of 14:35. That is odd, but it works. Sorta works, if you don't mind file (and log) timestamps not reflecting reality. I'm fussy about chronology. And then there's that 7 hour wait until those files become dated in the past, and so can be 'updated'. > Hence country ahead of UTC don't need adjkerntz -i Sorry, but this demonstrates exactly why you DO need to run that when (ever) working single user, if you want file/log datestamps consistent. I can't comment on i386/amd64 differences, but it's necessary on i386. cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: make installworld fails on RELEASE6.4 amd64
> > I am facing a problem that I cannot solve when trying to reinstall > > wolrd on 6.4 amd 64. > More about this issue. Regarding adjkerntz -i. Places that are ahead of UTC don't need to do the adjkerntz -i after rebooting in single user. Suppose you are in a time zone at UTC +7. Boot in multiuser: Wall clock=7:00 CMOS clock=7:00 TZ time= 7:00 UTC= 0:00 >From 7:00 to 7:30 you build world, file created will have a creation date of 0:00 to 0:30 UTC. Reboot in single user: Wall clock=7:30 CMOS clock=7:30 UTC= 7:30 (no adjkerntz) Make install world, the install will be done with a UTC at 7:30, that is after the build time of 0:00 to 0:30. Reboot in multiuser: Wall clock=7:45 CMOS clock=7:45 TZ time= 7:45 UTC= 0:45 Now if you look at the newly installed world, it will be in the future, ahead by 7 hours: a file installed at 7:35 will be listed with a time of 14:35. That is odd, but it works. Hence country ahead of UTC don't need adjkerntz -i Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: make installworld fails on RELEASE6.4 amd64
Hi, > > What I did is: during the installation of the distrubition I set back > > the CMOS clock to UTC time, and when FreeBSD was done installing from > > the CD, I reset the CMOS clock to the wall clock. It worked, but it's > > not very nice. > What you did is not necessary if you "adjkerntz -i" when you boot to single > user mode. Sorry, but wrong. I did adjkerntz -i when booting in single user mode; beleive me, I spent 2 days installing from CD and trying to buildworld/installworld in many various ways. But it did not help (never needed it with i386 though) because at the very first install from CD, there is no time zone defined so all the directory structure of /usr/src appeared to be 7 hours ahead of the installation. Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: make installworld fails on RELEASE6.4 amd64
On Sunday 15 March 2009 01:31:24 am Olivier Nicole wrote: > Hi, > > > I am facing a problem that I cannot solve when trying to reinstall > > wolrd on 6.4 amd 64. > > More about this issue. > > RELEASE_6.4 i386 is imune of this problem. > > I did a make -d A installworld and it seems that it is all about > /usr/obj/usr/src/sys/boot/i386/boot2/machine. > > It's a link to /usr/src/sys/i386/include. This directory is created at > the first installation of FreeBSD. > > When CMOS clock is the wall clock and when one is located ahead of UTC > (Thailand is UTC+7), during the first installation of a distribution, > the machine boots with UTC=CMOS clock, hence creating the directory > hierarchy 7 hours ahead of time. > > The link /usr/obj/usr/src/sys/boot/i386/boot2/machine is created by > make buildworld, after the first boot of the newly installed system, > after the time zone has been set, so it is created with the right > time. > > If one does an installworld between the 7 hours interval, when > installing /usr/src/sys/boot/i386/boot2, it detects that the directory > /usr/src/sys/i386/include pointed by > /usr/obj/usr/src/sys/boot/i386/boot2/machine is newer than the objects > being installed, and it tries to rebuild the object. > > My wild guess is that on i386, make installworld looks at the > modification date of the link > /usr/obj/usr/src/sys/boot/i386/boot2/machine; while on amd64 make > installworld looks at the modification date of the directory > /usr/src/sys/i386/include pointed by the link. Hence the different > behaviour. > > This is annoying for people leaving ahead of UTC, that will install a > new distribution, cvsup the release, build and installworld, during > the interval of 7 hours. I think that users behing UTC will not be > affected. > > What I did is: during the installation of the distrubition I set back > the CMOS clock to UTC time, and when FreeBSD was done installing from > the CD, I reset the CMOS clock to the wall clock. It worked, but it's > not very nice. > What you did is not necessary if you "adjkerntz -i" when you boot to single user mode. > I am curious to have experts opinion on the different behaviour of > make regarding the modification date of the link > /usr/obj/usr/src/sys/boot/i386/boot2/machine. > > Best regards, > > Olivier > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscr...@freebsd.org" -- kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: make installworld fails on RELEASE6.4 amd64
Hi, > I am facing a problem that I cannot solve when trying to reinstall > wolrd on 6.4 amd 64. More about this issue. RELEASE_6.4 i386 is imune of this problem. I did a make -d A installworld and it seems that it is all about /usr/obj/usr/src/sys/boot/i386/boot2/machine. It's a link to /usr/src/sys/i386/include. This directory is created at the first installation of FreeBSD. When CMOS clock is the wall clock and when one is located ahead of UTC (Thailand is UTC+7), during the first installation of a distribution, the machine boots with UTC=CMOS clock, hence creating the directory hierarchy 7 hours ahead of time. The link /usr/obj/usr/src/sys/boot/i386/boot2/machine is created by make buildworld, after the first boot of the newly installed system, after the time zone has been set, so it is created with the right time. If one does an installworld between the 7 hours interval, when installing /usr/src/sys/boot/i386/boot2, it detects that the directory /usr/src/sys/i386/include pointed by /usr/obj/usr/src/sys/boot/i386/boot2/machine is newer than the objects being installed, and it tries to rebuild the object. My wild guess is that on i386, make installworld looks at the modification date of the link /usr/obj/usr/src/sys/boot/i386/boot2/machine; while on amd64 make installworld looks at the modification date of the directory /usr/src/sys/i386/include pointed by the link. Hence the different behaviour. This is annoying for people leaving ahead of UTC, that will install a new distribution, cvsup the release, build and installworld, during the interval of 7 hours. I think that users behing UTC will not be affected. What I did is: during the installation of the distrubition I set back the CMOS clock to UTC time, and when FreeBSD was done installing from the CD, I reset the CMOS clock to the wall clock. It worked, but it's not very nice. I am curious to have experts opinion on the different behaviour of make regarding the modification date of the link /usr/obj/usr/src/sys/boot/i386/boot2/machine. Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
make installworld fails on RELEASE6.4 amd64
Hi, I am facing a problem that I cannot solve when trying to reinstall wolrd on 6.4 amd 64. On a brand new machine (Dell powerEdge 2950) I install RELEASE 6.4 amd64: FreeBSD ufo2.cs.ait.ac.th 6.4-RELEASE FreeBSD 6.4-RELEASE #0: Wed Nov 26 08:37:42 UTC 2008 r...@palmer.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 Then I buildworld. Reboot in single user, adjkerntz -i Then make installworld and it fails with: ===> sys/boot/i386/boot2 (install) cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -m32 -march=i386 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld:No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 I don't see any reason why installworld is trying to rebuild boot2.s Below are extracts of what has been going on... -- Part of buildworld ===> sys/boot/i386/boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=276 count=1 1+0 records in 1+0 records out 276 bytes transferred in 0.44 secs (6291456 bytes/sec) cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -m32 -march=i386 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -m32 -march=i386 -c /usr/src/sys/boot/i386/boot2/sio.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=680 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=14f9 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1c8d text=114 data=1b79 org=0 entry=0 371 bytes available dd if=boot2.ld of=boot2 obs=7680 conv=osync 14+1 records in 1+0 records out 7680 bytes transferred in 0.61 secs (125829120 bytes/sec) cat boot1 boot2 > boot produces the files in /usr/obj/usr/src/sys/boot/i386/boot2: total 94 lrwxr-xr-x 1 root wheel 50 Mar 14 15:26 machine -> /usr/src/sys/boot/i386/boot2/../../../i386/include -rw-r--r-- 1 root wheel 23 Mar 14 15:26 boot2.h -rwxr-xr-x 1 root wheel 2345 Mar 14 15:26 boot1.out -rw-r--r-- 1 root wheel 2316 Mar 14 15:26 boot1.o -rw-r--r-- 1 root wheel 2056 Mar 14 15:26 .depend -rw-r--r-- 1 root wheel 1028 Mar 14 15:39 sio.o -rw-r--r-- 1 root wheel 26549 Mar 14 15:39 boot2.s -rwxr-xr-x 1 root wheel 8059 Mar 14 15:39 boot2.out -rw-r--r-- 1 root wheel 9080 Mar 14 15:39 boot2.o -rw-r--r-- 1 root wheel276 Mar 14 15:39 boot2.ldr -rw-r--r-- 1 root wheel 7309 Mar 14 15:39 boot2.ld -rwxr-xr-x 1 root wheel 5369 Mar 14 15:39 boot2.bin -rw-r--r-- 1 root wheel 7680 Mar 14 15:39 boot2 -rwxr-xr-x 1 root wheel512 Mar 14 15:39 boot1 -rw
