ShareFS issue between pi3 and pi4

I have a collection of rPis which all need the same software configuration. To make this happen I use cloning, via Win32diskimager. As they will need to work in a local network without a router, the network setup is a little unusual – this might be relevant. The hosts file is populated with all the host/ip mappings. The network name is set to “from hosts file”.

The boot disc is set (via a small piece of BASIC) to share as

<hostname>_disc

This all worked well until I added a pi4 to the mix.

I created a new image from the Stable 5.28 download, since the older image I had used wouldn’t work on a pi4.

I booted this image on the pi4, and configured the network. ShareFS was working correctly, seeing other shares, and its shares becoming visible.

I saved a copy of this configured image. Then I transferred the same sd card to a pi3.

The network failed to start. To get it working I had to go to configure, network, interface and select the different interface shown on this hardware. Then I had to select “from hostname” and type in the network mask since the “default” option didn’t appear.

After rebooting there were no error messages. However ShareFS only showed its own shares, and its shares were not visible elsewhere.

I could not get ShareFS working correctly. *FWshow only showed the local machine.

I tried this whole scenario using the beta 5.29 image from 9-Jan. Exactly the same thing happened.

I now transferred the sd card back to the RPI4. Again I had to reconfigure the interface, and add the netmask. Again ShareFS failed to operate outside the local machine. The only way to fix this sd card was to put a new image on it.

Although ShareFS isn’t working, everything else over the network works. I can control the machine using Avalanche and VNCserver, and I can access the Internet.

It seems to me that there is an issue in the network config. As far as I know ShareFS is the only thing needing broadcasts, and the failure of the config to offer the default netmask, might indicate that the netmask isn’t actually being set correctly, or else that ShareFS is using a stale version.

The network failed to start. To get it working I had to go to configure, network, interface and select the different interface shown on this hardware. Then I had to select “from hostname” and type in the network mask since the “default” option didn’t appear.

From hostname doesn’t automatically imply default netmask, hence it’s not populated with that unless you type it yourself (in contrast to BOOTP and DHCP).

Most likely your issue here is that if you set up the interface on a Pi 4 you’d be using EtherGENET, but then if you put the same card into a Pi 3 that interface isn’t there. The code (in InetSetup) which parses the network settings in order to populate the dialogue boxes checks, for each command in !Boot.Choices.Internet.Startup, whether the interface in its list of known interfaces and skips if it’s not there.

The magic which picks EtherGENET or EtherUSB depending on the model of Pi runs once only when the SD card is newly imaged. Running Utilities.Caution.!ResetBoot will cause it to run again on next restart.

From hostname doesn’t automatically imply default netmask, hence it’s not populated with that unless you type it yourself (in contrast to BOOTP and DHCP).

However when the re-imaged card first starts it is populated with “Default” – the word, not the value.

Running Utilities.Caution.!ResetBoot will cause it to run again on next restart.

Thanks, I’ll try that. Otherwise I’m going to have to maintain two master images – one for pi4, and one for all the others.

Thinks… A little bit of BASIC that checks whether the network has started, then run resetboot if not, and triggers a reset. Maybe look for ShareFS, which won’t be running. Or try ping, and check for errors. Care needed – it could get into a continuous loop of resets.

[edit] so a simple test is *fwshow, which returns an error after the card is switched, but not once the interface has been configured.

However I’m now thinking that I could save boot.choices.internet.startup from each configuration, and simply switch in the appropriate one after booting, then reset.

Could be some interesting playing around to do here.

From hostname doesn’t automatically imply default netmask,

Define “default” netmask in a CIDR world.

!ResetBoot looks rather a sledgehammer – would just deleting Choices.Internet have the desired effect?
Or even populating Choices.Internet.Startup with a Pi3 version or a Pi4 version? (assuming they are the same for all the OPs Pis and Pi4s).

Define “default” netmask in a CIDR world.

Indeed. However that’s what the initial configuration sets in the GUI tool. Inet$EtherIPMask = Default too.

