02/06 ROM can't find System:

During module initialisation I’m seeing the message;

ColourDbox =>Error: Filing system or path System: not found

and on boot consequently;

Error: File ‘System:Modules.Toolbox.ColourDbox’ not found

ROMModules shows ColourDbox as dormant. An attempt to reinit ColourDbox generates ‘System:Modules.Picker’ not found (Error number &D6).

Might just be me? The last two updates (30/05 & today’s) wouldn’t start if updated with SDFS drag & drop, leaving the BB -xm with just a power light. Writing the uSD image with SDCreate works fine for the 30/05 ROM but not the 02/06. Perhaps duff uSD? To add to my confusion, going from the 02/06 ROM back to the 30/05 ROM by *Desktop then dragging the ROM to the SDFS filer gives a working machine contrary to the above. Not sure if I’m seeing one issue or two.

I’ll try another uSD but thought to see if the assembled expertise recognised anything first.

Sounds like the click over to 5.21 has left you with ColourPicker unplugged. Type

*UNPLUG

The last two updates (30/05 & today’s) wouldn’t start if updated via SDCreate

I don’t have an explanation for that, nothing interesting happened on the 29th May.

Sounds like the click over to 5.21 has left you with ColourPicker unplugged.

That was it – Thanks. I had SDCMOS unplugged. That module seems to have disappeared so ColourPicker may have taken its spot.

The last two updates (30/05 & today’s) wouldn’t start if updated via SDCreate

No, that’s the way it did work – via SDFS was the problem. Can’t repeat that now. If it happens again I’ll try a new card.
Anyone know of a way to differentiate between lot’s of little black squares that all look the same :-)

I just did a fresh install of 5.21 and latest HardDisc4 in RPCEmu. I’m getting an error from all the configure plugins about the ‘Messages’ file not being found.
Also the rom download page still shows 5.19 on the main page and the zip file names.

Sounds like the click over to 5.21 has left you with ColourPicker unplugged.

That was it – Thanks.

Good stuff!

Anyone know of a way to differentiate between lot’s of little black squares that all look the same :-)

A blob of (different colour) modelling paint/nail varnish on each?

I’m getting an error from all the configure plugins about the ‘Messages’ file not being found.

Hmm, something might have gone wrong in the disc build, I’ll go and look.

Also the rom download page still shows 5.19 on the main page and the zip file names.

It is Sunday. ROOL are probably having a lie in!

I just did a fresh install of 5.21 and latest HardDisc4 in RPCEmu. I’m getting an error from all the configure plugins about the ‘Messages’ file not being found.

Messages files missing from RO500Hook.Res.*

Also the rom download page still shows 5.19 on the main page and the zip file names

Probably the autobuilder not set to create 5.21 based names. Maybe that is a case of picking the filename from the build so that 5.21.0001 … 5.21.9999 are automatic and users get a definite version number to quote in any problem reports.

Messages files missing from RO500Hook.Res.*

Bah. Looks like that makefile dependency I kicked under the carpet has come back to haunt me. Try again in a few hours folks…

Bah. Looks like that makefile dependency I kicked under the carpet has come back to haunt me.

Those who never did anything wrong, never did anything.
How many changed items in recent days?!

Try again in a few hours folks…

I think I’m fine, unless there are post May 19th changes. I picked out the messages bit with a comparison of the decompressed 06/02 HD image and my existing with the May 19th RO500Hook

Just to add to the fun…

I’ve found that the resolver problem has returned. I can get mail & usenet going by setting an obey file to ReInit Resolver but that doesn’t seem to work for fetching the time. I’ve found that I can make that work if the BB -xm’s clock is set manually to other than 02/01/1970 (say 1st Jan 2013). Is there a command I can use in the obey file to do this?

The date change was a false lead. If Time & date config is set to be ‘Set manually’ followed by ‘Set from network’ Sync succeeds.

How many changed items in recent days?!

Not sure – but the writing has worn off some of the keys on my keyboard! There’s a revised disc image up now which should have any missing bits back in it.

I’ve found that the resolver problem has returned.

I’ve had an RMREINIT Resolver in my PopStar run file since RISC OS 4, as that runs after boot. Unfortunately Resolver sources are still locked in the legal cupboard at ANT, so even if some theory could be formed as to what is causing it to trip up sometimes, there’s no (easy) way to try.

I’ve had an RMREINIT Resolver in my PopStar run file since RISC OS 4, as that runs after boot.

Unfortunately that’s not a solution this time for time. If I RMReinit after boot has finished it seems to work for fetching mail & news but the time is not fetched which is a problem for a battery free BB -xm. The only way I can get time fetched is to open the time config, select ‘Set manually’ & ‘Set’, open time config, set ‘Set from network’ & ‘Set’. It’s as if there’s a new separate bug with the Time & Date config/fetcher.

Reverted back to the 22 May ROM and all’s ok so would seem to be to do with the ROM image. Tried a different uSD anyway but had the same result. So left with issues with 30 May & 02 June. Same disc image for all (updated 02 June).

