New Boot sequence , Iyonix and RISC OS 5.18 network issues

Hi

I updated to the latest ROOL hard disc image and 5.19 development softload on my Iyonix but now find that if I revert back to 5.18 then I lose networking.

I have tried a full clean Boot sequence , without softload, and that also results in the same problem.

Ping gave:
*ping 192.168.1.254
PING 192.168.1.254 (192.168.1.254): 56 data bytes
ping: sendto: No route to host

And ifconfig -a:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ek0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 1.107.17.232 netmask 0xff000000 broadcast 1.255.255.255
ether 00:09:95:00:11:e8

I also noticed that the usual wait for interaction between the Iyonix and DHCP server was not seen on booting up.

I then went in Boot>Configure>Network>Internet>Interfaces and changed “Obtain IP Address” from DHCP to from hostname. I set up the hosts file and then rebooted and my network came back on.

I also notice that running *Status on 5.19 gives FreeWayAutoAddress as On but on 5.18 this configuration is missing.

As the Boot image is supposed to be universal then this issue that needs addressing as anyone updating and still wishing to softload 5.18 will loose networking or need to alter their network setup.

If anymore information is required then let me know.

Doug

If you update your disc image to the current work-in-progress and the ROM likewise, are you saying it works fine? If you revert one and not the other, you’re clearly asking for trouble…

If you revert one and not the other, you’re clearly asking for trouble

In this instance
New disc image + older ROM should work fine.
Old disc image + new ROM, er, very doubtful.

My (completely unvalidated) hunch would be that the module order has changed and the DHCP module is accidentally unplugged. The 1.107.17.232 address looks very much like a Freeway auto assigned network.

The disc image is being actively tested back to RISC OS 3.50 (on actual hardware) though 3.10 support is currently disabled.

OK for clarity:

Iyonix hardware.

Clean ROOL HardDisc image and !Boot sequence and 5.18 in the Iyonix flash- If network is set for DHCP then on reboot it fails to wait for the server to give a IP address and boots straight through to the desktop with warnings.

*unplug shows no modules unplugged
1.107.xxx address
No networking/Internet access

Change networking to Obtain from host and reboot and I have networking and internet.

Merge 5.19 softload in to previous clean !Boot, Network set to DHCP and Reboot and it waits for the server to give an address and in to the desktop with no issues.

So New clean disc image and no softload merged in + 5.18 rom, DHCP gives no networking but Obtain from host gives networking

New disc image + 5.19 softload DHCP works fine.

Hope this clarifies things.

I have run !Reporter and it gives the following clue:

[SharedCLibrary/] Obey ADFS::Iyonix.$.!BOOT.Resources.!Internet.!Run 
Module is not in ROM
Module is not in ROM
Module is not in ROM
[SharedCLibrary/] Obey ADFS::Iyonix.$.!BOOT.Choices.Internet.Startup 
Syntax: *DHCPExecute [-e] [-block] [-w] 
Syntax: *DHCPExecute [-e] [-block] [-w] 
Syntax: *DHCPExecute [-e] [-block] [-w] 
Syntax: *DHCPExecute [-e] [-block] [-w] 
Syntax: *DHCPExecute [-e] [-block] [-w] 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
Syntax:[09]*IfThere  then  else 
08:04:43.18 ** Error **
  Error  : &000000DC
  Message: Syntax:[09]*IfThere  then  else 
[Appl/] Obey ADFS::Iyonix.$.!BOOT.Choices.Boot.PreDesk.Configure.!Run 
[20163C78/] Obey ADFS::Iyonix.$.!BOOT.Choices.Boot.PreDesk.Configure.Monitor

This is with clean 13thSept12 HardDisc image, aprt from !Confix and !Reporter added.

Also with 5.18 ROM no FreeWayAutoAddress seen using *Status but it is there if 5.19 is softloaded. Again to repeat *Unplug gives no modules unplugged.

Doug,
Yes – my conclusion was that someone’s changed !InetSetup to output non backwards compatible DHCPExecute commands despite my warning

Can you post the line from Choices:Boot.Internet.Startup please?
Alternatively, take a new disc image, replace !InetSetup (in BootResources:Configure) with the one from your old disc image, and check that works with both 5.18 and 5.19.

Thanks Rob for the pointer.

The offending command in Internet.Startup is:

