RepRapFirmware 3.01-RC6 released

chas2706

@bearer said in RepRapFirmware 3.01-RC6 released:

edit: NOPE, that was not a good idea.
maybe this works better, specifying all the packages to fulfill dependencies for duetsoftwareframework=1.2.5.0

Thanks for the suggestion but here's what I got:

pi@Duet3:~ $ sudo apt install duetcontrolserver=1.2.5.0 duetsd=1.0.5 duettools=1.2.5.0 duetwebserver=1.2.3.1 duetwebcontrol=2.0.7-1 reprapfirmware=1.2.5.0-1 duetruntime=1.2.5.0 duetsoftwareframework=1.2.5.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '1.2.5.0' for 'duetcontrolserver' was not found
E: Version '1.2.5.0' for 'duettools' was not found
E: Version '1.2.3.1' for 'duetwebserver' was not found
E: Version '2.0.7-1' for 'duetwebcontrol' was not found
E: Version '1.2.5.0-1' for 'reprapfirmware' was not found
E: Version '1.2.5.0' for 'duetruntime' was not found
E: Version '1.2.5.0' for 'duetsoftwareframework' was not found
pi@Duet3:~ $

For me there are a number of issues.
After you have installed a beta version and run into difficulties, re-installing a back up can create a number of issues.
Firstly you don't know which specific version of RRF your back up was on unless you were smart enough to include the version number in the backup name (all versions are named " Duet3Firmware_MB6HC.bin")!. So by default your back up will fail because your board is flashed with the latest version.
Secondly, your version of DWC will be the wrong version and for SBC users apparently, this is just tough luck.
Summing it up, a backup will only work if you never upgraded in the first place!

Danal

When running a Pi, there is more to a backup than the binary file loaded into the Duet board (and/or the contents of sys and macros). A lot more.

A backup of the entire SD in the Pi will always work to execute a recovery. After booting from such a full SD card backup, it is necessary to load firmware into the board. That backup of the entire SD card, by definition, has the firmware .bin files that were loaded sometime in the past. No name problems, no downloads, "just works". If the backup is of the entire card.

Maybe this should all be on a dozuki somewhere... and I'd be happy to write it up.

