9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front]
@ 2022-01-10  8:44 thinktankworkspaces
  2022-01-10 10:21 ` [9front] sirjofri
  2022-01-10 12:10 ` [9front] mkf
  0 siblings, 2 replies; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-10  8:44 UTC (permalink / raw)
  To: 9front

Trying to do an install on a remote server via ssh that has qemu.

I suppose i'm doing this with -nographic

kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
9front-xxxx-i386.iso -m 1024

With pipes such as /tmp/guest.in /tmp/guest.out

I'm receiving data.

Booting from DVD/CD...  *e820 .....  ...  ...  cdboot=yes
mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc


But it stops at that last line and nothing.  Any thoughts or
recommendations?  Is it possible?  Or do I have to build the image
local then copy the 9front.img to remote system.  I worry that I will
run into same situation where it gets stuck.


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-10  8:44 [9front] thinktankworkspaces
@ 2022-01-10 10:21 ` sirjofri
  2022-01-10 17:25   ` [9front] thinktankworkspaces
  2022-01-10 12:10 ` [9front] mkf
  1 sibling, 1 reply; 41+ messages in thread
From: sirjofri @ 2022-01-10 10:21 UTC (permalink / raw)
  To: 9front


10.01.2022 09:44:51 thinktankworkspaces@gmail.com:

> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD...  *e820 .....  ...  ...  cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing.  Any thoughts or
> recommendations?  Is it possible?  Or do I have to build the image
> local then copy the 9front.img to remote system.  I worry that I will
> run into same situation where it gets stuck.

Please check plan9.ini(8) man page and look for console=. I believe 
that's what you want/need.

I can't give more advise since I didn't use it (yet).

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-10  8:44 [9front] thinktankworkspaces
  2022-01-10 10:21 ` [9front] sirjofri
@ 2022-01-10 12:10 ` mkf
  1 sibling, 0 replies; 41+ messages in thread
From: mkf @ 2022-01-10 12:10 UTC (permalink / raw)
  To: 9front

-------- Original Message --------
> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD...  *e820 .....  ...  ...  cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing.  Any thoughts or
> recommendations?  Is it possible?  Or do I have to build the image
> local then copy the 9front.img to remote system.  I worry that I will
> run into same situation where it gets stuck.
>
try console=0.
(before 9boot timeouts and tries to boot)

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-10 10:21 ` [9front] sirjofri
@ 2022-01-10 17:25   ` thinktankworkspaces
  2022-01-10 23:33     ` [9front] sirjofri
  0 siblings, 1 reply; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-10 17:25 UTC (permalink / raw)
  To: 9front

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

Okay this is where it get confusing. So I suspect I mount the 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the contents into another directory and edit the plan9.ini file. Then
repackage the iso with the altered .ini file and reset the boot 
record? Now I have a new but modified iso that has console=0. I can
then try to install it on my target remote system via ssh/

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

From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Mon, 10 Jan 2022 10:21:56 +0000 (UTC)
Message-ID: <3cd7037b-6fa3-4ebd-b602-e65f6989872e@sirjofri.de>


10.01.2022 09:44:51 thinktankworkspaces@gmail.com:

> Trying to do an install on a remote server via ssh that has qemu.
>
> I suppose i'm doing this with -nographic
>
> kind of like qemu-system-x86_64 -serial stdio 9front.img -boot d
> 9front-xxxx-i386.iso -m 1024
>
> With pipes such as /tmp/guest.in /tmp/guest.out
>
> I'm receiving data.
>
> Booting from DVD/CD...  *e820 .....  ...  ...  cdboot=yes
> mouseport=ask monitor=ask vgasize=ask bootfile=/386/9pc
>
>
> But it stops at that last line and nothing.  Any thoughts or
> recommendations?  Is it possible?  Or do I have to build the image
> local then copy the 9front.img to remote system.  I worry that I will
> run into same situation where it gets stuck.

Please check plan9.ini(8) man page and look for console=. I believe 
that's what you want/need.

I can't give more advise since I didn't use it (yet).

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-10 17:25   ` [9front] thinktankworkspaces
@ 2022-01-10 23:33     ` sirjofri
  2022-01-12  1:16       ` [9front] thinktankworkspaces
  0 siblings, 1 reply; 41+ messages in thread
From: sirjofri @ 2022-01-10 23:33 UTC (permalink / raw)
  To: 9front


10.01.2022 18:25:59 thinktankworkspaces@gmail.com:

> Okay this is where it get confusing. So I suspect I mount the 
> 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the 
> contents into another directory and edit the plan9.ini file. Then
> repackage the iso with the altered .ini file and reset the boot
> record? Now I have a new but modified iso that has console=0. I can
> then try to install it on my target remote system via ssh/

I guess after dd'ing the iso to a usb drive you can just edit the 
plan9.ini file in the fat directory. It's not so easy when having to deal 
with CDs for obvious reasons.

However, you should have luck with mounting a copy of the iso, changing 
the file (and saving the iso), then overwriting the first sector(s) with 
the contents of the original iso. Make soure you don't overwrite the FAT 
and contents, the partition tables should be the same anyways.

It's also possible to generate a fresh iso with your settings if you have 
an installed 9front system. You wouldn't need to run sysupdates after 
installation, but this is definitely more work.

Disclaimer: I never did any of these things with 9front.

Good luck

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-10 23:33     ` [9front] sirjofri
@ 2022-01-12  1:16       ` thinktankworkspaces
  2022-01-12  8:30         ` [9front] sirjofri
  0 siblings, 1 reply; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-12  1:16 UTC (permalink / raw)
  To: 9front

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