DHCPExecute -e -b -w -p ek0

Deleteing the -p switch, which was added with DHCP 0.23 module?, allows a new ROOL boot sequence to work with DHCP and RISC OS 5.18.

So either the required supported version of the DHCP module needs to be in the !Boot sequence or a check made that the -p switch is supported somewhere.

or a check made that the -p switch is supported somewhere

Thanks for the confirmation – I think !InetSetup needs to be a little more careful. I’ll take a look at the options and see what’s the simplest way to support both situations.

Using downloads made today of Pi ROMS & Hard Drive Image
Choices.Internet.StartUp was a file typed TEXT this also happened mid last week!
Changed to obey and networking was fine!

Chris

It would be fine as the issue is using latest Hard Disc/Boot with 5.18 ROMs.

The issue is a change made to the DCHP module post 5.18 release.

i.e 5.18 includes DHCP module 0.21 that does not like the latest -p option set up with DHCPExecute via the newer ROOL !Boot sequence. 0.23 version of the module thats in 5.19 development ROMs including the Pi is OK with using that option.

Your issue is entirely seperate but one that does need to be addressed.

Oops yes Doug wrong thread. I was in a bit of a rush when I posted. More speed less haste!

Choices.Internet.StartUp was a file typed TEXT this also happened mid last week!

We think we know why this might be happening – let’s just say it’s “complicated”. But it does absolutely need sorting before the Big Release™.

We think we know why this might be happening – let’s just say it’s “complicated”.

The cause seems pretty simple to me – SDCMOS was corrupting R7, which InetSetup was using to store a pointer to an important flag.

Of course it was probably only this easy for me to track down because I was running with high processor vectors, so the corruption resulted in a crash rather than a silent failure of some code in InetSetup.

On my BB I upgraded both the ROM (v5.19 13/9/12) and “HardDisc4” on 15/09/12 and have had problems on booting. I often get the Supervisor prompt. The Startup file in !Boot.Choices.Internet has a line about loading the DHCP module, but HardDisc4 doesn’t contain the DHCP module. Since I have configured BB to use DHCP, this might matter? Could it be affecting the booting?
I notice that this HardDisc4 is missing many files that I would expect it to contain, e.g., IConv, AcornURI, SharedULib, Tinct all of which are needed by Netsurf. But what other modern browser do we use on BB apart from Netsurf?
It seems that this !Boot directory is a minimalist one.

I notice that this HardDisc4 is missing many files that I would expect it to contain, e.g., IConv, AcornURI, SharedULib, Tinct all of which are needed by Netsurf. But what other modern browser do we use on BB apart from Netsurf?
It seems that this !Boot directory is a minimalist one.

Most of those are third party developments and Tinct isn’t usable on modern (as in OMAP) processor revisions.

Admittedly the OS needs a ready, sitting in the base build, browser even if the load is actually a click on this to download the package.

The Startup file in !Boot.Choices.Internet has a line about loading the DHCP module, but HardDisc4 doesn’t contain the DHCP module

For a BBxM that shouldn’t matter since the module is in ROM.
Can you tell me what the DHCP RMEnsure line in Choices:Internet.Startup says? I hope 0.15.
Might also be worth typing *UNPLUG to check it’s not unplugged if you’ve previously not been using it.

I notice that this HardDisc4 is missing many files […] needed by Netsurf. It seems that this !Boot directory is a minimalist one.

The HardDisc4 is all you need for a working system and should be entirely self consistent (ie. all the apps on it should have everything they need to run). However, it’s not intended to include every app you might want since these are supplied by 3rd parties – you’ll need to install those yourself.

Alternatively, RComp offer a support scheme with more complete software bundles and support.

Can you tell me what the DHCP RMEnsure line in Choices:Internet.Startup says? I hope 0.15.
Might also be worth typing *UNPLUG to check it’s not unplugged if you’ve previously not been using it

The line says “RMEnsure DHCP 0.11 RMLoad System:Modules.Network.DHCP”
*UNPLUG gives “No modules are unplugged”
You say

However, it’s not intended to include every app you might want since these are supplied by 3rd parties

but I thought SharedULib was needed for many applications.

I upgraded both the ROM (v5.19 13/9/12) and “HardDisc4” on 15/09/12

The line says “RMEnsure DHCP 0.11 RMLoad System:Modules.Network.DHCP”

