issuing fshalt shuts down rio and gives the following outside rio init: starting /bin/rc term%

[ROuNIN]

Hello,

Recently, I noticed a change from what I do not recall to be the
behavoiur I saw some time ago

When I issue an fshalt, it shuts down rio and give the following
outside rio
init: starting /bin/rc
term%

ROuNIN

[David du Colombier]

Post by ROuNIN
Recently, I noticed a change from what I do not recall to be the
behavoiur I saw some time ago
When I issue an fshalt, it shuts down rio and give the following
outside rio
init: starting /bin/rc
term%

Yes, I got surprised when I first saw this change in may 2011,
but it's just normal behavior.

It kills rio and get back to cga mode to be able to reboot properly.

[Peter A. Cejchan]

is it okay to do ^T^Tr (or, CtlAltDel) then? I guess it is, however..
++pac

[David du Colombier]

Post by Peter A. Cejchan
is it okay to do ^T^Tr (or, CtlAltDel) then? I guess it is, however..

Yes. You just have to wait for your file system
to synchronize and halt.

[erik quanstrom]

Post by David du Colombier

Post by ROuNIN
Recently, I noticed a change from what I do not recall to be the
behavoiur I saw some time ago
When I issue an fshalt, it shuts down rio and give the following
outside rio
init: starting /bin/rc
term%

Yes, I got surprised when I first saw this change in may 2011,
but it's just normal behavior.
It kills rio and get back to cga mode to be able to reboot properly.

given that output, it is not clear that fshalt is really halting.
(expect, using kernel $fu...)

can you still run normal commands afterwards, or has your fs
shut down? you may wish to sprinkle some echoes in the
fshalt script and see where things fail.

- erik

[Peter A. Cejchan]

I've just checked it out, just boot/login/logout:
the terminal went to 'black' (== txt) mode with
prompt:
fsys all sync
main sync: wrote blocks ## why??
(then, cursor blinks until <Enter>)
term%

[David du Colombier]

Post by Peter A. Cejchan
the terminal went to 'black' (== txt) mode with
fsys all sync
main sync: wrote blocks ## why??

fshalt runs fossilcons(4) sync to flush the cache,
before halting the file system.

Post by Peter A. Cejchan
(then, cursor blinks until <Enter>)
term%

It looks fine.

[Peter A. Cejchan]

why did it write anything wnen nothing was changed? just login/fshalt...

Post by David du Colombier
fshalt runs fossilcons(4) sync to flush the cache,
before halting the file system.

[David du Colombier]

Post by Peter A. Cejchan
why did it write anything wnen nothing was changed? just
login/fshalt...

It is likely to be atime updates.

[erik quanstrom]

Post by Peter A. Cejchan
why did it write anything wnen nothing was changed? just login/fshalt...

atime updates.

i'm not convinced that everything is fine. are you running
the current version of fshalt, fossil? there are a couple
of expect scripts hiding in fshalt, and they could easily
be confused.

- erik

[t***@polynum.com]

Post by erik quanstrom

Post by Peter A. Cejchan
why did it write anything wnen nothing was changed? just login/fshalt...

atime updates.
i'm not convinced that everything is fine. are you running
the current version of fshalt, fossil? there are a couple
of expect scripts hiding in fshalt, and they could easily
be confused.

Since I have a vanilla fresh install, I can tell that what is described
is the default behavior. The fs does sync and halt.

The only curious thing is that "fshalt -r" does reboot, but reboots say
Plan9, and not the computer (restarts from 9load it seems). [I'm not
saying it should not or whatever; it is a constatation and it probably
makes sense for a Plan9 terminal.]

[David du Colombier]

Post by t***@polynum.com
The only curious thing is that "fshalt -r" does reboot, but reboots
say Plan9, and not the computer (restarts from 9load it seems). [I'm
not saying it should not or whatever; it is a constatation and it
probably makes sense for a Plan9 terminal.]

It reloads the current kernel using #c/reboot.

[erik quanstrom]

Post by David du Colombier

Post by t***@polynum.com
The only curious thing is that "fshalt -r" does reboot, but reboots
say Plan9, and not the computer (restarts from 9load it seems). [I'm
not saying it should not or whatever; it is a constatation and it
probably makes sense for a Plan9 terminal.]

It reloads the current kernel using #c/reboot.

not correct. it loads the current default kernel,
from /n/boot/$cputype/9xxx. where xxx is determined
by peeking at $terminal.

- erik

[Peter A. Cejchan]

... there've been some issues around pull considering files as locally
modified while they weren't... thus, I have some outdated versions of
everything ... I'll try to edit the pull's output to pull -s list, then
we'll see.
Although unhappy with that, I am spending much time now on linux, writing
in 'Go', as I depend on packages using features introduced after Go 60.2,
sigh...
Thanks, regards,
++pac

[ROuNIN]

Why can we not re-instate the following messages at least the "done
halting":

term% fshalt
syncing.../srv/fscons...prompt: venti...
halting.../srv/fscons...
prompt:
done halting

ROuNIN

[Nicolas Bercher]

Post by ROuNIN
Why can we not re-instate the following messages at least the "done
term% fshalt
syncing.../srv/fscons...prompt: venti...
halting.../srv/fscons...
done halting

That an important point to me: how can I be sure all of the fshalt stuff
is done for good? I'm currently setting up a Plan 9 cpu/fs/auth with
recent iso and this really confused to me at first.

Actually, after (too) many reboots, I saw "done halting" only once.

Nicolas