[9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Vladimir Nikishkin]

Hello, everyone.

I hope this is the correct place to ask for help with 9front.

I have booted the latest 9front-8013.d9e940a768d1.amd64.iso in
VirtualBox, played with the livecd a bit, and the typed `inst/start`.

Went through the few steps of the install, and got stuck at ndbsetup.

The step fails with the following error:
after sysname[cirno]:
cp can't stat /n/newfs/lib/ndb/local: '/n/newfs/lib' directory entry not
found.

This does not seem to depend on which network adapter I am using in
VirtualBox.

Meanwhile, network does seem to work at least in the FreeBSD and Windows
10 guests.
The network setting is NAT in VirtualBox, and "automatic" in 9front.

How do I debug this?

Lockywolf

-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Josuah Demangeon]

On Tue, 01 Dec 2020 16:19:36 +0800
Vladimir Nikishkin <lockywolf@gmail.com> wrote:
>
> The step fails with the following error:
> after sysname[cirno]:
> cp can't stat /n/newfs/lib/ndb/local: '/n/newfs/lib' directory entry not
> found.
> 
> This does not seem to depend on which network adapter I am using in
> VirtualBox.

Or maybe it does not depend on the network at all.  As I get it,
/n/newfs/lib is a disk-backed filesystem, and it lacks the /lib
directory.

I would have a look at the disk setup rather than the network. It is
possible to do the whole install without network access as far as
I remember.

-- 
Josuah Demangeon <me@josuah.net>

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Vladimir Nikishkin]

Sure, it may be irrelevant to the network at all. I have to idea, to be
honest, this is my first time doing anything with 9front.

But the `nbdsetup` task is otherwise called "setup network
configuration", so I thought it might be relevant.

`/n/newfs` is indeed empty.

Josuah Demangeon <me@josuah.net> writes:

> On Tue, 01 Dec 2020 16:19:36 +0800
> Vladimir Nikishkin <lockywolf@gmail.com> wrote:
>>
>> The step fails with the following error:
>> after sysname[cirno]:
>> cp can't stat /n/newfs/lib/ndb/local: '/n/newfs/lib' directory entry not
>> found.
>> 
>> This does not seem to depend on which network adapter I am using in
>> VirtualBox.
>
> Or maybe it does not depend on the network at all.  As I get it,
> /n/newfs/lib is a disk-backed filesystem, and it lacks the /lib
> directory.
>
> I would have a look at the disk setup rather than the network. It is
> possible to do the whole install without network access as far as
> I remember.


-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[ori]

Quoth Vladimir Nikishkin <lockywolf@gmail.com>:
> 
> Sure, it may be irrelevant to the network at all. I have to idea, to be
> honest, this is my first time doing anything with 9front.
> 
> But the `nbdsetup` task is otherwise called "setup network
> configuration", so I thought it might be relevant.
> 
> `/n/newfs` is indeed empty.
> 

I strongly suggest qemu or vmware instead of virtualbox; there's
a history of emulation bugs on vbox, so it's very much a "you're
on your own" platform. I've been told it's better now, but I don't
think anyone tests it regularly.

And, yeah -- what josuah said, this is definitely an issue with
mounting the install disk, and not the network. Make sure that
there weren't any errors reaming it or anything.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Vladimir Nikishkin]

I should have read the log output better.
The `copydist` task actually fails with the `bucket 9 is full` error.
I expected the installer to fail too at failed tasks. No wonder it can't
find what does not exist.

I didn't notice that such a large drive would be needed, as the FQA
says, 30Gb. I just took the .iso size, multiplied its size by 10, and
expected that to be enough.

Anyway, thank you everyone.

ori@eigenstate.org writes:

> Quoth Vladimir Nikishkin <lockywolf@gmail.com>:
>> 
>> Sure, it may be irrelevant to the network at all. I have to idea, to be
>> honest, this is my first time doing anything with 9front.
>> 
>> But the `nbdsetup` task is otherwise called "setup network
>> configuration", so I thought it might be relevant.
>> 
>> `/n/newfs` is indeed empty.
>> 
>
> I strongly suggest qemu or vmware instead of virtualbox; there's
> a history of emulation bugs on vbox, so it's very much a "you're
> on your own" platform. I've been told it's better now, but I don't
> think anyone tests it regularly.
>
> And, yeah -- what josuah said, this is definitely an issue with
> mounting the install disk, and not the network. Make sure that
> there weren't any errors reaming it or anything.


