Hello * Need to update section FQA 4.2.2.1 : At line: disk/fdisk -b /dev/sdUxxxxx/data would be better to add commands in fdisk shell for partition creation.. Next: Create a suitable /n/dos/plan9.ini: < bootfile=9pc > bootfile=9pc64 ... < cp /386/9pc /n/dos > cp /amd64/9pc64 /n/dos As I could see the /386/9pc is absent in last distribution and /amd64/9pc64 is present. Same modifications in section 4.2.2.2 (9pc ->9pc64). Also would be better to point that after makebootfat command need to copy 9front.iso to flashdrive. Sphynkx
thanks, i will look into these suggestions tomorrow evening. sl
sorry for the delay in looking at this. > Need to update section FQA 4.2.2.1 : > > At line: > disk/fdisk -b /dev/sdUxxxxx/data > would be better to add commands in fdisk shell for partition creation.. this will need to be examined when i have more time, but for now i added a comment to type '?' at the fdisk prompt for help. > Create a suitable /n/dos/plan9.ini: > < bootfile=9pc >> bootfile=9pc64 > ... > < cp /386/9pc /n/dos >> cp /amd64/9pc64 /n/dos > > As I could see the /386/9pc is absent in last distribution and > /amd64/9pc64 is present. > > Same modifications in section 4.2.2.2 (9pc ->9pc64). you see amd64 because you booted an amd64 iso. I've added some comments to clarify. > Also would be > better to point that after makebootfat command need to copy 9front.iso > to flashdrive. done. thanks! sl
Oh yes - now better!! =))
The fact now the system is installing mainly on amd64 (in the case of
virtualization) and on arm (in the case of RPi). Therefore, IMHO,
there need to set accent on these architectures, and the rest ones are
mention as options.
Found some typo in link code in section '8.4.9.1 - Tinc'
ср, 29 мар. 2023 г. в 06:35, <sl@stanleylieber.com>:
>
> sorry for the delay in looking at this.
>
>
> > Need to update section FQA 4.2.2.1 :
> >
> > At line:
> > disk/fdisk -b /dev/sdUxxxxx/data
> > would be better to add commands in fdisk shell for partition creation..
>
> this will need to be examined when i have more time, but for now i added a
> comment to type '?' at the fdisk prompt for help.
>
>
> > Create a suitable /n/dos/plan9.ini:
> > < bootfile=9pc
> >> bootfile=9pc64
> > ...
> > < cp /386/9pc /n/dos
> >> cp /amd64/9pc64 /n/dos
> >
> > As I could see the /386/9pc is absent in last distribution and
> > /amd64/9pc64 is present.
> >
> > Same modifications in section 4.2.2.2 (9pc ->9pc64).
>
> you see amd64 because you booted an amd64 iso. I've added some comments to clarify.
>
>
> > Also would be
> > better to point that after makebootfat command need to copy 9front.iso
> > to flashdrive.
>
> done.
>
> thanks!
>
> sl
> The fact now the system is installing mainly on amd64 (in the case of > virtualization) and on arm (in the case of RPi). Therefore, IMHO, > there need to set accent on these architectures, and the rest ones are > mention as options. well, maybe. if we arrive at some agreement on changing the "default" architecture, fine; but to my knowledge nobody has established that yet. 386 was always the starting point. i appreciate that owners of amd64 systems often have no interest in looking back, but we do still have a significant number of 386 users, and the amd64 port in fact still builds code out of the 386 kernel. a significant number of drivers are still disabled (by default)in the amd64 kernel. i am of course happy to revisit this if devs have some preference to the contrary. > Found some typo in link code in section '8.4.9.1 - Tinc' this is fixed now. thanks! sl
On Fri, Mar 31, 2023 at 02:50:44PM -0400, sl@stanleylieber.com wrote:
> > The fact now the system is installing mainly on amd64 (in the case of
> > virtualization) and on arm (in the case of RPi). Therefore, IMHO,
> > there need to set accent on these architectures, and the rest ones are
> > mention as options.
>
> well, maybe. if we arrive at some agreement on changing the "default"
> architecture, fine; but to my knowledge nobody has established that
> yet. 386 was always the starting point. i appreciate that owners of
> amd64 systems often have no interest in looking back, but we do still
> have a significant number of 386 users, and the amd64 port in fact
> still builds code out of the 386 kernel. a significant number of drivers
> are still disabled (by default)in the amd64 kernel.
>
> i am of course happy to revisit this if devs have some preference
> to the contrary.
In addition the raspberry pi is a trash computer and I'm not comfortable
recommending them even implicitly by emphasising them in documentation.
People should try really hard not to use them even when they ARE
available, which is not any more.
khm
another point of view:
there may be many better computers than the raspberry pi, they do work and have been a good choice for me (running plan9) for about 5 years now, and still are.
-Steve
> On 1 Apr 2023, at 9:29 pm, Kurt H Maier <khm@sciops.net> wrote:
>
> On Fri, Mar 31, 2023 at 02:50:44PM -0400, sl@stanleylieber.com wrote:
>>> The fact now the system is installing mainly on amd64 (in the case of
>>> virtualization) and on arm (in the case of RPi). Therefore, IMHO,
>>> there need to set accent on these architectures, and the rest ones are
>>> mention as options.
>>
>> well, maybe. if we arrive at some agreement on changing the "default"
>> architecture, fine; but to my knowledge nobody has established that
>> yet. 386 was always the starting point. i appreciate that owners of
>> amd64 systems often have no interest in looking back, but we do still
>> have a significant number of 386 users, and the amd64 port in fact
>> still builds code out of the 386 kernel. a significant number of drivers
>> are still disabled (by default)in the amd64 kernel.
>>
>> i am of course happy to revisit this if devs have some preference
>> to the contrary.
>
> In addition the raspberry pi is a trash computer and I'm not comfortable
> recommending them even implicitly by emphasising them in documentation.
> People should try really hard not to use them even when they ARE
> available, which is not any more.
>
> khm
Quoth Steve Simon <steve@quintile.net>:
> another point of view:
>
> there may be many better computers than the raspberry pi, they do work and have been a good choice for me (running plan9) for about 5 years now, and still are.
>
Today, a used NUC can be had for far less, and runs
far better. Even before the prices skyrocketed, an
old thinkpad was a comparably priced choice, but
beefier.
(though, it's good to have non-x86 boxes, just to
make sure we're keeping things portable)
On Sat, Apr 01, 2023 at 09:52:13PM +0100, Steve Simon wrote:
> another point of view:
>
> there may be many better computers than the raspberry pi, they do work and have been a good choice for me (running plan9) for about 5 years now, and still are.
This is useful information for people who are you. Just today we had
someone contact us with wild-ass malfunctions in a Raspberry Pi USB
controller. I am glad that you have hardware that serves you but people
who are considering buying a Raspberry Pi are not guaranteed a good
experience and it is not worth rewriting the FQA to pretend otherwise.
khm
2023-04-02T07:14:53Z Kurt H Maier: > I am glad that you have hardware that serves you but people > who are considering buying a Raspberry Pi are not guaranteed a good > experience As a Linux user, I don't recommend installing Linux on RPI either, and I use it only for testing. But, I've started playing with 9front 4 weeks ago *because* I had a spare "computer" (RPI) and I've found the RPI image from 9front.org. > and it is not worth rewriting the FQA to pretend otherwise. What's the purpose of having/maintaining the FQA if not for newcomers ? A very short handbook with auth/fs installation info is more than enough for regular users of 9front/plan9. The FQA looks like a newcomer's guide/map/overview, and the chances that newcomers are starting with RPI might be higher than you think. Just to be very clear, I understand the feeling of voluntarily maintaining something that you don't need and I'm grateful to those who put together this FQA, maintaining it in whatever form they think is best.
Using a USB SSD helps though (there are also SSD USB sticks, and hubs can be used for external power...) and using the original Power Supply. At least for the USB part the FQA can be used to look that up.
On April 2, 2023 7:29:07 AM EDT, Philip Silva <philip.silva@protonmail.com> wrote:
>Using a USB SSD helps though (there are also SSD USB sticks, and hubs can be used for external power...) and using the original Power Supply. At least for the USB part the FQA can be used to look that up.
>
>
i experimented with an rpi4 file server backed by usb ssd. i stopped using it because parallel reads and writes routinely froze the system for interminable periods.
here's a tangentially related stupid story:
the thinkpad x1 yoga 3rd gen won't boot from a drive in its wwan slot, and 9front can't quite access the nvme i put in that slot, and i didn't want to erase the main hard drive, so i spent a week booting from an installation (not just the iso) on a usb stick. this sucked for similar reasons as above, so i installed to a micro sdcard in the internal micro sdcard slot (and continued booting the kernel from the usb stick because the machine can't boot from the micro sdcard slot either). this sucked less, but still sucks because write speeds are slow.
it's valuable that all these things kind of work, but they only kind of work. depending on what you're doing with the computer usb may be fine. but it sucks.
sl
> i experimented with an rpi4 file server backed by usb ssd. i stopped using it because parallel reads and writes routinely froze the system for interminable periods.
Ah ok, I've definitely also seen freezes so that I couldn't connect anymore at all without power cycling. Although I never narrowed it down whether it was because of USB or messed up login config. I'm now running 2 Rasperries with SD (with a network mount/ramfs for writes), not sure when I saw the system freezing the last time
Although actually I had the login problem just now - after having it idling for a week or so. The Raspberry is still pingable but I cannot connect anymore to it. (Although of course the Ethernet is also on the USB bus...)
rpi4 has ethernet on pcie
On 4/2/23, Philip Silva <philip.silva@protonmail.com> wrote:
> Although actually I had the login problem just now - after having it idling
> for a week or so. The Raspberry is still pingable but I cannot connect
> anymore to it. (Although of course the Ethernet is also on the USB bus...)
>
>
On Sun, Apr 02, 2023 at 09:40:03AM +0000, ooga@e.email wrote:
> > and it is not worth rewriting the FQA to pretend otherwise.
>
> What's the purpose of having/maintaining the FQA if not for newcomers ? A very short handbook with auth/fs installation info is more than enough for regular users of 9front/plan9. The FQA looks like a newcomer's guide/map/overview, and the chances that newcomers are starting with RPI might be higher than you think.
I didn't say the FQA is not for newcomers, I said it's not worth
rewriting the FQA to make the Raspberry Pi more prominent, because
newcomers will be better served, on average, by better computers.
In other words, we focus a lot on older Thinkpads and Intel wifi,
because we know that this hardware works more frequently with fewer
mysterious problems. This is part of the point of the sysinfo effort;
new users can see what hardware people are using.
Lots of newcomers start with Virtualbox, which is the Raspberry Pi of
virtualization tools, but that doesn't make Virtualbox worth focusing
on.
khm
> In addition the raspberry pi is a trash computer and I'm not comfortable
> recommending them even implicitly by emphasising them in documentation.
> People should try really hard not to use them even when they ARE
> available, which is not any more.
I would be heavily interested in viable alternatives that use as little
power as a rpi2.
The rpi2 is a great allrounder regarding energy limitations from my cabin
in the woods while offering a default linux as a fallback if I'm forced to
commit treason.
X200 Thinkpads are great as well. But having limited energy supply from solar
panels forces me to ignore other comforts.
I know this is very specific to my needs, but I seldom see much talk of
other micro computers (desktop/server) (especially regarding 9) and would
happily try out some alternatives.
> I know this is very specific to my needs, but I seldom see much talk of
> other micro computers (desktop/server) (especially regarding 9) and would
> happily try out some alternatives.
Although I know that one doesn't get specific platform support by means of
wishing for it.
9front is indeed mainly developed for specific (common) targets. If someone
requires more specific hardware to run reliable, he probably has to do some
patching himself.
I was mainly asking for options/work-in-progress projects I didn't see advertised
in the well-known resources. (I doubt there are any)
So excuse me for expecting some magic micro controller/computer support out of
thin air. I'm just not that educated when it comes to latest hardware products
and the like and probably just fell for the easy choice of going with something as
common as the pi (which is at least viable on 9front to some degree).
The repeated critique of rpi's just got me curious if someone knows something that
I don't.
There is now a kernel for the Mediatek mt7688 in 9Front. It needs drivers for wifi and i2c and such, but it is a start. I do have a couple other work-in-progress kernels for Arm and Mips. https://github.com/adventuresin9?tab=repositories The Raspberry Pi gets downplayed because it is one of the more difficult chips to work with. Much of the functionality is controlled by the GPU, and Broadcom isn't very open about how to work with it. Most Arm chips are going to have some kind of compromise because they are designed for some particular application. On Mon, Apr 3, 2023 at 4:54 AM <chris@chrisfroeschl.de> wrote: > > > I know this is very specific to my needs, but I seldom see much talk of > > other micro computers (desktop/server) (especially regarding 9) and would > > happily try out some alternatives. > > Although I know that one doesn't get specific platform support by means of > wishing for it. > > 9front is indeed mainly developed for specific (common) targets. If someone > requires more specific hardware to run reliable, he probably has to do some > patching himself. > > I was mainly asking for options/work-in-progress projects I didn't see advertised > in the well-known resources. (I doubt there are any) > > So excuse me for expecting some magic micro controller/computer support out of > thin air. I'm just not that educated when it comes to latest hardware products > and the like and probably just fell for the easy choice of going with something as > common as the pi (which is at least viable on 9front to some degree). > > The repeated critique of rpi's just got me curious if someone knows something that > I don't. >
On April 3, 2023 2:09:39 PM EDT, adventures in9 <adventuresin9@gmail.com> wrote:
>There is now a kernel for the Mediatek mt7688 in 9Front. It needs
>drivers for wifi and i2c and such, but it is a start.
>
>I do have a couple other work-in-progress kernels for Arm and Mips.
>https://github.com/adventuresin9?tab=repositories
>
>The Raspberry Pi gets downplayed because it is one of the more
>difficult chips to work with. Much of the functionality is controlled
>by the GPU, and Broadcom isn't very open about how to work with it.
>Most Arm chips are going to have some kind of compromise because they
>are designed for some particular application.
>
>On Mon, Apr 3, 2023 at 4:54 AM <chris@chrisfroeschl.de> wrote:
>>
>> > I know this is very specific to my needs, but I seldom see much talk of
>> > other micro computers (desktop/server) (especially regarding 9) and would
>> > happily try out some alternatives.
>>
>> Although I know that one doesn't get specific platform support by means of
>> wishing for it.
>>
>> 9front is indeed mainly developed for specific (common) targets. If someone
>> requires more specific hardware to run reliable, he probably has to do some
>> patching himself.
>>
>> I was mainly asking for options/work-in-progress projects I didn't see advertised
>> in the well-known resources. (I doubt there are any)
>>
>> So excuse me for expecting some magic micro controller/computer support out of
>> thin air. I'm just not that educated when it comes to latest hardware products
>> and the like and probably just fell for the easy choice of going with something as
>> common as the pi (which is at least viable on 9front to some degree).
>>
>> The repeated critique of rpi's just got me curious if someone knows something that
>> I don't.
>>
>
damn dude
03.04.2023 21:15:47 Stanley Lieber <sl@stanleylieber.com>:
> > damn dude
That's always my reaction when I notice that adventuresin9 is working on yet another 9front kernel port. Incredible!
sirjofri
no. the ethernet for the pi4 is in the soc and not related to pcie. it is the xhci controller that is connected to the pcie lane. -- cinap
> 9front can't quite access the nvme i put in that slot, and i didn't want to erase the main hard drive
do you see the drive in "pci -v" output?
i had a similar issue on x230. i got a mpcie to m.2 adapter,
but the bios has a whitelist and wont allow a nvme drive
in this slot.
i solved it by flashing a hacked bios that removed these
restrictions.
i'm now using a x230 motherboard without display or keyboard
as my file server in this configuration, using serial console
over intel me thing for console access.
--
cinap
On April 6, 2023 10:19:45 AM EDT, cinap_lenrek@felloff.net wrote: >> 9front can't quite access the nvme i put in that slot, and i didn't want to erase the main hard drive > >do you see the drive in "pci -v" output? > >i had a similar issue on x230. i got a mpcie to m.2 adapter, >but the bios has a whitelist and wont allow a nvme drive >in this slot. > >i solved it by flashing a hacked bios that removed these >restrictions. > >i'm now using a x230 motherboard without display or keyboard >as my file server in this configuration, using serial console >over intel me thing for console access. > >-- >cinap > i posted about it here on the mailing list at the time[0]. the drive is detected and usable by openbsd. it is also detected by 9front, but the kernel bails out on it during boot: sdN (nvme): create completion queue: status 102 then: % cat '#'S/sdctl sdN nvme 0 units sysinfo here: http://okturing.com/src/14842/body sl [0] https://inbox.vuxu.org/9front/CABO6shf22OXu4p0F3rmi_3kkhujtkxULzzpXKWZRUy-99RkmDQ@mail.gmail.com/T/#m06c1cbfb737552e8d2d482a9b63af875f7d2d06f