Super frustrating. I'm sure I'm making it more difficult

I tried following 4.2.2.1

It seems like things should be easier. 9bootfat, 9pc, ini and 9front.iso. I think the frustrating part was being stuck dealing with a
usb device. I don't care about thumb drives. All of this should
be accomplished with an iso or 9front.bin or something similar. 

I ended up doing a dd from /dev/SDUxxx -of cd.iso 

But it was exactly 32G image. I have a limitation because its on 
AWS with an EBS of 32G maximum. 

In theory I should have been mount the ISO and dump the data, then
modify ini. But how in the world do you write the mbr you can't do 
that to a directory

disk/mbr -r mbr /dev/sdUxxx

So really I'm not sure how iso's are created in 9front. I suspect
some sort of rockridge format and a generic bootloader.

Here is what I ended up doing. I fired up qemu locally and performed
the install. Then I logged in and changed the ini file and added
console=0. Then I copied the 9front.img to the AWS ec2 instance. 
Everything came up fine text mode. Nice! and thak you for the help.

Honestly I would like to use the ec2 bare metal. Its already a 
hypervisor. I just don't know what to do to make that happen. I 
suspect I would need to dump the data into another EBS then force
the EC2 to load it. But i'm also not sure of the files required
beyond digging into inst/start and looking at the rc scripts. 

Or a docker would be nice. I saw a docker out there but it was two 
years old. It also ran on alpine linux, so someone manged to copy 
some files over. Maybe I don't want docker. Bare metal is better any thoughts would be much appreciated. 

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

From: sirjofri <sirjofri+ml-9front@sirjofri.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Mon, 10 Jan 2022 23:33:38 +0000 (UTC)
Message-ID: <89cc4583-2f86-49f0-98b6-69dec8c45816@sirjofri.de>


10.01.2022 18:25:59 thinktankworkspaces@gmail.com:

> Okay this is where it get confusing. So I suspect I mount the 
> 9front-xxxx=i386.iso. Which is generally in read only mode. Copy the 
> contents into another directory and edit the plan9.ini file. Then
> repackage the iso with the altered .ini file and reset the boot
> record? Now I have a new but modified iso that has console=0. I can
> then try to install it on my target remote system via ssh/

I guess after dd'ing the iso to a usb drive you can just edit the 
plan9.ini file in the fat directory. It's not so easy when having to deal 
with CDs for obvious reasons.

However, you should have luck with mounting a copy of the iso, changing 
the file (and saving the iso), then overwriting the first sector(s) with 
the contents of the original iso. Make soure you don't overwrite the FAT 
and contents, the partition tables should be the same anyways.

It's also possible to generate a fresh iso with your settings if you have 
an installed 9front system. You wouldn't need to run sysupdates after 
installation, but this is definitely more work.

Disclaimer: I never did any of these things with 9front.

Good luck

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12  1:16       ` [9front] thinktankworkspaces
@ 2022-01-12  8:30         ` sirjofri
  2022-01-12  9:29           ` [9front] Eckard Brauer
  2022-01-12 14:18           ` [9front] Stanley Lieber
  0 siblings, 2 replies; 41+ messages in thread
From: sirjofri @ 2022-01-12  8:30 UTC (permalink / raw)
  To: 9front


12.01.2022 02:16:57 thinktankworkspaces@gmail.com:

> Super frustrating. I'm sure I'm making it more difficult
>
> I tried following 4.2.2.1
>
> It seems like things should be easier. 9bootfat, 9pc, ini and 
> 9front.iso. I think the frustrating part was being stuck dealing with a
> usb device. I don't care about thumb drives. All of this should
> be accomplished with an iso or 9front.bin or something similar.
>
> I ended up doing a dd from /dev/SDUxxx -of cd.iso
>
> But it was exactly 32G image. I have a limitation because its on
> AWS with an EBS of 32G maximum.

Since you dd'd the iso to the usb drive before you can also just dd that 
amount of data back to an image file. I don't exactly know the parameter 
now, but the man page lists it.

> In theory I should have been mount the ISO and dump the data, then
> modify ini. But how in the world do you write the mbr you can't do
> that to a directory
>
> disk/mbr -r mbr /dev/sdUxxx

The sdUxxx directory contails lots of files for lowlevel interaction. E.g 
it contains a ctl and data, and a file for each partition you can mount.

In this case I'm pretty sure you can call the command on the data file 
(which is the disk ignoring all partitions).

> So really I'm not sure how iso's are created in 9front. I suspect
> some sort of rockridge format and a generic bootloader.

9front has its own bootloader, at least for x86/amd64 standard machines. 
However, some people got 9front booting with other linux bootloaders.

As for the iso, I can't really help you. I never created an iso (I 
planned to do it) on 9front with the 9front system.

However, there are commands and filesystem that support the generation of 
iso files in general. I did it some time ago since it is easier to burn 
an iso to cd than a whole directory of files.

lookman iso

> Here is what I ended up doing. I fired up qemu locally and performed
> the install. Then I logged in and changed the ini file and added
> console=0. Then I copied the 9front.img to the AWS ec2 instance.
> Everything came up fine text mode. Nice! and thak you for the help.

Have you tried dding the iso to a usb drive and edit the file in the fat 
directory? (And dding back)

It might even be possible that you can mount the iso somehow and change 
the file there. I'm not sure about it and I don't know how it handles the 
mbr then...

