[9fans] fs(3) not bound at boot

[9fans] fs(3) not bound at boot

[a]

In /sys/src/9/boot/local.c^connectlocal we have:
	if(bind("#k", "/dev", MAFTER)<0)
I am booting locally off a fossil partition, so I'm pretty
sure this is the right code path. The bind seems to
work (I stuck a test right after that in my local local.c),
but by the time it gets around to starting venti, venti
can't see a file in /dev/fs. When booting finishes, the
file's in #k/fs, but #k isn't mounted anywhere.

Anyone know where/why this is getting lost? I'd like
to boot off a fs(3)-backed venti. I also tried telling
venti to get its arenas directly from #k/fs/arenas, but
that went poorly.
Anthony

Re: [9fans] fs(3) not bound at boot

[geoff]

On the machines where it matters, mostly file servers, we have

bind -a '#k' /dev

in /cfg/$sysname/namespace.  There's a newns() in init.c, at least.

Re: [9fans] fs(3) not bound at boot

[a]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

Right, but how do you get your root file system if it's on a fs(3)
device? It looks like it should work, with connectlocalfossil
just a few lines after the bind in connectlocal, but that doesn't
seem to actually work for me. init.c (and thus /cfg/*) are much
later in the process.
Anthony

[-- Attachment #2: Type: message/rfc822, Size: 1725 bytes --]

From: geoff@plan9.bell-labs.com
To: 9fans@9fans.net
Subject: Re: [9fans] fs(3) not bound at boot
Date: Tue, 6 May 2008 14:13:27 -0400
Message-ID: <eedaa87abfd8f639db71e02bab7d0f5a@plan9.bell-labs.com>

On the machines where it matters, mostly file servers, we have

bind -a '#k' /dev

in /cfg/$sysname/namespace.  There's a newns() in init.c, at least.

Re: [9fans] fs(3) not bound at boot

[Francisco J Ballesteros]

did you write the config?


On Tue, May 6, 2008 at 9:01 PM,  <a@9srv.net> wrote:
> Right, but how do you get your root file system if it's on a fs(3)
>  device? It looks like it should work, with connectlocalfossil
>  just a few lines after the bind in connectlocal, but that doesn't
>  seem to actually work for me. init.c (and thus /cfg/*) are much
>  later in the process.
>  Anthony
>
>
> ---------- Forwarded message ----------
> From: geoff@plan9.bell-labs.com
> To: 9fans@9fans.net
> Date: Tue, 6 May 2008 14:13:27 -0400
> Subject: Re: [9fans] fs(3) not bound at boot
> On the machines where it matters, mostly file servers, we have
>
>  bind -a '#k' /dev
>
>  in /cfg/$sysname/namespace.  There's a newns() in init.c, at least.
>
>

Re: [9fans] fs(3) not bound at boot

[a]

Yes. When the system come up, #k/fs/arenas exists, showing
fs(3) is getting initialized from the disk partition with its config,
and 'venti/conf '#k'/fs/arenas' give the expected results.
Anthony

Re: [9fans] fs(3) not bound at boot

[Christopher Nielsen]

Hrm. This looks familiar, and I think I had a similar problem a long
time ago when I was trying to do the same. I think I had to modify
local.c. I can't check right now, but I will later this evening. If
you haven't found a solution, I'll let you know.

On 5/6/08, a@9srv.net <a@9srv.net> wrote:
> Right, but how do you get your root file system if it's on a fs(3)
> device? It looks like it should work, with connectlocalfossil
> just a few lines after the bind in connectlocal, but that doesn't
> seem to actually work for me. init.c (and thus /cfg/*) are much
> later in the process.
> Anthony
>
>
> ---------- Forwarded message ----------
> From: geoff@plan9.bell-labs.com
> To: 9fans@9fans.net
> Date: Tue, 6 May 2008 14:13:27 -0400
> Subject: Re: [9fans] fs(3) not bound at boot
> On the machines where it matters, mostly file servers, we have
>
> bind -a '#k' /dev
>
> in /cfg/$sysname/namespace.  There's a newns() in init.c, at least.
>
>


--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] fs(3) not bound at boot

[a]

Sigh. This seems to be working for me now. I rebuilt my kernels
after a pull (of nothing that looked relevant) and it just worked as
expected. I'd love to know what was going on, but I doubt I'll
spend any more time on it as each attempt involves rebooting my
file server, which is more disruptive than i'm willing to deal with
for this. Thanks to Geoff and Steve for advice.
Anthony