From mboxrd@z Thu Jan 1 00:00:00 1970 From: Corey To: 9fans@9fans.net Date: Tue, 28 Jul 2009 15:42:50 -0700 User-Agent: KMail/1.11.4 (Linux/2.6.27-gentoo-r8; KDE/4.2.4; i686; ; ) References: <664879e97485933b3ca1bc9e37760730@quanstro.net> <200907272205.56808.corey@bitworthy.net> <73922819731eb511895ad1959a18a486@coraid.com> In-Reply-To: <73922819731eb511895ad1959a18a486@coraid.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200907281542.50518.corey@bitworthy.net> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] how to fix: 'arena arenas00 creation time after last write time' Topicbox-Message-UUID: 3070b29c-ead5-11e9-9d60-3106f5b1d025 On Tuesday 28 July 2009 06:22:19 erik quanstrom wrote: > > > -L used with -r to indicate the real time clock is in > > > local time rather than GMT. This is useful on PCs that > > > also run the Windows OS. > > > > I must be stuck in some sort of logic error, so please correct me where > > I'm wrong: > > > > * the Plan 9 installer assumes EDT (UTC -4) > > > > * however I live in MST (UTC -7) > > > > * thus no matter what, when I set my timezone after the install, the ti= me > > goes _backward_ X number of hours (EDT is -4, MST is -7; so time goes > > this is incorrect. time stays the same. you can verify with date -n. > plan 9 keeps time in utc. in fact the timezone is just an environment > variable. so two different programs on the same machine can be set > to different timezones. > This is useful info, thanks. But if this is in fact certainly true in all cases, then I do not understand why I can so easily affect venti in negative ways simply by changing the timezone on the terminal. (I have verified with certainty that the bios=20 rtc is not somehow becoming reset or changed at any point) > your problem is with the rtc. it sounds like between your install and yo= ur > reboot, the rtc was accidentally changed from utc to local time. this > may be a bug in plan 9's installer, but i suspect it was something else > you ran. > I'm guessing I'd probably wear out my welcome if I continue to press the issue. (c8=3D But I'm a stubborn punk, so I'll here's another attempt: The steps are short and simple, and the results are confirmed reproducible. #0 - start with a fully 0'd hd (i.e.: no 'sticky' plan 9 partitions still lingering around with data; I do this using dd or shred) #1 - boot into bios, set the cmos clock to UTC #2 - reboot and confirm bios clock remains accurate after above change #3 - reboot and begin Plan 9 install onto the hardware using latest Plan 9 = cd #4 - choose 'fossil+venti' for configfs, and go on to complete install using appropriate defaults #5 - on first reboot after install, before first login, go into bios and co= nfirm that bios clock is still in fact set accurately to UTC #6 - reboot, (first-time login), as glenda:=20 - remove -L switch from $TIMESYNCARGS in /rc/bin/termrc - as an adm user: cp /adm/timezone/US_Arizona /adm/timezone/local - fshalt #7 - reboot, (second-time login), as glenda:=20 - venti starts up.... aaaannd.... et voila: "arenas00: indexing 1169 clumps..." =46rom that point and onward, your venti will insist on performing the index with every reboot and _additionally_, you will be plagued with those previously described 'creation time after last write time' errors - which you need to quickly cat /dev/kprint or they'll often eat up your console ( and suppressing them in arena.c obviously does nothing to prevent the chronic (and lengthy) re-indexing of venti on every reboot ). I'm not trying to prove that I'm not mistaken somewhere, I'm just explaining what I'm seeing, what appears to be preventing me from setting the correct timezone on my terminal, and the precise steps I use to repeatedly=20 reproduce the symptoms involved. This is in an effort to better understand= =20 the problem, but more pragmatically - I just want to know how to set my=20 freakin' timezone accurately without hosing venti... As a corollary - what makes this problem even more vexing, is that somehow venti just kindof "sticks around", even after deleting the partitions, and re-creating and reformatting them via the Plan 9 installer... the problem above will continue to plague unless you fully zero out the plan 9 partitio= ns involved before starting the install. =20 Kind regards, your time and assistance is appreciated - Corey