I hope this helps

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12  8:30         ` [9front] sirjofri
@ 2022-01-12  9:29           ` Eckard Brauer
  2022-01-12 13:09             ` [9front] sirjofri
  2022-01-12 14:40             ` [9front] thinktankworkspaces
  2022-01-12 14:18           ` [9front] Stanley Lieber
  1 sibling, 2 replies; 41+ messages in thread
From: Eckard Brauer @ 2022-01-12  9:29 UTC (permalink / raw)
  To: 9front

>  [...]
>
> Since you dd'd the iso to the usb drive before you can also just dd
> that amount of data back to an image file. I don't exactly know the
> parameter now, but the man page lists it.
>
>  [...]

As long as you're on P9, that should work:

dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k

as long as the product of bs and count args are exactly the 32 GB. With
Unix/linux/bsd it should be the same, except that args are as in MVS
(if=/dev/sdY of=outfile.iso etc.).

Problem could be that the initial dd when preparing the usb went to the
(1st?) partition of the USB instead of the raw (whole) device. Maybe
it's possible to read&compare the first few bytes, e.g.

dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x

the same for image.iso

> The sdUxxx directory contails lots of files for lowlevel interaction.
> E.g it contains a ctl and data, and a file for each partition you can
> mount.
>
> In this case I'm pretty sure you can call the command on the data
> file (which is the disk ignoring all partitions).
>
>  [...]
>
> 9front has its own bootloader, at least for x86/amd64 standard
> machines. However, some people got 9front booting with other linux
> bootloaders.

correct, but IMO that works like:

BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel

where the 9pc/9pc64 plan9 bootloader still needs to be in a given
position or to be contiguous on disk - refer "bootloader magic" or the
like somewhere in the fqa.

But didn't try that with qemu at all, IIRC that was the init. problem.

>  [...]
>
> Have you tried dding the iso to a usb drive and edit the file in the
> fat directory? (And dding back)
>
> It might even be possible that you can mount the iso somehow and
> change the file there. I'm not sure about it and I don't know how it
> handles the mbr then...

For little edits NOT violating block boundaries, even in-binary-edits
are fine, did that a few time using sed, but you have to double
(triple,...) check the boundaries before. Or you could even split the
image file apart (with dd) into prefix + file contents + suffix, edit
the 2nd one, compare size and reassemble, if it's contiguous - but all
that's bit dangerous.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12  9:29           ` [9front] Eckard Brauer
@ 2022-01-12 13:09             ` sirjofri
  2022-01-12 13:40               ` [9front] hiro
  2022-01-12 14:40             ` [9front] thinktankworkspaces
  1 sibling, 1 reply; 41+ messages in thread
From: sirjofri @ 2022-01-12 13:09 UTC (permalink / raw)
  To: Eckard Brauer


12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:

>> 9front has its own bootloader, at least for x86/amd64 standard
>> machines. However, some people got 9front booting with other linux
>> bootloaders.
>
> correct, but IMO that works like:
>
> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>
> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
> position or to be contiguous on disk - refer "bootloader magic" or the
> like somewhere in the fqa.

Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd 
/sys/src/9/pc64 && mk install.

But there's also the minimal initial disk or something like that, 
containing some basic programs for networking etc.

sirjofri

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12 13:09             ` [9front] sirjofri
@ 2022-01-12 13:40               ` hiro
  2022-01-12 14:59                 ` [9front] thinktankworkspaces
  0 siblings, 1 reply; 41+ messages in thread
From: hiro @ 2022-01-12 13:40 UTC (permalink / raw)
  To: 9front

correct, and the plan 9 kernel supports being directly loaded by linux
bootloaders just like a linux kernel (where you would have vmlinuz for
example).

On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>
>>> 9front has its own bootloader, at least for x86/amd64 standard
>>> machines. However, some people got 9front booting with other linux
>>> bootloaders.
>>
>> correct, but IMO that works like:
>>
>> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>>
>> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
>> position or to be contiguous on disk - refer "bootloader magic" or the
>> like somewhere in the fqa.
>
> Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
> /sys/src/9/pc64 && mk install.
>
> But there's also the minimal initial disk or something like that,
> containing some basic programs for networking etc.
>
> sirjofri
>

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12  8:30         ` [9front] sirjofri
  2022-01-12  9:29           ` [9front] Eckard Brauer
@ 2022-01-12 14:18           ` Stanley Lieber
  2022-01-12 15:04             ` [9front] thinktankworkspaces
  1 sibling, 1 reply; 41+ messages in thread
From: Stanley Lieber @ 2022-01-12 14:18 UTC (permalink / raw)
  To: 9front

clues here:

http://fqa.9front.org/fqa5.html#5.3

sl

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12  9:29           ` [9front] Eckard Brauer
  2022-01-12 13:09             ` [9front] sirjofri
