DiscDev build fail

30Jan18. Intrigued by the mention of new NFS and OmniNFS modules in cvs changes and having noticed that the daily DiscDev build hadn’t but that there was now a build fix, a build was attempted using a direct cvs download from Linux Mint 18.3. The build on the Titanium failed :-

Starting phase resources ...

Cleaning Messages...
amu -E  -k clean COMPONENT=Messages TARGET=Messages NUMLOCALE=01
ADFS::Titan4.$._ROOL.DiscDev.DiscDev.castle.RiscOS.Sources.Internat.Messages.Makefile: would not open
AMU: error reading makefile
Error running make clean on module 'Messages'.
Error creating directory 'Install.ROOL.Disc'.
Fatal error creating directory 'Install.ROOL.Disc'.
Batched errors...
Error running make clean on module 'Messages'.
Error creating directory 'Install.ROOL.Disc'.

Internat.Messages is completely missing, it is not in the Products modules file.

The ‘missing Messages’ was downloaded separately.

NFS 0.71 via !Omni 2.27 on the Titanium can see Moonfish on the RPi3.

Starting phase resources …

The ‘Export resources’ phase should only be used for ROM builds. It collects together all the files that go into ResourceFS, so that they can be used to construct the Messages module. Running that phase when building disc-based components is pointless, and as you’ve discovered the products file typically won’t even bother listing the Messages module.

The ‘Export resources’ phase should only be used for ROM builds.

User error, one too many Builder boxes ticked, thanks.

However though the build does complete there are a lot of pain instances like this :-

Time: Tue Jan 30 17:55:50 2018
Location: Offset 0001358c in module SharedCLibrary
Current Wimp task: Task Obey
Last app to start: rpcgen -i 0 -DWANT_NFS3 -debuglib -h -o h.rquota rquota.x

R0  = 00000000 R1  = 75717200 R2  = 000000ff R3  = 00000001
R4  = 00000008 R5  = 00000000 R6  = 0001837c R7  = 00018324
R8  = 00015404 R9  = 00000001 R10 = 00017088 R11 = 00017c2c
R12 = 01010101 R13 = 00017bf8 R14 = 80808080 R15 = fc156a44
DFAR = 00000000  Mode USR32  Flags nZCv if   PSR = 60000010