-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Iruatã Souza]

On 02/12/2020 05:40, ori@eigenstate.org wrote:
> I strongly suggest qemu or vmware instead of virtualbox; there's
> a history of emulation bugs on vbox, so it's very much a "you're
> on your own" platform. I've been told it's better now, but I don't
> think anyone tests it regularly.
> 

It is not daily use, but my cpu server runs smoothly on virtualbox. I 
never pushed it too far, though.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[ori]

Quoth Iruatã Souza <iru.muzgo@gmail.com>:
> 
> It is not daily use, but my cpu server runs smoothly on virtualbox. I 
> never pushed it too far, though.

Right -- it's likely to work, but it's not actively supported. Use at
your own risk, etc.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[ori]

Quoth Vladimir Nikishkin <lockywolf@gmail.com>:
> 
> I should have read the log output better.
> The `copydist` task actually fails with the `bucket 9 is full` error.
> I expected the installer to fail too at failed tasks. No wonder it can't
> find what does not exist.
> 
> I didn't notice that such a large drive would be needed, as the FQA
> says, 30Gb. I just took the .iso size, multiplied its size by 10, and
> expected that to be enough.
> 
> Anyway, thank you everyone.

Yeah -- cwfs has an archive which reserves a lot of space. It's really
useful being able to look at old snapshots, but it's not suitable for
small disks.

hjfs was written to solve this problem, but it's slower and less
battle tested.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stanley Lieber]

On December 2, 2020 11:46:07 AM EST, ori@eigenstate.org wrote:
>Quoth Vladimir Nikishkin <lockywolf@gmail.com>:
>> 
>> I should have read the log output better.
>> The `copydist` task actually fails with the `bucket 9 is full` error.
>> I expected the installer to fail too at failed tasks. No wonder it
>can't
>> find what does not exist.
>> 
>> I didn't notice that such a large drive would be needed, as the FQA
>> says, 30Gb. I just took the .iso size, multiplied its size by 10, and
>> expected that to be enough.
>> 
>> Anyway, thank you everyone.
>
>Yeah -- cwfs has an archive which reserves a lot of space. It's really
>useful being able to look at old snapshots, but it's not suitable for
>small disks.
>
>hjfs was written to solve this problem, but it's slower and less
>battle tested.

neither file system should have required 30gb. something went wrong here.

sl

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[ori]

Quoth Stanley Lieber <sl@stanleylieber.com>:
> 
> neither file system should have required 30gb. something went wrong here.
> 
> sl
> 

I don't think that the install was attempted with 30gb. The iso is about
0.5gb, so 10*iso would be about 5gb, which *is* too small for cwfs. 

 From recent testing, even 10gb is a bit tight for our default settings on
cwfs. At 10gb, the install succeeds, but a 'mk all' in /sys/src followed
by 'mk install' runs out of the 1gb of cache.

30gb should be comfortable.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stanley Lieber]

On December 2, 2020 1:07:24 PM EST, ori@eigenstate.org wrote:
>Quoth Stanley Lieber <sl@stanleylieber.com>:
>> 
>> neither file system should have required 30gb. something went wrong
>here.
>> 
>> sl
>> 
>
>I don't think that the install was attempted with 30gb. The iso is
>about
>0.5gb, so 10*iso would be about 5gb, which *is* too small for cwfs. 
>
>From recent testing, even 10gb is a bit tight for our default settings
>on
>cwfs. At 10gb, the install succeeds, but a 'mk all' in /sys/src
>followed
>by 'mk install' runs out of the 1gb of cache.
>
>30gb should be comfortable.

ah, i misread the original message.

sl

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[kvik]

Quoth ori@eigenstate.org:
> Yeah -- cwfs has an archive which reserves a lot of space. It's really
> useful being able to look at old snapshots, but it's not suitable for
> small disks.
> 
> hjfs was written to solve this problem, but it's slower and less
> battle tested.

Alternatively, if not preferably (to hjfs), cwfs can be configured
without a dump partition.  Here's how:

	http://docs.a-b.xyz/cwfs.html

How do people feel about making this an option in the installer?

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stanley Lieber]