@ 2022-01-12 14:40             ` thinktankworkspaces
  1 sibling, 0 replies; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-12 14:40 UTC (permalink / raw)
  To: 9front

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

Simply brilliant. I need to save this email somewhere and remember this logic. But honestly I'm 
tired of qemu. I really need to read up on how the booatloader works and how to bootstrap an
AWS ec2 instance. I never used 'xd' command before so thats interesting. There seems to be
some sort of syntatical magic here in plan9 thats missing in other OS's

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

From: Eckard Brauer <eckard.brauer@gmx.de>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 10:29:48 +0100
Message-ID: <20220112102948.4a6d7d53@gmx.de>

>  [...]
>
> Since you dd'd the iso to the usb drive before you can also just dd
> that amount of data back to an image file. I don't exactly know the
> parameter now, but the man page lists it.
>
>  [...]

As long as you're on P9, that should work:

dd -if /dev/sdXXX/disk -of outfile.iso -bs 4k -count 8192k

as long as the product of bs and count args are exactly the 32 GB. With
Unix/linux/bsd it should be the same, except that args are as in MVS
(if=/dev/sdY of=outfile.iso etc.).

Problem could be that the initial dd when preparing the usb went to the
(1st?) partition of the USB instead of the raw (whole) device. Maybe
it's possible to read&compare the first few bytes, e.g.

dd -if /dev/sdXXX -bs 1b -count 1 | xd -1x

the same for image.iso

> The sdUxxx directory contails lots of files for lowlevel interaction.
> E.g it contains a ctl and data, and a file for each partition you can
> mount.
>
> In this case I'm pretty sure you can call the command on the data
> file (which is the disk ignoring all partitions).
>
>  [...]
>
> 9front has its own bootloader, at least for x86/amd64 standard
> machines. However, some people got 9front booting with other linux
> bootloaders.

correct, but IMO that works like:

BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel

where the 9pc/9pc64 plan9 bootloader still needs to be in a given
position or to be contiguous on disk - refer "bootloader magic" or the
like somewhere in the fqa.

But didn't try that with qemu at all, IIRC that was the init. problem.

>  [...]
>
> Have you tried dding the iso to a usb drive and edit the file in the
> fat directory? (And dding back)
>
> It might even be possible that you can mount the iso somehow and
> change the file there. I'm not sure about it and I don't know how it
> handles the mbr then...

For little edits NOT violating block boundaries, even in-binary-edits
are fine, did that a few time using sed, but you have to double
(triple,...) check the boundaries before. Or you could even split the
image file apart (with dd) into prefix + file contents + suffix, edit
the 2nd one, compare size and reassemble, if it's contiguous - but all
that's bit dangerous.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12 13:40               ` [9front] hiro
@ 2022-01-12 14:59                 ` thinktankworkspaces
  2022-01-12 16:56                   ` [9front] hiro
  2022-01-14 11:45                   ` [9front] cinap_lenrek
  0 siblings, 2 replies; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-12 14:59 UTC (permalink / raw)
  To: 9front

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

No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc I feel like when an EC2 is 
launched for the first time its amazon linux or ubuntu which ever you pick. By default it picks up
a t3.micro which also includes an EBS of about 2G. Kind of small but you can resize it. The mbr is
is already written and the bootlaoder is vmlinuz. 

If I swap it out I'm still in an ext2 or ext3/4 file system so it wouldn't matter. So basically 
I create another EBS then tell linux to format it fdisk and set fat then format it. I can set mbr. But 
then its a matter of placing the files in the right directories on that new EBS. Then telling my ec2 linux
to reboot but on a different ebs volume and boom! I'm booting in 9front. I still feel this is a waste or
I'm doing it in the wrong order. 

So right now I have my ec2 running qemu and its working fine. I could also try and tell AWS to spin
up another EBS volume and creatively mount it then run dd if=/mnt/9front.img of=/dev/to_new_volume etc...
with the right flags. 

Then tell ec2 to boot on a new volume. 

I guess the only benefit is speed because qemu works but I was hoping to retire it. At this moment I'm 
starting to feel lazy do I push forward or settle. I need to think. 

Thanks again!

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

From: hiro <23hiro@gmail.com>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 14:40:09 +0100
Message-ID: <CAFSF3XNCiHtVyg=p7jnjuRYWA3LvfMceRH__gqOq-y97oc9LzA@mail.gmail.com>

correct, and the plan 9 kernel supports being directly loaded by linux
bootloaders just like a linux kernel (where you would have vmlinuz for
example).

On 1/12/22, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 12.01.2022 10:29:48 Eckard Brauer <eckard.brauer@gmx.de>:
>
>>> 9front has its own bootloader, at least for x86/amd64 standard
>>> machines. However, some people got 9front booting with other linux
>>> bootloaders.
>>
>> correct, but IMO that works like:
>>
>> BIOS -> "other bootloader" -> 9pc/9pc64 -> plan9 kernel
>>
>> where the 9pc/9pc64 plan9 bootloader still needs to be in a given
>> position or to be contiguous on disk - refer "bootloader magic" or the
>> like somewhere in the fqa.
>
> Afaik the 9pc/64 is the kernel. At least that's what is compiled when cd
> /sys/src/9/pc64 && mk install.
>
> But there's also the minimal initial disk or something like that,
> containing some basic programs for networking etc.
>
> sirjofri
>

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12 14:18           ` [9front] Stanley Lieber
@ 2022-01-12 15:04             ` thinktankworkspaces
  0 siblings, 0 replies; 41+ messages in thread
From: thinktankworkspaces @ 2022-01-12 15:04 UTC (permalink / raw)
  To: 9front

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

OMG thanks. So the mk files handles the ISO creation

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

From: Stanley Lieber <sl@stanleylieber.com>
To: 9front@9front.org
Subject: Re: [9front]
Date: Wed, 12 Jan 2022 14:18:24 +0000
Message-ID: <D9C8C87A-E18D-4127-B204-31E6C8731A28@stanleylieber.com>

clues here:

http://fqa.9front.org/fqa5.html#5.3

sl

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12 14:59                 ` [9front] thinktankworkspaces
@ 2022-01-12 16:56                   ` hiro
  2022-01-14 11:45                   ` [9front] cinap_lenrek
  1 sibling, 0 replies; 41+ messages in thread