[Resolver…] Unfortunately that’s not a solution this time for time.

If you RMReinit the resolver then the time lookup that NetTime is sitting waiting to be resolved would be cancelled with it knowing. You could try (after the RMReinit) doing a NetTime_Kick to force a new name resolution to be started.

Reverted back to the 22 May ROM and all’s ok so would seem to be to do with the ROM image.

Do you use DHCP to get the DNS addresses? Or have you entered them into the two boxes in DNS setup in configure?
Does a

*RESOLVERCONFIG

Sounds like the click over to 5.21

What click over to 5.21? The Software tab still shows 5.19 this morning?

Edit: the html says 5.19 but the actual rom image is 5.21 – so where is 5.20? I presume it is undergoing testing. Can version 5.20 be downloaded from the CVS and built yet?

You could try (after the RMReinit) doing a NetTime_Kick to force a new name resolution to be started.

I should have mentioned I’m using an obey file with both commands instead of assuming that would be realised

Do you use DHCP to get the DNS addresses?

Yes, DHCP.

Does a *RESOLVERCONFIG rather than an RMReinit similarly help?

I’ll try that next time I’m at the BB

Unfortunately Resolver sources are still locked in the legal cupboard at ANT

Speaking from ignorance of what’s involved, would a replacement be beyond the scope of a bounty? I would think it would be popular.

Speaking from ignorance of what’s involved, would a replacement be beyond the scope of a bounty? I would think it would be popular.

A few years ago I sort of persuaded Frank de Bruijn to spend time on a DNS blacklist feature in AntiSpam.
Not wanting to dig a big hole and get earache about it I test ported a Linux lookup tool to prove the concept before badgering him too much. Satisfying myself it wasn’t impossible I started nudging. He found the same problem I did (Resolver is rather limited in its abilities and broken to boot¹) and being sufficiently talented (better than a simple twiddler like me) he wrote a resolver module ==> NSQ.

###############################
Resolver SWI list :

Generated by : !Swish 0.14 (12 Jul 2007)
Generated on : Mon 03 Jun 2013. 07:02 PM
-—————————————————————————————————————-
Module : Resolver 0.69 (11 Jul 2004)
Chunk base : &46000
&046000 Resolver_GetHostByName
&046001 Resolver_GetHost
&046002 Resolver_GetCache
&046003 Resolver_CacheControl
-—————————————————————————————————————-

NSQ SWI list :

Generated by : !Swish 0.14 (12 Jul 2007)
Generated on : Mon 03 Jun 2013. 07:01 PM
-—————————————————————————————————————-
Module : NSQ 0.36 (25 Oct 2011)
Chunk base : &58200
&058200 NSQ_ByName
&058201 NSQ_ByAddress
&058202 NSQ_CheckBL
&058203 NSQ_TestZones
&058204 NSQ_Cache
&058205 NSQ_State
&058206 NSQ_IPAddress
&058207 NSQ_Results
&058208 NSQ_Country
-—————————————————————————————————————-
#############################

In short, and Frank is the only one who can say yes or no, I think the alternate resolver may already exist, and it doesn’t muck up reverse resolution like Resolver.

¹ Frank points out the main broken element of Resolver:
Introduction
-————-
This module came about when I wanted to implement the use of DNS Block Lists
for AntiSpam and discovered that the default Resolver module was useless for
that purpose, because it assumes that any query that has a request field
starting with a dotted quad (e.g. 12.34.56.78) is a reverse lookup using the
in-addr.arpa zone. Which is incredibly stupid but probably unavoidable
because of the broken design of that module: you can’t TELL it to perform a
reverse lookup – it has to decide you want one by itself.

Unfortunately, NSQ is not a ‘drop in replacement’ for Resolver. I designed it with AntiSpam in mind and that meant it didn’t have to be able to return standard hostent structures. I suppose it would be possible to add that functionality, but I’m currently rather busy with other projects. And before anyone suggests taking over its development, it’s coded in assembler…

And before anyone suggests taking over its development, it’s coded in assembler…

Ah, but you have the source and the copyright. That means the ROOL guys could have access to commented source that isn’t going to give them legal nightmares.
Sprows response suggests that the show stopper for any resolver development based on the existing module is legal rather than technical.
Many of these things are easier to alter than build from scratch.

Ah, but you have the source and the copyright. That means the ROOL guys could have access to commented source that isn’t going to give them legal nightmares.

They’ll get another kind of nightmare when they realise what an awfull programmer I am… :-)
I just looked at my project directory for NSQ. Good grief! Did I really start working on that thing in 2005? No wonder I can hardly make sense of it (just kidding, honestly…).

Joking aside, the only thing I know for sure about the functional difference between NSQ and Resolver is the lack of hostent support. NSQ was geared towards Block Lists. I wouldn’t be surprised if it was missing other general functionality as well. Doesn’t Resolver also provide a DNS server? Or was that one of the other – older – resolver modules?