(P.S. For anybody that doesn't know, I have no association with Duet the company. I am just a vocal user)

chas2706

@Danal said in RepRapFirmware 3.01-RC6 released:

When running a Pi, there is more to a backup than the binary file loaded into the Duet board (and/or the contents of sys and macros). A lot more.
A backup of the entire SD in the Pi will always work to execute a recovery. After booting from such a full SD card backup, it is necessary to load firmware into the board. That backup of the entire SD card, by definition, has the firmware .bin files that were loaded sometime in the past. No name problems, no downloads, "just works". If the backup is of the entire card.
Maybe this should all be on a dozuki somewhere... and I'd be happy to write it up.
(P.S. For anybody that doesn't know, I have no association with Duet the company. I am just a vocal user)

The backup was of the entire card and I initially realised that there were problems because the firmware on the board was of the new build so I grabbed a copy of Duet3Firmware_MB6HC.bin found in /opt/dsf/sd/sys i.e "Duet3Firmware_MB6HC.bin" and flashed it to the board but still have the above mentioned issues.

chas2706

If a full backup of the entire SD "always works" how come the DWC does not downgrade to the correct version?

Danal

Also, if you want to backup the entire Pi SD card to a windows PC without physically touching the card in the Duet+Pi, here is an outline of how to do that:

One time installation tasks:

#At your windows machine, create a shared drive to receive the backups. Allow user 'guest' read/write access (assuming your home network is physically secure, or you are otherwise comfortable with this)

#On the Pi
sudo apt-get install pv
git clone https://github.com/lzkelley/bkup_rpimage.git

#Edit file /etc/fstab, add a line at the end:
//windows-machine-name/shared-drive-name /linux-mount-point cifs user=pi,password=raspberry 0 0
mkidir a directory that matches the mount point above

Each Time, to run a backup:

sudo mount linux-mount-point
sudo sh ./bkup_rpimage/bkup_rpimage.sh start -cz /linux-mount-point/$(uname -n).img

NOTE: The running backup WILL disrupt a running print, do not backup while doing anything else.

In a recovery situation, the file deposited on the shared drive is used as an input to balena etcher (or other similar tools) to make a recovery SD for the Pi.

Danal

@chas2706 said in RepRapFirmware 3.01-RC6 released:

If a full backup of the entire SD "always works" how come the DWC does not downgrade to the correct version?

If you put a physically different SD card, that was copied before any upgrades, if you put that card in the Pi and boot, then every file on that card will be at the version it was the moment that backup was taken. Including DWC.

A Former User

@chas2706 said in RepRapFirmware 3.01-RC6 released:

Thanks for the suggestion but here's what I got:

huh, thats odd; you'd have to have the unstabe list to do the upgrade so the old versions should still be on the list; i did try it just before.

if you accept flashing the duet 3 using usb+bossa then backing up the sd card will work as the matching firmware file should be in /opt/dsf/sd/sys

if you hook the duet to the pi with usb this would flash that firmware to the duet without worrying about iap files or anything.

wget https://pastebin.com/raw/Wa1kYf3G -O - | tr -d "\r" | bash

and if dcs happened to be working echo M997 S0| sudo /opt/dsf/bin/CodeConsole should achieve the same without having to deal with usb.

Danal

This post is deleted!

chas2706

@Danal said in RepRapFirmware 3.01-RC6 released:

Also, if you want to backup the entire Pi SD card to a windows PC without physically touching the card in the Duet+Pi, here is an outline of how to do that

I made the back up by taking out the sd card, inserting it in my pc and then using win32disk manager and I can verify that it works because while I was on the same RRF version I deliberately flashed a different sd card and re-installed using my backup. In the process I made lots of changes, backed them up and re- installed - all with success but when you "upgrade" the result is so different

Danal

@chas2706 said in RepRapFirmware 3.01-RC6 released:

I made the back up by taking out the sd card, inserting it in my pc and then using win32disk manager and I can verify that it works because while I was on the same RRF version I deliberately flashed a different sd card and re-installed using my backup. In the process I made lots of changes, backed them up and re- installed - all with success but when you "upgrade" the result is so different

The Duet board has flash that has the running firmware. It absolutely does have to be re-flashed to change the firmware release.

EVERYTHING else is on the SD card. That is the physical setup of a Raspberry Pi. I don't doubt what you are seeing, your symptoms. At the same time, if a backup SD card was taken before the upgrade, and that backup was properly restored (such as a physically different card with the prior copy being put in the Pi), then it is absolutely not possible that the files are somehow at a different level than the backup. Pi hardware does not have any other storage than the SD.

So again, I'm just a fellow user, trying to help improve understanding so that people don't get painted into corners... if DWC didn't regress to the level it was when the backup was taken, the the backup/restore procedure is the thing to fix for next time.

Danal

Wait a minute... "Win32 disk manager"??? That won't deal with the Unix partitions on that card. Will it?

A Former User

This ought be a passing problem for most people as a stable release becomes available that most people can actually use without being recommended to switch to the unstable list where stuff like this so to some degree is acceptable.

And for now; we can try to make the best of it.

A Former User

@Danal said in RepRapFirmware 3.01-RC6 released:

Wait a minute... "Win32 disk manager"??? That won't deal with the Unix partitions on that card. Will it?

indirectly; as in it'll do a bit for bit copy that will work unless you want to restore to a smaller sd card

(not sure if it applies to SD cards as it did with old harddrives, but I always leave a few megabytes unused to allow for X gigabyte from vendor A not being the same as X gigabyte from vendor B)

Danal

Are we talking about this:

A Former User

@Danal yaeh - dd for windows basically

Danal

Win32 disk imager has been known to copy portions of a card, and not copy other portions, in certain SD readers. Which makes it very difficult for other people to diagnose.

Personally, I would never use it. Balena etcher or SD Writer or...

Probably not what happened here; but something did happen to that backup. Some confusion.

chas2706

@Danal said in RepRapFirmware 3.01-RC6 released:

o again, I'm just a fellow user, trying to help improve understanding so that people don't get painted into corners... if DWC didn't regress to the level it was when the backup was taken, the the backup/restore procedure is the thing to fix for next time.

Thanks for your help danal. I really appreciate your input.
I am just so frustrated with the problems I am experiencing.

@Danal
Wait a minute... "Win32 disk manager"??? That won't deal with the Unix partitions on that card. Will it?

I am no Linux expert but I can confirm that win32 disk manager deals with the unix partitions because I have used it for many years on my rpi projects.
It was available for the rpi way before etcher or raspberry pi imager.

Danal

@chas2706 said in RepRapFirmware 3.01-RC6 released:

@Danal said in RepRapFirmware 3.01-RC6 released:

o again, I'm just a fellow user, trying to help improve understanding so that people don't get painted into corners... if DWC didn't regress to the level it was when the backup was taken, the the backup/restore procedure is the thing to fix for next time.

Thanks for your help danal. I really appreciate your input.
I am just so frustrated with the problems I am experiencing.

@Danal
Wait a minute... "Win32 disk manager"??? That won't deal with the Unix partitions on that card. Will it?

I am no Linux expert but I can confirm that win32 disk manager deals with the unix partitions because I have used it for many years on my rpi projects.
It was available for the rpi way before etcher or raspberry pi imager.

Yeah, I think we both mean "win32diskimager". That does work on complete SD cards. Although I have read where it can skip certain parts of cards on certain drives. Probably not what happened here.

And, yes, I understand the frustration. I was up until 2:30 last night doing a "five minute install" of LaTEX on an unrelated system... and had calls starting at 7 AM. I really should have walked away about 11 PM, but you get that "one more command and it has GOT to work" syndrome.

chas2706

@Danal said in RepRapFirmware 3.01-RC6 released:

Yeah, I think we both mean "win32diskimager

Sorry yes. My mistake!
Looks like I will just have to spend hours setting up my config again from scratch.
A lessen learnt - don't download from the "unstable list".
Again, thanks for you help.

A Former User

@chas2706 said in RepRapFirmware 3.01-RC6 released:

A lessen learnt - don't download from the "unstable list".

hopefully when 3.01 hits stable, there won't be a a reason to do so (which didn't quite hold true for 3.0)