RepRapFirmware 3.01-RC6 released

ChrisP

@chas2706
Because power cycling fixed that issue (ie. the drive mounted and read file and config etc), but after rebooting it hit a different bug (mentioned in my post above) that still rendered the printer unusable at that point.

chas2706

Ok that's an improvement but for me power cycling, resetting or re-installing made no difference.
I've had to revert to RRF3.01RC3 but now running on the wrong version of DWC because there is no indication anywhere how we SBC users can download a specific version of DWC.

chas2706

This has learnt me a big lesson. Always, always, always make a current back up before you download a "new release"! My latest back up was from a few previous releases.

A Former User

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

grep duet3d -r /etc/apt | grep unstable && 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 || echo Please swtich to unstable list.

edit changed to fail if not on unstable list.

Also according to chrishamm switching to instead of adding the unstable list may be the way to go

#comment out stable list
sudo sed -i '/ stable/s/^/#/g' /etc/apt/sources.list.d/duet3d.list
#add unstable list
echo "deb https://pkg.duet3d.com/ unstable armv7" | sudo tee /etc/apt/sources.list.d/duet3d-unstable.list

ChrisP

@chas2706 said in RepRapFirmware 3.01-RC6 released:

Ok that's an improvement but for me power cycling, resetting or re-installing made no difference.
I've had to revert to RRF3.01RC3 but now running on the wrong version of DWC because there is no indication anywhere how we SBC users can download a specific version of DWC.

As @bearer pointa out, rolling back isn't tricky. Tbh, theres a reason that it's a beta firmware, so it should be obvious that backups are wise when trying a new "upgrade".

I'd still be interested to know the output of you logs for the DCS service.

A Former User

the start of the log is probably more relevant than the end of it.

chas2706

@ChrisP said in RepRapFirmware 3.01-RC6 released:

As @bearer pointa out, rolling back isn't tricky. Tbh, theres a reason that it's a beta firmware, so it should be obvious that backups are wise when trying a new "upgrade".

I understand the meaning of beta firmware but if you have Duet3 with SBC and dare to "upgrade" there is no guarantee that if upon failure an older backup will work.
I now have this problem running RRF3.01.RC3 from a backup:

So now I will be spending numerous hours starting afresh!

A Former User

@chas2706 said in RepRapFirmware 3.01-RC6 released:

there is no guarantee that if upon failure an older backup will work.

that would imply your backup isn't covering your needs. simply shutting down the pi and cloning or imaging the SD card would take care of all but the RRF firmware on the Duet which can be flashed after restoring an old SD card. (caveat if they changed the iap binary)

ChrisP

@chas2706
You really shouldn't need to start afresh. Even if you do, as long as you have a copy of the sys & macros folders it should take longer to burn a new raspbian image than it does to get that fresh Linux install to a working printer. I can't remember it taking more than about 15 mins following the guide on the wiki.

You'll be back up and running in no time

droftarts

@Marco-Bona said in RepRapFirmware 3.01-RC6 released:

1_ I continue to have the problem with the correct visualization of the Layers (yesterday @droftarts said it would be solved with the new build)

Strange, because this is mentioned specifically in the notes;

Bug fixes:
When printing a file, the first layer time was reported incorrectly, and when the print completed the total print time reported was incorrect

Have you updated the firmware AND the DWC?

Ian

A Former User

@chas2706 said in RepRapFirmware 3.01-RC6 released:

So now I will be spending numerous hours starting afresh!

see my edited post https://forum.duet3d.com/post/143326

Danal

@chas2706 said in RepRapFirmware 3.01-RC6 released:

because there is no indication anywhere how we SBC users can download a specific version of DWC.

apt allows specification of a version after the thing you are installing.
sudo apt install duetsoftwareframework=1.2.4.0

This, plus a few more commands below, gives you total control over the duet installation on the Pi. You can force it into a good (or bad!) state.

You may want to do 'uninstall' in certain circumstances, or use the --reinstall flag (which forces a complete install even if apt thinks that version is already installed) Examples:
sudo apt uninstall duetsoftwareframework
sudo apt install duetsoftwareframework --reinstall

You can list all available versions via:

sudo apt list -a duetsoftwareframework
Listing... Done
duetsoftwareframework/unstable,now 1.3.0 armhf [installed]
duetsoftwareframework/unstable 1.2.5.0 armhf
duetsoftwareframework/unstable,stable 1.2.4.0 armhf
duetsoftwareframework/unstable 1.2.3.1 armhf
duetsoftwareframework/unstable,stable 1.2.3.0 armhf
duetsoftwareframework/unstable,stable 1.2.2.1 armhf
duetsoftwareframework/unstable 1.2.2.0 armhf
duetsoftwareframework/unstable 1.2.1.0 armhf
duetsoftwareframework/unstable 1.2.0.0 armhf
duetsoftwareframework/unstable,stable 1.1.0.5 armhf
duetsoftwareframework/unstable 1.1.0.4 armhf
duetsoftwareframework/unstable 1.1.0.3 armhf
duetsoftwareframework/unstable 1.1.0.2 armhf
duetsoftwareframework/unstable 1.1.0.1 armhf
duetsoftwareframework/unstable 1.1.0.0 armhf
duetsoftwareframework/unstable,stable 1.0.4.1 armhf
duetsoftwareframework/unstable 1.0.4.0 armhf
duetsoftwareframework/unstable 1.0.3.5 armhf
duetsoftwareframework/unstable 1.0.3.3 armhf
duetsoftwareframework/unstable 1.0.3.2 armhf
duetsoftwareframework/stable 1.0.3.1 armhf

Generally, when doing a simple install, apt will deal properly with dependencies. During uninstalls and reinstalls in often does not. You can list all dependencies via:

apt-cache depends duetsoftwareframework
duetsoftwareframework
  Depends: duetcontrolserver
  Depends: duetsd
  Depends: duettools
  Depends: duetwebserver
  Depends: duetwebcontrol
  Depends: reprapfirmware
  Depends: reprapfirmware

A Former User

@Danal said in RepRapFirmware 3.01-RC6 released:

Generally, when doing a simple install, apt will deal properly with dependencies. During uninstalls and reinstalls in often does not. You can list all dependencies via:

not when downgrading dsf it seems

pi@raspberrypi:~ $ sudo apt install duetsoftwareframework=1.2.4.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 duetsoftwareframework : Depends: duetcontrolserver (= 1.2.4.0) but 1.3.0 is to be installed
                         Depends: duettools (= 1.2.4.0) but 1.3.0 is to be installed
                         Depends: reprapfirmware (<= 1.2.4.0-999) but 1.3.0-2 is to be installed
E: Unable to correct problems, you have held broken packages.
pi@raspberrypi:~ $

thus my post detailing all the verions..

Danal

Agreed, during anything but a simple install, it often does not.

That's why I showed the commands that list dependencies and versions.

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.