Does a *RESOLVERCONFIG rather than an RMReinit similarly help?

Makes no difference. In place of RMReinit – mail, usenet and time fail to resolve. Added after RMReinit it’s the same as without it – mail & news are fetched, time fails.

They’ll get another kind of nightmare when they realise what an awfull programmer I am… :-)

Better than a closed, locked down, legally tied up resolver.

I just looked at my project directory for NSQ. Good grief! Did I really start working on that thing in 2005?

Sounds likely, I thought it was a bit earlier – but I could rummage through old archives for my test program which would timestamp it nicely.
Went rather quiet in the RO scene for quite a while.

Does a *RESOLVERCONFIG rather than an RMReinit similarly help?

Makes no difference. In place of RMReinit – mail, usenet and time fail to resolve. Added after RMReinit it’s the same as without it – mail & news are fetched, time fails

I’ve borrowed the (bounty funded) ROOL developer BBxM and quickly grabbed the 02-Jun-13 OMAP3 ROM (same 5.21 as you’re using).

With static IP address it boots fine and I can ping google.co.uk no problem, having set the primary and secondary resolvers in the network setup dialogue.

With DHCP enabled it boots, but reports that “file already exists” creating route on entering the desktop, and name resolution doesn’t work. So I cleared the route from the network setup dialogue.

After rebooting (DHCP + 5.21 02-Jun-13) no errors, and I can ping google.co.uk no problem, and for good measure I enabled automatic time sync in the time & date setup. Typing

*NetTime_Status

So, I’m afraid for notionally the same setup it works fine here. Perhaps you could do a

*SHOW Inet*

Perhaps you could do a SHOW Inet to see in both the failing and working case to see if anyone here can spot anything amiss.

First the working case ROS 5.19;

show inet
Inet$BootFile :
Inet$BootServer : 0.0.0.0
Inet$EtherDevice : EtherUSB
Inet$EtherIPAddr : 192.168.1.66
Inet$EtherIPMask : 255.255.255.0
Inet$EtherType : ej0
Inet$Gateway : 192.168.1.254
Inet$HostName : Beagle
Inet$IsGateway :
Inet$LocalDomain : lan
Inet$MimeMappings : InetDBase:MimeMap
Inet$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.
Inet$ResolverDelay : 5
Inet$ResolverRetries : 3
Inet$Resolvers : 192.168.1.254
Inet$RouteDOptions :
Inet$Started : Yes
Inet$Startup : Choices:Internet.Startup
InetDBase$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.files.
InetSetup$Dir : SCSI::HardDisc4.$.PlingBOOT.Resources.Configure.!InetSetup
*

Then the failing case before Reinit Resolver (5.21);

Show Inet
Inet$BootFile :
Inet$BootServer : 0.0.0.0
Inet$EtherDevice : EtherUSB
Inet$EtherIPAddr : 192.168.1.66
Inet$EtherIPMask : 255.255.255.0
Inet$EtherType : ej0
Inet$Gateway : 192.168.1.254
Inet$HostName : Beagle
Inet$IsGateway :
Inet$LocalAddr : 400b6a0a
Inet$LocalDomain : lan
Inet$MimeMappings : InetDBase:MimeMap
Inet$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.
Inet$ResolverDelay : 5
Inet$ResolverRetries : 3
Inet$Resolvers : 192.168.1.254
Inet$RouteDOptions :
Inet$Started : Yes
Inet$Startup : Choices:Internet.Startup
InetDBase$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.files.
InetSetup$Dir : SCSI::HardDisc4.$.PlingBOOT.Resources.Configure.!InetSetup
*

… and failing after ReInit (5.21);

show inet
Inet$BootFile :
Inet$BootServer : 0.0.0.0
Inet$EtherDevice : EtherUSB
Inet$EtherIPAddr : 192.168.1.66
Inet$EtherIPMask : 255.255.255.0
Inet$EtherType : ej0
Inet$Gateway : 192.168.1.254
Inet$HostName : Beagle
Inet$IsGateway :
Inet$LocalAddr : 400b6a0a
Inet$LocalDomain : lan
Inet$MimeMappings : InetDBase:MimeMap
Inet$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.
Inet$ResolverDelay : 5
Inet$ResolverRetries : 3
Inet$Resolvers : 192.168.1.254
Inet$RouteDOptions :
Inet$Started : Yes
Inet$Startup : Choices:Internet.Startup
InetDBase$Path : SCSI::HardDisc4.$.PlingBOOT.Resources.!Internet.files.
InetSetup$Dir : SCSI::HardDisc4.$.PlingBOOT.Resources.Configure.!InetSetup
*

The only difference that I see is that the fail outputs has the extra line ‘Inet$LocalAddr’. The content of this post was transferred from the BB -xm to my Mac for sending after the ReInit so FTPc also works. It’s just time fetching that doesn’t.

That Inet$LocalAddr entry shows a local address of 10.106.11.64. No wonder it doesn’t work – but where does that address come from?