fc1569fc : e59f1008 : LDR     R1,&FC156A0C
fc156a00 : e51a221c : LDR     R2,[R10,#-540]
fc156a04 : e0821001 : ADD     R1,R2,R1
fc156a08 : ea00001a : B       &FC156A78
fc156a0c : fc176ebc : Undefined instruction
fc156a10 : e52de004 : STR     R14,[R13,#-4]!
fc156a14 : e2803001 : ADD     R3,R0,#1
fc156a18 : e3100003 : TST     R0,#3
fc156a1c : 0a000004 : BEQ     &FC156A34
fc156a20 : e4d01001 : LDRB    R1,[R0],#1
fc156a24 : e3510000 : CMP     R1,#0
fc156a28 : 0a000010 : BEQ     &FC156A70
fc156a2c : e3100003 : TST     R0,#3
fc156a30 : 1afffffa : BNE     &FC156A20
fc156a34 : e51fc620 : LDR     R12,&FC15641C
fc156a38 : e1a0e38c : MOV     R14,R12,LSL #7
fc156a3c * e4901004 * LDR     R1,[R0],#4
fc156a40 : e041200c : SUB     R2,R1,R12
fc156a44 : e1c22001 : BIC     R2,R2,R1
fc156a48 : e112000e : TST     R2,R14
fc156a4c : 0afffffa : BEQ     &FC156A3C
fc156a50 : e31100ff : TST     R1,#&FF            ; ="ˇ"
fc156a54 : 02400003 : SUBEQ   R0,R0,#3
fc156a58 : 0a000004 : BEQ     &FC156A70
fc156a5c : e3110cff : TST     R1,#&FF00
fc156a60 : 02400002 : SUBEQ   R0,R0,#2
fc156a64 : 0a000001 : BEQ     &FC156A70
fc156a68 : e31108ff : TST     R1,#&00FF0000
fc156a6c : 02400001 : SUBEQ   R0,R0,#1
fc156a70 : e0400003 : SUB     R0,R0,R3
fc156a74 : e49df004 : LDR     PC,[R13],#4
fc156a78 : e3500006 : CMP     R0,#6

R15 = fc156a44 = SharedCLibrary +13594 = strlen +34
R14_usr = 80808080 is nowhere in RAM

USR stack:
00017bf8 : 00008528 : - R14: 00008528 (ASM call to fc156a10)
         :          : | 00008528 = +528 in application memory
         :          : | fc156a10 = SharedCLibrary +13560
         :          : | = strlen +0
00017bfc : 00000001 :

Intrigued by the mention of new NFS […] and having noticed that the daily DiscDev build hadn’t but that there was now a build fix

Yeah, when ROOL processed the scrubbed sources the other week I did some of the usual laundry, but obviously left the old header hanging around. Once checked in properly I neglected to do a clean build – my bad.

However though the build does complete there are a lot of pain instances

I guess nothing else ever used rpcgen, which was imported 9 years ago and not touched since. I’ve given ROOL a prod to see if it can be sorted – in practice the autobuilder runs on a Risc PC class so is blissfully unaware of zero page errors.

Did you get a load from DDEUtils too? Triggered by sed? Those ones are probably soluble too though sed looks a bit scary.

The HardDisc4 build has completed today, so I updated my Omni from there, and I found the following…

If I changed Startup to set Omni$Share to 1, then StartShare failed because <Omni$Dir>.RMStore.Access.KillTask does not exist, so cannot be run. After commenting that Run, it all seems to work and I can now use Access on my RO Shares through Omni. I am not sure if using Access under Omni has any advantages?

If I changed Startup to set Omni$NFS to 1, then NFS becomes available. I have a Synology NAS running NFS, and Sunfish can connect to it (although usually aborts after some use). If I try to connect Omni to the Synology I get an error: RPC communication failed on mount (RPC Service not available on remote host (not registered)), or if I specify an Authenticator of nobody I get RPC communication failed on mount (Cannot find hostname in host database). I can find no mention of an RPC Service on my Synology – where might I be going wrong?

Looking at the draft User Guide OmniClient section I also saw mention of Econet under Omni (and in Startup Obey Apple is mentioned). Is it intended that the modules to support this will also become available? I am unlikely to use Econet, but their availability may help to clarify what should be in the User Guide.

Would it be wise to assume that whatever does become available, it still needs considerable testing to make sure it is fit for purpose today? Or has that testing already been done?

If I changed Startup to set Omni$Share to 1, then StartShare failed because <Omni$Dir>.RMStore.Access.KillTask does not exist, so cannot be run.

I found the errant KillTask in a backup !Omni from my RiscPC. It’s BASIC and works with the new !Omni, Shares can be seen in !Omni and the ShareFS iconbar icon has disappeared.

One has got so used to the unbridgeable rift between RISC OS and macOS that it came as a surprise to find that OmniNFS can see the iMac. Brilliant!!!

If I changed Startup to set Omni$NFS to 1, then NFS becomes available. I have a Synology NAS running NFS, and Sunfish can connect to it (although usually aborts after some use). If I try to connect Omni to the Synology I get an error: RPC communication failed on mount (RPC Service not available on remote host (not registered)), or if I specify an Authenticator of nobody I get RPC communication failed on mount (Cannot find hostname in host database). I can find no mention of an RPC Service on my Synology – where might I be going wrong?

NFS is built ontop of RPC. Chances are your NAS automatically enables the RPC service whenever any relevant systems are enabled (like NFS), or maybe it just leaves it running all the time. Either way, Sunfish should be making use of it when it connects.

When Sunfish connects to your NAS, what settings does it use? There are a few different protocol and transport options available (NFS protocol versions and TCP or UDP transport). Possibly Omni doesn’t support the right set of features.

I am not sure if using Access under Omni has any advantages?

It keeps everything together in one coherent UI, but otherwise no – under the bonnet it still uses ShareFS.

If I changed Startup to set Omni$NFS to 1, then NFS becomes available. I have a Synology NAS running NFS, and Sunfish can connect to it (although usually aborts after some use). If I try to connect Omni to the Synology I get an error: RPC communication failed on mount (RPC Service not available on remote host (not registered)), or if I specify an Authenticator of nobody I get RPC communication failed on mount (Cannot find hostname in host database). I can find no mention of an RPC Service on my Synology – where might I be going wrong?

The authenticator is the name (or IP address) of a server that maps user names to UID’s. If you want to log in as nobody you put that in the “user name” field and leave the authenticator empty. As you might spot from my check in message, I tested it with FreeBSD. I found I needed to add ‘-n’ to the mountd arguments so it would allow connections on any inbound port.

Looking at the draft User Guide OmniClient section I also saw mention of Econet under Omni (and in Startup Obey Apple is mentioned). Is it intended that the modules to support this will also become available? I am unlikely to use Econet, but their availability may help to clarify what should be in the User Guide.

The Econet support is all there (assuming you enabled it in InetSetup). If you have genuine Econet it uses the Econet module, otherwise it’ll be NetI (Econet over IP).

I found the errant KillTask in a backup !Omni from my RiscPC. It’s BASIC and works with the new !Omni, Shares can be seen in !Omni and the ShareFS iconbar icon has disappeared.

ANT’s missing KillTask/Dormant can probably be dispensed with, or recreated from other similar bits (eg. HourOff).

David. Your first post might as well have been mine. Same thoughts and experience.

I’ve got to try again. NFS via Omni was what caught my attention too.

One has got so used to the unbridgeable rift between RISC OS and macOS that it came as a surprise to find that OmniNFS can see the iMac. Brilliant!!!

Does this mean that it’s working for you, or only partially? When I open Omni I can see an entry for my Mac (OS 10.12.6), but I get the RPC error when I try to connect. If yours is working and there’s nothing too top-secret, can you share your Omni settings and the contents of your Mac’s exports file?

When Sunfish connects to your NAS, what settings does it use?

As far as I can tell, NFSv3 and TCP. But although the Sunfish filer seems to work, most of the menu items cause ZP errors, and end in the front-end disappearing after aborts.

Using Omni NFS to my Synology (based on linux), I still cannot get past the RPC errors. Strange that Chris also had these to a Mac, which Dave found works!

I should point out that I only had a few minutes to test before work and may have done something wrong; I took a quick photo of the screen and I now see that I’d left “Directory path” set to “/”; presumably this should be “/Users/myname” so that’ll be the first thing to try when I get home.

Edit: I now have it working read-only; I set Directory path to “/Users” and User name to “nobody”. I only get the RPC server error when I have my actual username in there (putting the server name in Authenticator doesn’t help). The next challenge is making it read/write, which may require tweaks to /etc/exports on the Mac.

exports currently contains:
/Users -alldirs -network 10.0.1.0 -mask 255.255.255.0

One has got so used to the unbridgeable rift between RISC OS and macOS that it came as a surprise to find that OmniNFS can see the iMac. Brilliant!!!

Does this mean that it’s working for you, or only partially?

(My iMac is running High Sierra 10.13.3.)

Having clearly failed to understand the syntax of the Mac etc/exports file, I ‘cheated’ and used NFS Manager. Currently !Omni is showing two mounts, a read only /Users and a read/write /Users/Shared.

Having got a working NFS server on the iMac I now find that Sunfish can connect to it.

Ooh. I have baited my breath…I’m still running El Capitan on my Mac mini though. I send emails from NetSurf to Safari and vice versa, which works…it’d be nice to be able to see the Mac’s hard drive on the Pi!

Currently !Omni is showing two mounts, a read only /Users and a read/write /Users/Shared.

Excellent! Can you please post the output of “cat /etc/exports” (assuming that the are no public IP addresses, passwords, etc in there)?

Edit: Never mind; I didn’t realise that Shared was read/write by default (ie. it doesn’t need anything special in the exports file). The snippet that I posted above is sufficient :)

The authenticator is the name (or IP address) of a server that maps user names to UID’s.

Do you happen to know what sort of server this is? A few non-RISC OS articles mention NIS and LDAP being common choices; is it one of these or something else?

Can you please post the output of “cat /etc/exports”

Edit: Never mind; I didn’t realise that Shared was read/write by default (ie. it doesn’t need anything special in the exports file). The snippet that I posted above is sufficient

exports currently contains:
/Users -alldirs -network 10.0.1.0 -mask 255.255.255.0

The little problem here is turning out to be permissions, files copied from the Titanium to the iMac via NFS arrive with permissions of everyone no access, not very useful!! Adding -mapall=501 to /etc/exports gets around that, NFS sees the iMac as “Me”. Whether it is the right thing to do is another matter.

I noticed that as well. By default only the person that created the files is allowed to look at them, and since the “nobody” user doesn’t map to your normal user in MacOS it doesn’t let you see the files.

I was aware that you could remap in the exports file, but I’d prefer to do things “properly” (probably using the authenticator settings) and then document it all on the wiki. Your method basically throws away all security so although it’s fine on a home network, it’s not really good practice. But it works in a pinch! :)