Ifconfig shows it as 0xffffff00 i.e. 255.255.255.0

Or even populating Choices.Internet.Startup with a Pi3 version or a Pi4 version? (assuming they are the same for all the OPs Pis and Pi4s).

My thought too. The aim is that as I bring up each new cloned disc, I go into configure, network, host names, and set the name. Then exit and reset. Everything else works from there. This does work on the pi 1,2 and 3s.

Before saving a new master image, I set the name to something I will not use on a live network. That way the first boot won’t clash with an existing computer.

I started to say this didn’t work, then checked again.

What caught me out is that resetboot creates a ~Choices directory alongside Choices, and I switched files into the wrong one. That ~ isn’t very visible, unless you’re expecting it, which after looking into what resetboot does, I was aware of.

Switching the files does work.

So the steps I used in testing were:

Boot the card. Configure the network, reboot
Copy the choices.internet.startup file to somewhere outside !boot, and rename it to show which rpi type it is from.
Swap the card into the other type of rpi
Boot, cancel the error message.
Run resetboot and reset
Configure the network, then reset
Copy this choices.internet.startup and rename it.

Now when switching the card, simply cancel any error messages and copy the appropriate startup file into choices.internet and reset.

To automate this, I will need to detect that the network hasn’t started (use freeway calls and look for error), then identify the type of rpi we are running on (how? – RMEnsure EtherUSB and RMEnsure EtherGENET), and switch the appropriate file into Choices and reset. This will only happen once for each card made from the master image, or if a card if moved between pi types.

The only manual step left is the one I already use, of changing the host name.

!ResetBoot looks rather a sledgehammer

…and yet it’s the correct thing to do, supported by the OS, and solves the problem in the original question. If Alan’s putting together a master image (to clone between several other Pis) then any customisations should live in the respective RO52xHook. Then, when swapping between machines, you run !ResetBoot and everything works.

The alternative would be I explain which specific run-once file is the one that selects between interfaces, except then the answer trapped in the forum history is specific to a Pi and only for the current range of hardware. Why not pick a solution which works in the general case though?

would just deleting Choices.Internet have the desired effect?

No, because then there’s no networking setup at all! That’s not the desired outcome I suspect, whereas my proposal of using !ResetBoot leaves you with networking set up and the correct interface selected. An extra level of finesse would be to set the hostname to a semi-random string to ensure there are no duplicates in the DHCP tables – left as an exercise for the reader.

left as an exercise for the reader

I’ve spent over 50 years interpreting that phrase as “I could say/write something, but without thorough checks I’m not sure it would be right” – when I was charitable about the author :)

In this instance, I’d suggest the technique of set a hostname based on the MAC like so many instances that aren’t Microsoft tend to do. Setting the hostname manually would ideally override this.

Out of interest, does anyone know what happens when the device (Pi or other) has two network interfaces that are both active?

So there are two alternatives suggested.

Using resetboot results in each clone needing a list of settings to be made manually – unless there’s an SWI interface to do it.
Interface selected, set to “from hostname”, then in routing, add the router address, then in host names, set the host name and “use resolver”.

Using the swap files technique merely requires setting the hostname to its correct value. However automating the swap is proving tricky. I have several ways to detect if the network is running, the simplest of which is to see whether Inet$LocalAddr exists. If not, then I need to swap. The question then is which file to substitute?

I can look at Inet$EtherDevice, which will be set to the wrong one, and pick the other file. This works while there are only 2 options – rpi 1 to 3 or rpi4. (EtherUSB or EtherGENET)

Ideally there would be a way to find out what the hardware present actually is, but I haven’t yet found a way to do that, or at least without dropping into assembler and using HAL calls. Any thoughts?

And I ought to repeat these tests using the ROD stack before writing any more code.

Incidentally this thread should ideally be in Community Support, but I don’t think there’s a way to move it. I thought initially I had encountered a bug in shareFS, but I think it was because, in a moment of brain-fade, I had been setting the netmask to 192.168.0.0 instead of 255.255.255.0