From: hiro @ 2022-01-12 16:56 UTC (permalink / raw)
  To: 9front

On 1/12/22, thinktankworkspaces@gmail.com <thinktankworkspaces@gmail.com> wrote:
> No. Is it that easy. can I just swap out vmlinuz with 9bootfat and 9pc

https://fqa.9front.org/fqa3.html#3.3.1.2.1

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2022-01-12 14:59                 ` [9front] thinktankworkspaces
  2022-01-12 16:56                   ` [9front] hiro
@ 2022-01-14 11:45                   ` cinap_lenrek
  1 sibling, 0 replies; 41+ messages in thread
From: cinap_lenrek @ 2022-01-14 11:45 UTC (permalink / raw)
  To: 9front

it is supporting the multiboot standard.

any multiboot capable bootloader (grub, coreboot, qemu,
syslinux, linux kexec) can start our kernel file directly,
the plan9.ini is (optionally) passed as a "module"
(like initrd).

this is done by having a second entry point in the kernel
dedicated for multiboot, which also handles things like
getting the framebuffer configuration and memory map from
multiboot parameters and converting them into internal
plan9.ini format.

9boot and /dev/reboot (yes, you can start a plan9 kernel
from a plan9 kernel) enter the kernel thru the classical
a.out entry point.

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [9front]
@ 2021-09-16 22:17 Drew Fargo
  0 siblings, 0 replies; 41+ messages in thread
From: Drew Fargo @ 2021-09-16 22:17 UTC (permalink / raw)
  To: 9front

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

subscribe

[-- Attachment #2: Type: text/html, Size: 31 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [9front]
@ 2021-08-24 19:25 Jonas
  0 siblings, 0 replies; 41+ messages in thread
From: Jonas @ 2021-08-24 19:25 UTC (permalink / raw)
  To: 9front

unsubscribe

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [9front]
@ 2021-06-09 14:33 adr
  0 siblings, 0 replies; 41+ messages in thread
From: adr @ 2021-06-09 14:33 UTC (permalink / raw)
  To: 9front

unsubscribe

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-02 18:31         ` [9front] cinap_lenrek
@ 2021-04-03  0:41           ` Romano
  0 siblings, 0 replies; 41+ messages in thread
From: Romano @ 2021-04-03  0:41 UTC (permalink / raw)
  To: 9front, cinap_lenrek



On April 2, 2021 6:31:56 PM UTC, cinap_lenrek@felloff.net wrote:
>A quick follow up on the Pallocmem slots.
>
>I just eleminated the array in the last commit, as we can
>caclculate the user page allocation from the conf.mem[]
>array, so the xinit errors can be avoided completely.
>
>Can you confirm that this works on the macbook with
>just increasing the conf.mem[] array size?

I updated and built two ISOs, one with etherbcm added back in to pc64 and one without. The one without bcm boots, but slightly less overall mem is found, the difference being kernel data. Initial:
4009MB memory: 1688M kernel data, 2321M user, 2946M swap
vs changeset 8390:
3928MB memory: 1607M kernel data, 2321M user, 2946M swap

Both kmesgs are available at https://blog.fallglow.com/misc/mbpro

The other ISO, in which I added back in etherbcm, causes the same machine check error as before.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-02 21:24         ` [9front] Romano
@ 2021-04-02 21:54           ` cinap_lenrek
  0 siblings, 0 replies; 41+ messages in thread
From: cinap_lenrek @ 2021-04-02 21:54 UTC (permalink / raw)
  To: 9front

ok, i'll stop trying to get this macbook working in this release
as we obviously need to do more work with etherbcm to get it
supported out of the box.

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-02 14:31       ` [9front] cinap_lenrek
  2021-04-02 18:31         ` [9front] cinap_lenrek
@ 2021-04-02 21:24         ` Romano
  2021-04-02 21:54           ` [9front] cinap_lenrek
  1 sibling, 1 reply; 41+ messages in thread
From: Romano @ 2021-04-02 21:24 UTC (permalink / raw)
  To: 9front, cinap_lenrek



On April 2, 2021 2:31:24 PM UTC, cinap_lenrek@felloff.net wrote:
>This is why we'r loosing amlsost 2GB of user memory because
>of the high fragmentation of the memory map.
>
>The xinit errors are due to us running out of pallocmem slots.
>
>change the Palloc struct in /sys/src/9/port/portdat.h:
>
>-	Pallocmem	mem[16];	/* physical user page banks */
>+	Pallocmem	mem[32];	/* physical user page banks */

Updated, and was able to boot.

>We could also try to minimize the memory loss by sorting the
>Conf.mem[] array by region size.
>
>For the machine check, do you confirm that it is related to
>the bcm ethernet driver? And when you removed the driver
>that it went away?

Yes, I removed the bcm driver and that's how I was able to boot successfully before changing Pallocmem.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-02 14:31       ` [9front] cinap_lenrek
@ 2021-04-02 18:31         ` cinap_lenrek
  2021-04-03  0:41           ` [9front] Romano
  2021-04-02 21:24         ` [9front] Romano
  1 sibling, 1 reply; 41+ messages in thread
From: cinap_lenrek @ 2021-04-02 18:31 UTC (permalink / raw)
  To: 9front

A quick follow up on the Pallocmem slots.

I just eleminated the array in the last commit, as we can
caclculate the user page allocation from the conf.mem[]
array, so the xinit errors can be avoided completely.

Can you confirm that this works on the macbook with
just increasing the conf.mem[] array size?

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-01 23:16     ` [9front] Romano
@ 2021-04-02 14:31       ` cinap_lenrek
  2021-04-02 18:31         ` [9front] cinap_lenrek
  2021-04-02 21:24         ` [9front] Romano
  0 siblings, 2 replies; 41+ messages in thread
From: cinap_lenrek @ 2021-04-02 14:31 UTC (permalink / raw)
  To: 9front

This is why we'r loosing amlsost 2GB of user memory because
of the high fragmentation of the memory map.

The xinit errors are due to us running out of pallocmem slots.

change the Palloc struct in /sys/src/9/port/portdat.h:

-	Pallocmem	mem[16];	/* physical user page banks */
+	Pallocmem	mem[32];	/* physical user page banks */

We could also try to minimize the memory loss by sorting the
Conf.mem[] array by region size.

For the machine check, do you confirm that it is related to
the bcm ethernet driver? And when you removed the driver
that it went away?

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-01 19:03   ` [9front] cinap_lenrek
@ 2021-04-01 23:16     ` Romano
  2021-04-02 14:31       ` [9front] cinap_lenrek
  0 siblings, 1 reply; 41+ messages in thread
