9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Corey <corey@bitworthy.net>
To: 9fans@9fans.net
Subject: Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'
Date: Tue, 28 Jul 2009 15:42:50 -0700	[thread overview]
Message-ID: <200907281542.50518.corey@bitworthy.net> (raw)
In-Reply-To: <73922819731eb511895ad1959a18a486@coraid.com>

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 time
> >   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 
rtc is not somehow becoming reset or changed at any point)


> your problem is with the rtc.  it sounds like between your install and your
> 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=


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 confirm
       that bios clock is still in fact set accurately to UTC

#6 - reboot, (first-time login), as glenda: 
         - 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: 
         - venti starts up.... aaaannd.... et voila:
           "arenas00: indexing 1169 clumps..."

From 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 
reproduce the symptoms involved. This is in an effort to better understand 
the problem, but more pragmatically - I just want to know how to set my 
freakin' timezone accurately without hosing venti...  <grin>


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 partitions
involved before starting the install.

 
Kind regards, your time and assistance is appreciated -

Corey




  parent reply	other threads:[~2009-07-28 22:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <664879e97485933b3ca1bc9e37760730@quanstro.net>
2009-07-28  5:05 ` Corey
2009-07-28 13:22   ` erik quanstrom
2009-07-28 15:16     ` Russ Cox
2009-07-28 22:14       ` Dave Eckhardt
2009-07-28 22:16         ` erik quanstrom
2009-07-28 22:56           ` Corey
2009-07-29  1:42           ` Russ Cox
2009-07-29  4:24             ` Corey
2009-07-29  8:54               ` Corey
2009-07-29 14:02                 ` Steve Simon
2009-07-29 14:48               ` Russ Cox
2009-07-28 22:42     ` Corey [this message]
2009-07-28 23:50       ` erik quanstrom
     [not found] <09c88626d985457ecaa621715f4f1af0@quanstro.net>
2009-07-29  0:42 ` Corey
2009-07-29  1:04   ` erik quanstrom
     [not found] <26a2b1a9fb6ec5947c440b48b8bde174@quanstro.net>
2009-07-27 23:56 ` Corey
2009-07-28  0:35   ` erik quanstrom
2009-07-28  8:52   ` Steve Simon
2009-07-27  1:03 Corey
2009-07-27 16:28 ` Russ Cox
2009-07-27 20:31   ` Corey
2009-07-27 20:38     ` erik quanstrom
2009-07-27 20:58       ` Corey
2009-07-27 22:49       ` Corey
2009-07-27 22:52         ` erik quanstrom
2009-07-27 20:56     ` Lyndon Nerenberg
2009-07-30  4:15 ` Corey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200907281542.50518.corey@bitworthy.net \
    --to=corey@bitworthy.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).