On December 2, 2020 7:35:41 PM EST, kvik@a-b.xyz wrote:
>
>Quoth ori@eigenstate.org:
>> Yeah -- cwfs has an archive which reserves a lot of space. It's
>really
>> useful being able to look at old snapshots, but it's not suitable for
>> small disks.
>> 
>> hjfs was written to solve this problem, but it's slower and less
>> battle tested.
>
>Alternatively, if not preferably (to hjfs), cwfs can be configured
>without a dump partition.  Here's how:
>
>	http://docs.a-b.xyz/cwfs.html
>
>How do people feel about making this an option in the installer?

i haven't tried this yet, but an option for cwfs without dump would be very much appreciated.

sl

Re: [9front] Cannot

[ori]

> Alternatively, if not preferably (to hjfs), cwfs can be configured
> without a dump partition.  Here's how:
> 
> 	http://docs.a-b.xyz/cwfs.html
> 
> How do people feel about making this an option in the installer?
> 

Uneasy, but not a hard 'no'. Having dumps has saved my ass so many
times that I don't really want to present a default install option
that gets rid of them. Especially since CWFS isn't crash-safe, so
pulling the plug without a dump leaves you without a way to recover.

It's good to have it documented, but putting it as an option in the
install media suggests to me that it's a recommended configuration,
and it's one that I'd really want people to think hard about.

Re: [9front] Cannot

[Stanley Lieber]

On December 2, 2020 8:02:00 PM EST, ori@eigenstate.org wrote:
>> Alternatively, if not preferably (to hjfs), cwfs can be configured
>> without a dump partition.  Here's how:
>> 
>> 	http://docs.a-b.xyz/cwfs.html
>> 
>> How do people feel about making this an option in the installer?
>> 
>
>Uneasy, but not a hard 'no'. Having dumps has saved my ass so many
>times that I don't really want to present a default install option
>that gets rid of them. Especially since CWFS isn't crash-safe, so
>pulling the plug without a dump leaves you without a way to recover.
>
>It's good to have it documented, but putting it as an option in the
>install media suggests to me that it's a recommended configuration,
>and it's one that I'd really want people to think hard about.

let me present you with my counter-scenario:

9front.org worm fills up before i notice it happened (this actually happened at least three times, over the years, which is why we now run hjfs without taking a dump).

there's no recourse. you're just futzed.

sl

Re: [9front] Cannot

[ori]

Quoth Stanley Lieber <sl@stanleylieber.com>:
> 
> let me present you with my counter-scenario:
> 
> 9front.org worm fills up before i notice it happened
> (this actually happened at least three times, over the
> years, which is why we now run hjfs without taking a dump).
> 
> there's no recourse. you're just futzed.
> 
> sl
> 

Fair enough, I'm convinced.

I'd still want to steer users towards a dump, but I'm ok
with adding this as an option to the installer.

Re: [9front] Cannot

[Xiao-Yong Jin]

> On Dec 2, 2020, at 7:28 PM, Stanley Lieber <sl@stanleylieber.com> wrote:
> 
> 9front.org worm fills up before i notice it happened (this actually happened at least three times, over the years, which is why we now run hjfs without taking a dump).

What are the options when worm fills up?  Are there any docs dealing with this situation?

Re: [9front] Cannot

[Stanley Lieber]

On December 2, 2020 9:54:30 PM EST, Xiao-Yong Jin <meta.jxy@gmail.com> wrote:
>
>> On Dec 2, 2020, at 7:28 PM, Stanley Lieber <sl@stanleylieber.com>
>wrote:
>> 
>> 9front.org worm fills up before i notice it happened (this actually
>happened at least three times, over the years, which is why we now run
>hjfs without taking a dump).
>
>What are the options when worm fills up?  Are there any docs dealing
>with this situation?

there are no options. the worm is designed to be read-only. once it's full, it's full.

sl

Re: [9front] Cannot

[Alex Musolino]

I can't comment on what specifically happens when the worm *actually*
fills up - maybe the front falls off entirely  - but I recently
upgraded the storage of my not full fileserver and tried to document
the process [1].

Now, perhaps this is not the correct way to do things and I've just
built myself a time-bomb but nothing seems to have gone awry so far.

kvik, perhaps this could be incorporated into your docs site?

[1] http://musolino.id.au/up/2020/12/03/migrating-cwfs.md