From: Romano @ 2021-04-01 23:16 UTC (permalink / raw)
  To: 9front, cinap_lenrek

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



On April 1, 2021 7:03:37 PM UTC, cinap_lenrek@felloff.net wrote:
>i dont see a kernelpanic here.
>
>it seems just that it locks up as soon as it tries to enable the
>broadcom ethernet?
>
>Does the bcm ethernet work before?

It initializes, and can send packets, but never receives any.

>and i see that we run out of conf.mem[] slots (is this 386 or amd64
>kernel?).

amd64

>The easiest is to just increase the number of Confmem slots in
>pc64/dat.h:
>
>-	Confmem	mem[16];	/* physical memory */
>+	Confmem	mem[64];	/* physical memory */
>
>Can you be more specific on what is the regression here?

I know I've replied with my results off-list to your other email you sent, but hadn't tried this yet.  I still get a machine check error, but the inital boot text has a lot of 'xinit' errors. I then commented out the bcm line in pc64 and rebuilt the kernel. That got me a little farther, but now loading hjfs with -m 581 I get an out of memory error. If I use -m 128, I get to rio. Then, if I switch back Confmem to use 16 instead of 64, I still grt the meminit errors but successfully boot using -m 581 with hjfs. (I noticed that the 64 for Confmem set aside a lot more for the kernel and loads more mem overall, but left little for user mem).

Hopefully some of this is helpful.

