It should be possible to change the WiFi network without having to register and setup everything again.
You don’t have to do that. Currently you have to shut down the Pi, remove the SD and edit the existing file config/wireless. After saving, put the SD back in and start. Your Pi will try the new WiFi settings. See here for a description of that file: https://info-beamer.com/doc/device-configuration#wificonfiguration
In the next OS version this will be a lot easier as you can edit this kind of setting directly on the device page itself. If you want to try this out, follow this guide: Trying out the next info-beamer OS version before release
After switching to the ‘testing’ version of the OS, just reload the device page, go to the Device configuration section and click on Edit…. Then select the Networking tab, edit the configuration and click on Apply configuration and reboot device:
Let me know if that helps.
The “problem” is that when I change the file: config/wireless with the new information and restarts the RPi with this, it boots and are showing a new ID, and waiting for me to register it. I then have to delete the “old” devices.
I just tried that with two devices.
That should never happen unless something odd is happening as a side effect of editing the wireless file. A device is only newly initialized if either the number of partitions is unexpected or a signature on the third partition changed or is not valid for some reason. This should not happen by just editing a single file.
When the device reboots after you edit the file, can you check the very first line? It should say something like this:
[*] Starting stable:<some-number>:stable-0009 (XXXXXXX)
What’s the value of XXXXX?
Later is the device reinitializes, there will be a line like this:
[*] Initializing persistent filesystem (YYYYY)
What’s the value of YYYYYY?
Which Operating system/editor are you using to make the changes to config/wireless?
Hm. Another reason might be that you switch SD cards between devices. The registration is bound to the serial number of the Pi, so if you put the SD card into a different Pi after editing the config file, you’ll have to reregister. This is also required if you just move an SD card from one Pi to another without editing anything. Maybe that’s the reason?
If it’s the same Pi, something strange is going on and we should definitely investigate further.
I might have switched the card at boot, but have tried to switch again after initial boot.
I’m using Windows 10 with “Sublime Text” as editor (Unix-like)
What I noticed when booting for the first time after the change, was that “Checking Filesystem” did not report “OK”
All very very strange. This would indicate that the data partition ended up in an unexpected state. The partition layout is like this:
/dev/mmcblk0p1 2048 200000 197953 96.6M b Win95 FAT32
/dev/mmcblk0p2 202048 400000 197953 96.6M 83 Linux
/dev/mmcblk0p3 400001 15564799 15164799 7404M 83 Linux
So the first partition is marked as FAT32 and is the partition the Pi boots from. The second partition is a spare partition for A/B booting and isn’t used except during system upgrades. See also [1] for some additional notes.
Finally the third partition is where the devices stores its dynamic data, like log files, downloaded code/assets and so on. During bootup, the OS will run a fsck on the third partition. It this works out ok, it will continue booting. If not, the partition will be reformatted and everything will be completely restored by downloading all assigned assets again.
If there is no ok after the Checking filesystem.. line, this means that e2fsck doesn’t return. Does the device just get stuck there forever? If there is no further console output at all, I’m very confused because that would mean that there is no low level hardware problem (as those tend to flood the console with SD card related error messages) and instead the ext4 partition is in a state that results in some kind of endless loop in e2fsck. Weird. I guess this only happened when you started editing the config file on a completely unrelated FAT32 partition?
[1] The second partition is either empty or also contains a FAT32 FS, but is marked as Linux, as it shouldn’t be visible on a Windows/OSX machine. Unfortunately they detect it as FAT32 regardless. In the future, this partition will most likely be marked as empty instead.
Both RPi did boot fine after a few seconds and now the file systems checks out OK on every boot. It’s just strange that it changed the ID on first boot after the config change. I think that this was caused by the reformatting of partition 3 on boot.
I have 5 more devices to perform the same action on, so I’ll see what happens 
Even if the 3rd partition is reformatted, this doesn’t remove the unique device UUID that is initially set when first formatting the 3rd partition for the first time. As the UUID stays the same, the device shouldn’t need to be reregistered. The only intended code path where the UUID is updated and therefore a new registration is required is:
- The hardware serial changed, so the SD card moved to another Pi
- The partition is explicitly marked as to-be-set-up. This happens if…
- no 3rd partition doesn’t exist as happens for example during initial setup on a blank FAT32 SD card
- the 3rd partition hasn’t been touched by info-beamer before. For example when you replace the boot files from an existing Raspbian with 3 partitions.
- if you explicitly delete a devices from the system using either the Manage > Delete button or the API.
1 Like