On Mon, Mar 17, 2025 at 12:00:17PM -0400, o...@eigenstate.org wrote:
> Quoth tlaro...@kergis.com:
> > On Mon, Mar 17, 2025 at 01:52:46PM +0100, Jens Staal wrote:
> > > On Monday, 17 March 2025 11.27.23 Central European Standard Time
> > > tlaro...@kergis.com wrote:
> > > > I wanted to install 9legacy as well as 9front (already installed) on
> > > > my main PC.
> > > >
> > >
> > > What is the purpose? Do you need 2 different kernels? Otherwise, you
> > > could
> > > probably just copy a 9legacy root into a directory and mount that.
> >
> > The purpose is Nix. But you can't just drive a physically put hierarchy
> > served by a server with a different kernel: the kernel has, at least,
> > to be able to serve the hierarchy. Since there is no dynamic linking,
> > there may be a kind of compatibility between executables, but I'm not
> > sure the syscalls are the same between 9legacy and 9front.
>
> The syscalls should be the same, but the file system interfaces may
> have changed here and there. We're largely binary compatible
>
> > Finally, the coexistence between the two is not the problem: the
> > problem---that I hit also when trying to install 9front on a hardware
> > where 9front can't give access to a keyboard because it is USB xhci
> > and there is AMD IOMMU in the way---the problem is;
> >
> > How to correct a filesystem config having hard coded the device it
> > serves when this device has changed?
>
> The config is stored in the start of the file, and the devices are
> the paths to the disks within the cwfs namespace; for example, on
> my cpu server, here's the config I have:
>
> % read -n 20 /dev/sdN0/fscache
> service cwfs
> filsys main c(/dev/sdN0/fscache)(/dev/sdN0/fsworm)
> filsys dump o
> filsys other (/dev/sdN0/other)
> noauth
> newcache
> blocksize 16384
> daddrbits 64
> indirblks 4
> dirblks 6
> namelen 144
>
> You can edit it by hand, or you can edit it at the config console;
> both will work just fine.
Thanks for the explanations! But I may I suggest again that people
knowledgeable about the fileserver review the fsconfig(8). Because of
this:
"If the non-volatile RAM on the server gets erased, it will be
necessary to recreate the configuration."
And this:
"The config and nvram commands identify the device on which
the information is recorded. The config command also erases
any previous configuration."
And this:
"The configuration information is stored in block zero on a
device whose device string is written in non-volatile RAM."
I inspected the NVRAM there was no such thing (but since
other documents explain how to create/recreate the NVRAM by
"garbaging" it first and then calling auth/wrkey, if the name was stored
in the NVRAM, it will be erased when someone is dealing with the
initial authentication...).
The man page continues about things (IP addresses stored) that are not
valid today, it seems?
So I do think the page should be reviewed or a dedicated cwfs64x
config page be derived from the original fs one.
FWIW.
Thanks again!
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Teea5d5b5e6678327-Mcbc2053dd22c191b4a7f7c2d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