[-- Attachment #2: IMAG9254.jpg --]
[-- Type: image/jpeg, Size: 1549830 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-01 18:33 ` [9front] Romano
  2021-04-01 18:54   ` [9front] Romano
@ 2021-04-01 19:03   ` cinap_lenrek
  2021-04-01 23:16     ` [9front] Romano
  1 sibling, 1 reply; 41+ messages in thread
From: cinap_lenrek @ 2021-04-01 19:03 UTC (permalink / raw)
  To: 9front

i dont see a kernelpanic here.

it seems just that it locks up as soon as it tries to enable the broadcom ethernet?

Does the bcm ethernet work before?

and i see that we run out of conf.mem[] slots (is this 386 or amd64 kernel?).

The easiest is to just increase the number of Confmem slots in pc64/dat.h:

-	Confmem	mem[16];	/* physical memory */
+	Confmem	mem[64];	/* physical memory */

Can you be more specific on what is the regression here?

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-04-01 18:33 ` [9front] Romano
@ 2021-04-01 18:54   ` Romano
  2021-04-01 19:03   ` [9front] cinap_lenrek
  1 sibling, 0 replies; 41+ messages in thread
From: Romano @ 2021-04-01 18:54 UTC (permalink / raw)
  To: 9front, cinap_lenrek

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

Looks like the second image was not attached.

On April 1, 2021 6:33:48 PM UTC, Romano <unobe@cpan.org> wrote:
>
>
>On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote:
>>Subject: state of emmc and usb on pi400 and cm4
>>I'm in preparation for a new 9front release,
>>fixing penting issues.
>>
>>I have confirmation that the XHCI (USB3) works
>>now on the pi400, but there are still issues with
>>the sdcard.
>>
>>On the CM4, we have to enable the usbdwc driver 
>>(as it does not have the xhci controller chip)
>>in the kernel configuration, but i have no
>>confirmation if this works.
>>
>>So is it possible for anyone owning these devices
>>to troubleshoot this before the end of this week?
>
>I don't have a pi400, but I do have a macbook pro, 13", early 2011.
>With the last release's ISO (8013), it booted and installed fine
>(albeit with a bunch of i8042 warnings and bcm not functioning) . I
>resolved my networking issue by tethering to a pinephone. However, with
>tip I get a kernel panic. I have attached screenshots. Any idea what
>could be the cause?

[-- Attachment #2: IMAG9253.jpg --]
[-- Type: image/jpeg, Size: 1549944 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-03-31 16:32 [9front] cinap_lenrek
@ 2021-04-01 18:33 ` Romano
  2021-04-01 18:54   ` [9front] Romano
  2021-04-01 19:03   ` [9front] cinap_lenrek
  0 siblings, 2 replies; 41+ messages in thread
From: Romano @ 2021-04-01 18:33 UTC (permalink / raw)
  To: 9front, cinap_lenrek

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



On March 31, 2021 4:32:37 PM UTC, cinap_lenrek@felloff.net wrote:
>Subject: state of emmc and usb on pi400 and cm4
>I'm in preparation for a new 9front release,
>fixing penting issues.
>
>I have confirmation that the XHCI (USB3) works
>now on the pi400, but there are still issues with
>the sdcard.
>
>On the CM4, we have to enable the usbdwc driver 
>(as it does not have the xhci controller chip)
>in the kernel configuration, but i have no
>confirmation if this works.
>
>So is it possible for anyone owning these devices
>to troubleshoot this before the end of this week?

I don't have a pi400, but I do have a macbook pro, 13", early 2011. With the last release's ISO (8013), it booted and installed fine (albeit with a bunch of i8042 warnings and bcm not functioning) . I resolved my networking issue by tethering to a pinephone. However, with tip I get a kernel panic. I have attached screenshots. Any idea what could be the cause?

[-- Attachment #2: IMAG9252.jpg --]
[-- Type: image/jpeg, Size: 1550115 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [9front]
@ 2021-03-31 16:32 cinap_lenrek
  2021-04-01 18:33 ` [9front] Romano
  0 siblings, 1 reply; 41+ messages in thread
From: cinap_lenrek @ 2021-03-31 16:32 UTC (permalink / raw)
  To: 9front

Subect: state of emmc and usb on pi400 and cm4

Hola,

I'm in preparation for a new 9front release,
fixing penting issues.

I have confirmation that the XHCI (USB3) works
now on the pi400, but there are still issues with
the sdcard.

On the CM4, we have to enable the usbdwc driver 
(as it does not have the xhci controller chip)
in the kernel configuration, but i have no
confirmation if this works.

So is it possible for anyone owning these devices
to troubleshoot this before the end of this week?

It would be nice to get this fixed and include it
in the upcoming release...

--
cinap

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
@ 2021-01-23 14:12   ` hiro
  0 siblings, 0 replies; 41+ messages in thread
From: hiro @ 2021-01-23 14:12 UTC (permalink / raw)
  To: 9front

send an e-mail message to 9front-owner@9front.org, this time
containing, on a single line, the unsubscribe command.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-01-22 16:32 [9front] Марко М. Костић
  2021-01-22 23:41 ` [9front] Tanami Muller
@ 2021-01-23 13:38 ` Thaddeus Woskowiak
  2021-01-23 14:12   ` [9front] hiro
  1 sibling, 1 reply; 41+ messages in thread
From: Thaddeus Woskowiak @ 2021-01-23 13:38 UTC (permalink / raw)
  To: 9front

On Fri, Jan 22, 2021 at 11:58 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe

One does not simply unsubscribe from 9front.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-01-22 23:41 ` [9front] Tanami Muller
@ 2021-01-23  0:29   ` Stuart Morrow
  0 siblings, 0 replies; 41+ messages in thread
From: Stuart Morrow @ 2021-01-23  0:29 UTC (permalink / raw)
  To: 9front

Polo

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2021-01-22 16:32 [9front] Марко М. Костић
@ 2021-01-22 23:41 ` Tanami Muller
  2021-01-23  0:29   ` [9front] Stuart Morrow
  2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
  1 sibling, 1 reply; 41+ messages in thread
From: Tanami Muller @ 2021-01-22 23:41 UTC (permalink / raw)
  To: 9front

It won't be that easy, my friend.


On Sat, Jan 23, 2021 at 3:28 AM Марко М. Костић
<marko.m.kostic@gmail.com> wrote:
>
> unsubscribe



-- 

Tanami Muller

Chief Technology Officer


Email: tanami@oneworldled.com

Mobile: 0450 107 311
Office: (08) 8374 4557
Address: 1024 South Road, Edwardstown

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [9front]
@ 2021-01-22 16:32 Марко М. Костић
  2021-01-22 23:41 ` [9front] Tanami Muller
  2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
  0 siblings, 2 replies; 41+ messages in thread
From: Марко М. Костић @ 2021-01-22 16:32 UTC (permalink / raw)
  To: 9front

unsubscribe

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
@ 2018-08-20 19:42 umbraticus
  0 siblings, 0 replies; 41+ messages in thread
From: umbraticus @ 2018-08-20 19:42 UTC (permalink / raw)
  To: 9front

> Note, however, that there is a bug in hjfs(4) which means this last
> part won't work.  I already have a patch for this; I'll send it to the
> list now.

Thanks! I didn't realise that the fact I'd switched to hjfs might be relevant
but that is clearly why it worked before and why I am tearing my hair out now.

Will someone commit the patch?

umbraticus


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
@ 2018-08-20 12:11 Alex Musolino
  0 siblings, 0 replies; 41+ messages in thread
From: Alex Musolino @ 2018-08-20 12:11 UTC (permalink / raw)
  To: 9front

Hi,

This is not quite how I have it set up but I think this is probably
the way to go:

Have each mail box, /mail/box/$user/mbox, be owned by upas, with the
group set to $user and the mode set to 0770.  Then run your upas/smtpd
listener as upas.  This will allow upas access to all mail boxes, but
each user will only have access to their own.  Files created by upas
in the mailboxes will be owned by upas and the group will be inherited
from the parent directory.

Note, however, that there is a bug in hjfs(4) which means this last
part won't work.  I already have a patch for this; I'll send it to the
list now.

--
Cheers,
Alex Musolino


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2018-06-06 12:30 Stanislav Paskalev
@ 2018-06-06 15:50 ` Kurt H Maier
  0 siblings, 0 replies; 41+ messages in thread
From: Kurt H Maier @ 2018-06-06 15:50 UTC (permalink / raw)
  To: 9front

On Wed, Jun 06, 2018 at 03:30:13PM +0300, Stanislav Paskalev wrote:
> unsubscribe

if you send this message to 9front-owner@9front.org it might even work

khm


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
@ 2018-02-17  4:53 kokamoto
  0 siblings, 0 replies; 41+ messages in thread
From: kokamoto @ 2018-02-17  4:53 UTC (permalink / raw)
  To: 9front

> 9FRONT "CONTENTS, MAINTAINED, STABLE" RELEASED
> ==============================================

Thank you very much this release!

Now

(1) I can use sandy bridge (Dell desktop) machine without any problem
up tp 1920x1200x32 resolution.

(2) Now I don't need nupas, the generic upas now has its functionarity.

Now I'm wrinting this mail by the new upas program.

Kenji



^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2016-12-28 23:31 sl
@ 2016-12-28 23:33 ` cinap_lenrek
  0 siblings, 0 replies; 41+ messages in thread
From: cinap_lenrek @ 2016-12-28 23:33 UTC (permalink / raw)
  To: 9front

nice! :-)

i like the back picture :-)

--
cinap


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2015-10-02 14:32 ` [9front] Kurt H Maier
@ 2015-10-04 21:18   ` Stanley Lieber
  0 siblings, 0 replies; 41+ messages in thread
From: Stanley Lieber @ 2015-10-04 21:18 UTC (permalink / raw)
  To: 9front

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

Guys, read the tin:

http://lists.9front.org

sl



On Oct 2, 2015, 10:32 AM, at 10:32 AM, Kurt H Maier <khm@sciops.net> wrote:
>On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote:
>> X-Mailer: iPhone Mail (11D257)
>>
>> unsubscribe
>>
>
>hahaha

[-- Attachment #2: Type: text/html, Size: 216 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [9front]
  2015-10-02 11:43 Holger Sebert
@ 2015-10-02 14:32 ` Kurt H Maier
  2015-10-04 21:18   ` [9front] Stanley Lieber
  0 siblings, 1 reply; 41+ messages in thread
From: Kurt H Maier @ 2015-10-02 14:32 UTC (permalink / raw)
  To: 9front

On Fri, Oct 02, 2015 at 01:43:11PM +0200, Holger Sebert wrote:
> X-Mailer: iPhone Mail (11D257)
>
> unsubscribe
> 

hahaha


^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2022-01-14 11:50 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-10  8:44 [9front] thinktankworkspaces
2022-01-10 10:21 ` [9front] sirjofri
2022-01-10 17:25   ` [9front] thinktankworkspaces
2022-01-10 23:33     ` [9front] sirjofri
2022-01-12  1:16       ` [9front] thinktankworkspaces
2022-01-12  8:30         ` [9front] sirjofri
2022-01-12  9:29           ` [9front] Eckard Brauer
2022-01-12 13:09             ` [9front] sirjofri
2022-01-12 13:40               ` [9front] hiro
2022-01-12 14:59                 ` [9front] thinktankworkspaces
2022-01-12 16:56                   ` [9front] hiro
2022-01-14 11:45                   ` [9front] cinap_lenrek
2022-01-12 14:40             ` [9front] thinktankworkspaces
2022-01-12 14:18           ` [9front] Stanley Lieber
2022-01-12 15:04             ` [9front] thinktankworkspaces
2022-01-10 12:10 ` [9front] mkf
  -- strict thread matches above, loose matches on Subject: below --
2021-09-16 22:17 [9front] Drew Fargo
2021-08-24 19:25 [9front] Jonas
2021-06-09 14:33 [9front] adr
2021-03-31 16:32 [9front] cinap_lenrek
2021-04-01 18:33 ` [9front] Romano
2021-04-01 18:54   ` [9front] Romano
2021-04-01 19:03   ` [9front] cinap_lenrek
2021-04-01 23:16     ` [9front] Romano
2021-04-02 14:31       ` [9front] cinap_lenrek
2021-04-02 18:31         ` [9front] cinap_lenrek
2021-04-03  0:41           ` [9front] Romano
2021-04-02 21:24         ` [9front] Romano
2021-04-02 21:54           ` [9front] cinap_lenrek
2021-01-22 16:32 [9front] Марко М. Костић
2021-01-22 23:41 ` [9front] Tanami Muller
2021-01-23  0:29   ` [9front] Stuart Morrow
2021-01-23 13:38 ` [9front] Thaddeus Woskowiak
2021-01-23 14:12   ` [9front] hiro
2018-08-20 19:42 [9front] umbraticus
2018-08-20 12:11 [9front] Alex Musolino
2018-06-06 12:30 Stanislav Paskalev
2018-06-06 15:50 ` [9front] Kurt H Maier
2018-02-17  4:53 [9front] kokamoto
2016-12-28 23:31 sl
2016-12-28 23:33 ` [9front] cinap_lenrek
2015-10-02 11:43 Holger Sebert
2015-10-02 14:32 ` [9front] Kurt H Maier
2015-10-04 21:18   ` [9front] Stanley Lieber

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).