The other option is to do Access/Public through Filer, but that’ll “get old” fairly quickly.

I was aware that you could remap in the exports file, but I’d prefer to do things “properly” (probably using the authenticator settings) and then document it all on the wiki. Your method basically throws away all security so although it’s fine on a home network, it’s not really good practice. But it works in a pinch!

This is perhaps a bit less bad.

/Users /Users/Shared/Trans /Users/imac/Downloads -mapall=501

Work in progress.

In other news, RISC OS on a case-sensitive filing system is interesting! It seems that there’s some logic in there to correct casing if there isn’t a match.

For example, if I have a directory called “stuff” and I do “Dir Stuff” from the command-line, it still switches to “stuff”. If I have both “stuff” and “Stuff” with different contents, then “Dir stuff” and “Dir Stuff” each open the correct one. “Dir STUFF”, on the other hand, still opens one of them (but I have no idea whether there’s any logic behind which one, or whether it’s unpredictable).

Edit: Here’s an interesting scenario:

1. Create a directory called “Stuff” and put some files in it
2. Type “Dir stuff” followed by “Cat” and confirm that it’s looking at “Stuff”
3. Create a directory called “stuff” (alongside the existing one) and put different files in it
4. Type “Cat” and you’ll see that it’s now looking at “stuff”!