Re: [9front] Cannot

[kvik]

Quoth Alex Musolino <alex@musolino.id.au>:
> [1] http://musolino.id.au/up/2020/12/03/migrating-cwfs.md

Nice writeup!

> kvik, perhaps this could be incorporated into your docs site?

Definitely, I can commit tomorrow.  Thanks!

Re: [9front] Cannot

[kvik]

Quoth Alex Musolino <alex@musolino.id.au>:
> kvik, perhaps this could be incorporated into your docs site?

Done: http://docs.a-b.xyz/migrating-cwfs.html

Contribution very much appreciated, thanks!

Re: [9front] Cannot

[Stuart Morrow]

> Done: http://docs.a-b.xyz/migrating-cwfs.html

I think startdump should be cwcmd startdump

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stuart Morrow]

/n was always for remote-host roots (that and the faces server) - n
for network, I'd imagine. In Plan 9 it became the place for impromptu
mounts, since mntgen(4) is there. This practice should have died the
day we started putting mntgen on /mnt. I would even want this
recommendation to be made somewhere in section 8 of the manual.

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[hiro]

compatibility though we should keep a /mnt/n and a /mnt/usr/n

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stuart Morrow]

> compatibility though we should keep a /mnt/n and a /mnt/usr/n

What. Why.

Anyway, speaking of inst stuff, do people find it acceptable that
fstype only knows Plan 9 filesystems?

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[hiro]

was just a shitty joke.

dunno. is there a non-plan9 fstype implemented in plan9 that supports
our kinds of extensions, like append-only attributes?

On 12/3/20, Stuart Morrow <morrow.stuart@gmail.com> wrote:
>> compatibility though we should keep a /mnt/n and a /mnt/usr/n
>
> What. Why.
>
> Anyway, speaking of inst stuff, do people find it acceptable that
> fstype only knows Plan 9 filesystems?
>

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[Stuart Morrow]

> is there a non-plan9 fstype implemented in plan9 that supports
> our kinds of extensions, like append-only attributes?

Why does that matter? It's fstype, not inst/fstype, you should be able
to use it for identifying disk images at any time, not just install
time.

chattr(1) on Linux btw

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[hiro]

good point, sorry for confusing the intention

On 12/3/20, Stuart Morrow <morrow.stuart@gmail.com> wrote:
>> is there a non-plan9 fstype implemented in plan9 that supports
>> our kinds of extensions, like append-only attributes?
>
> Why does that matter? It's fstype, not inst/fstype, you should be able
> to use it for identifying disk images at any time, not just install
> time.
>
> chattr(1) on Linux btw
>

Re: [9front] Cannot

[Alex Musolino]

Ah, you got me!  I didn't actually try that part, figuring I'd
be well done before 5am rolled around again.  I just jotted it
down when I came across it in my travels.  So, you're right,
startdump is a subcommand of cwcmd.  However, looking at it now,
fs(8) says:

          startdump [01]
               Suspend (0) or restart (1) the background dump process.

But it seems like it actually behaves the other way around:

	cpu% con -C /srv/cwfs.cmd
	cwcmd startdump 1
	dump stopped
	cwdcmd startdump 0
	dump allowed
	\x1c
	>>> q
	cpu% 

Any objections to the following patch to bring cwfs64x inline with the
documentation?

diff -r 91126ac896fa sys/src/cmd/cwfs/cw.c
--- a/sys/src/cmd/cwfs/cw.c	Sat Nov 28 23:03:44 2020 +1030
+++ b/sys/src/cmd/cwfs/cw.c	Fri Dec 04 11:06:49 2020 +1030
@@ -2281,7 +2281,7 @@
 		blockcmp(dev, s1, s2);
 	} else if(strcmp(arg, "startdump") == 0) {
 		if(argc > 2)
-			cw->nodump = number(argv[2], 0, 10);
+			cw->nodump = !number(argv[2], 0, 10);
 		else
 			cw->nodump = !cw->nodump;
 		if(cw->nodump)

Re: [9front] Cannot install 9front-8013.d9e940a768d1.amd64.iso due to network issues

[sl]

> /n was always for remote-host roots (that and the faces server)

just for completeness:

if i understand correctly, /n dates from research unix v8's network
file system (netfs(8)):

	http://man.cat-v.org/unix_8th/8/netfs

sl