From: Richard Miller <9fans@hamnavoe.com>
To: users@p9f.org, 9fans@9fans.net
Subject: [9fans] Re: [p9fUsers] Re: Plan 9 rpi nvram not found
Date: Tue, 5 Nov 2024 11:04:28 +0000 [thread overview]
Message-ID: <817da080a097e94ce0b2772ad7869b8f@hamnavoe.com> (raw)
In-Reply-To: <ZyhnwidMOQUY4pOh@ircnow.org>
> Thank you, I managed to get nvram to read properly.
>... No idea what changed, but somehow, upon rebooting, this time
> it worked.
One possibility: if the SD card gets joggled, it may become inaccessible
and the kernel won't automatically reinitialise it. I use the 'diskparts'
command as an alternative to rebooting.
> My $sysname seems to be set to gnot; I couldn't get it to change despite
> trying to define sys= in /lib/ndb/local.
In a "normal" Plan 9 system, /lib/ndb/local may be on a shared file server
used by multiple machines: "local" here means local to your network, not
local to one host. To find sysname, the ndb/cs command looks up the host
in /lib/ndb/local using its ethernet MAC address - but on the pi zero,
there's no ethernet and no hardcoded MAC. An alternative is to add
'sysname=whatever' to the variables in the cmdline.txt file on the SD card.
> I know config.txt says that the pi zero is using [pi1]'s entry but, in
> practice, my rpi zero wh seems to be using the [pi0] entry
The config.txt file is interpreted by the pi firmware, which has been known
to change its behaviour from one release to the next. I guess the comment
should instead say "Pi Zero W *may* use this entry"
> Inside /cfg/gnot/cpustart I added this line:
> aux/listen -q -t /rc/bin/service.auth -d /rc/bin/service tcp
I think it's more usual to put this in /cfg/$sysname/cpurc, not cpustart.
Or uncomment the
And you shouldn't need the '-d /rc/bin/service' because those ports
will be handled by the aux/listen in /bin/cpurc.
> However, when I run $ drawterm -u glenda -c 192.168.86.250 -a
> 192.168.86.250, I see this error:
> cpu: can't dial: 192.168.86.250: Connection refused
> The 'Connection refused' error makes me think that the cpu server is not
> listening at all on port 567.
I think it's the ncpu port (17010) you need first. Try 'netstat|grep Listen'
on the cpu server to confirm what it's listening on.
> Any ideas for how to fix this?
It can be useful to insert a 'flag x +' command into /bin/cpurc so you can
watch the startup script progressing.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9bb336bb1166fd70-M9d32faae3d8ec85241b936a0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
next parent reply other threads:[~2024-11-05 11:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ZyhnwidMOQUY4pOh@ircnow.org>
2024-11-05 11:04 ` Richard Miller [this message]
[not found] <ZyHL2dnIY9IHP8SK@inter9.org>
2024-10-30 14:54 ` Richard Miller
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=817da080a097e94ce0b2772ad7869b8f@hamnavoe.com \
--to=9fans@hamnavoe.com \
--cc=9fans@9fans.net \
--cc=users@p9f.org \
/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).