In other words, the currently-selected directory is stored as whatever you typed, and not the actual name returned by the filing system.

The authenticator is the name (or IP address) of a server that maps user names to UID’s.

Do you happen to know what sort of server this is? A few non-RISC OS articles mention NIS and LDAP being common choices; is it one of these or something else?

It expects to get a reply from pcnfsd which it uses as authenticator. My reading of how NFS is typically set up is that you restrict the mount by machine name in your /etc/exports as the main means of trust.

In other news, RISC OS on a case-sensitive filing system is interesting! It seems that there’s some logic in there to correct casing if there isn’t a match.

There’s name cacheing in both FileSwitch and NFS, so it wouldn’t surprise me if you have two directories on the server that vary only by case that the most recently touched will win. With LanManFS if the server has ‘image.jpg’ and ‘image.jpg,c85’ on it you get a Filer window with two files with the same name, if you subsequently double click on either you get the first to be returned by the directory enumeration call to the server.

Meanwhile in a thread far far away…

NFS […] it does not seem to handle filename,filetype so filetypes are lost

Sure that’s the right way round? If anything it’s over zealous about adding comma suffixes because it doesn’t use the MimeMap, so something with a PC extension will always get the comma suffix added too on creation. Conversely if ‘thing.pdf’ was already on the server then it’ll not (currently) be typed &ADF when viewed. Adding MimeMap support would be a nice little project for someone – NFS hadn’t been touched since 2004 and the other clients have moved on since then.

It expects to get a reply from pcnfsd which it uses as authenticator.

Thanks. Unfortunately it looks like I’ll have to give up for now; MacOS doesn’t include pcnfsd and while I was able to build it myself it doesn’t seem to work (presumably things have changed too much since it was written). Omni sees the authenticator but returns “Authorisation failed” and nothing is logged at the Mac end; the log file that it tries to use is documented as obsolete.