Ah right, I think you’re suffering from a bug in !InetSetup that I fixed on the 15th, so that wont have appeared until the download of the morning of the 16th, could you try updating again?

I thought SharedULib was needed for many applications

But not for any in the HardDisc4 download. Again, you should consider it as a foundation on which to build, not a ready furnished house.

The cause seems pretty simple to me – SDCMOS was corrupting R7, which InetSetup was using to store a pointer to an important flag.

Top marks to Jeffrey for finding and fixing that bug. It’s not the cause we suspected – that’s actually something else that still needs investigating…

I have updated to the new “HardDisc4” today, but this won’t help with the Supervisor prompt problem where the USB stick isn’t even looked at.

The probelm with the minimalist !Boot in “HardDisc4” is that if I just copy accross all the missing files from the old !Boot, how do I know they are compatible with the new !Boot or the new ROM? As an example, there are 61 files in my old System.310 directory, but only 10 in the same directory from ROOL. Before you say otherwise, I try to keep my !Boot as small as possible and only stick stuff in when the programmers advise this. E.g., I have Iconv, SharedULib, Tinct, URI, EtherUSB in the Network subdirectory whereas the ROOL minimalist one doesn’t even have a Network subdirectory! How many users are not connected to a network? And what about DRenderer needed for Artworks Viewer?
I also have the Toolbox subdirectory in !System.310, aren’t these still needed?

David, I think you are confusing what is needed by RISC OS to get up and running with what is needed by any additional 3rd party applications.

The way to sort this out is via a package manager that adds and manages things on your behalf or if you don’t want that you could wait for a ROOL commercial distro package, invest in RComp’s Beagleboard scheme that adds things in for you or manage things yourself.

In my experience even ROL had issues where Select updates had to be manually tweaked after an upgrade.

Personally having set up my Beagleboard from scratch rather than using what was in either my Iyonix or Kinetic !Boot has enabled me to clear out a lot of deadwood modules that I had accumulated over the years and to ensure I had the latest compatible versions that were ARM7 safe.

The probelm with the minimalist !Boot in “HardDisc4” is that if I just copy accross all the missing files from the old !Boot, how do I know they are compatible with the new !Boot or the new ROM?

Sounds like you’re already happy brewing frankenstein boot sequences so I’m not sure I can offer much more insight. I’ll repeat (again) that the Harddisc4 image is self consistent and contains all the modules and resources needed for the apps on it that ROOL are licenced to distribute.

• Iconv – not required by any components in the download
• SharedULib – not required by any components in the download
• Tinct – not required by any components in the download
• URI – not required by any components in the download
• EtherUSB – hmm, that’s been in ROM since May, but then you said you’re using 15-Sep-2012 of 5.19? I’m further confused
• DRenderer – not required by any components in the download
• Toolbox – these are in ROM

To work with RISC OS 3, you also need to download the “System resources” ZIP file and merge those with !System, this is because a subset of modules must be 26 bit.

Toolbox – these are in ROM

Unfortunately most users are going to be victims of the apps out there that demand the ROL toolbox by requiring a later version number for Toolbox than the version in ROM.
I haven’t tested any with a tweaked Run file to see if they actaully require features in that version or just bitch about the version number not being high enough.
Should be interesting testing…

Unfortunately most users are going to be victims of the apps out there that demand the ROL toolbox by requiring a later version number for Toolbox than the version in ROM.

I don’t think there are that many applications in this situation. I don’t have the ROL toolbox modules on either the Iyonix or the Beagleboard and I’ve rarely hit problems.

And what can we do about it anyway, other than fix the applications or artificially increase the ROOL toolbox module version numbers? Even if ROOL could get permission to distribute the ROL toolbox modules, you would not want to base a distribution on closed-source content.

I don’t think there are that many applications in this situation. I don’t have the ROL toolbox modules on either the Iyonix or the Beagleboard and I’ve rarely hit problems.

That may be true, simply because there haven’t been many new applications while the ROL stream toolbox has been around and many apps don’t use those kind of features anyway as the authors didn’t want to limit their market.

Sadly there seem to be a lot of utilities that used the toolbox, and insist on the latest version in their startup.
Quite apart from the likes of Blackhole2, as an example, not having a 32bit module available on the web it uses the Toolbox too.