Keep gupdate.gcd on-board after update?

[Butters]

@Scyllo
Bootlooping by a device is indicative of a 'soft-bricking'. You must load cure firmware in preboot mode to re-enable Mass Storage Mode so you can delete faulty files or re-format correctly. Read here: [Only registered and activated users can see links. ]

[Scyllo]

@Butters
Consequently, the following sentence refers only to flashing with the original RGN?

There's only need to delete it, if present, before updating manually by RGN or with GCD on media card.

I had suspected on the basis of your statement that a perhaps existing GUPDATE.gcd already disturbs, if the Cure file is to be flashed on the device. And I could not remove this .gcd, because the device is not recognized before flashing with the Cure file on the PC.

[Butters]

If present, a gupdate.gcd can only be fully initiated by the device if the device is capable of booting. The device only looks for a gupdate.gcd after loading maps and other essential files is complete. It will only try to update the device by initiating the GCD if it's deemed to be a later version of fw than that presently loaded. However, even just examining the GCD can 'soft-brick' the device if the file is corrupt.

Cure fw RGN intentionally stalls the boot before any files at all can be loaded. While both cure and original fw RGNs will directly and immediately flash all regions applicable i.e. 12, 14 certainly and maybe 127 and 158 too, it's 14 where the main firmware, aka 'System Software' is present and it's responsible (simplistically) for boot initiation and loading files during the boot.

Cure fw in region 14 doesn't load essential files and it stops the boot process, intentional after Mass Storage Mode is attainable which is before loading files. However original fw will try to load those files so the device will attempt to boot fully, loading all needed files and a gupdate.gcd present will also be examined. If any one of such files are bad the device cannot boot and will either freeze or bootloop, with MSM no longer attainable.

A device with cure fw loaded has Mass Storage Mode re-enabled even though it is stalled (frozen) on the logo splash screen. The entire purpose of cure fw is to allow MSM to again work. Technically, the device is still 'soft-bricked' but that's part of the process and it's why, after removing corrupt files or re-formatting properly, that original fw has to be loaded, again as an RGN in preboot, because any 'good' original fw GCD added manually would just sit there in the file system, unread, if a cure fw is still loaded in such a (therefore un-bootable) device.

In your case you seem to be assuming that a corrupt GCD is the problem and often after a firmware update using GarminExpress or WebUpdater, or simply manually placing a later version GCD in the .System folder, that is indeed the case. However the bootloop could also be caused by a bad map IMG file, or it might be a GPI, VPM, etc. file causing the problem. This is why it's safer to update via a gupdate.gcd in a Garmin folder on a media card because if the GCD is faulty it still 'bricks' the device but then removing the card allows the device to boot.

TLDR: You must load cure firmware so you can delete suspect files progressively and as a last resort re-format.

[Scyllo]

In your case you seem to be assuming that a corrupt GCD is the problem and often after a firmware update using GarminExpress or WebUpdater, or simply manually placing a later version GCD in the ....
This is why it's safer to update via a gupdate.gcd in a Garmin folder on a media card because if the GCD is faulty it still 'bricks' the device but then removing the card allows the device to boot.

TLDR: You must load cure firmware so you can delete suspect files progressively and as a last resort re-format.

Thank you but I currently have no problems with my device (2599LMT-D).

However, I had this once (boot loop) and was able to solve it successfully at the time using GarminCure3.

But I had not paid attention at the time whether a GUPDATE.gcd is on the device when it was in MSM mode, but have flashed the original FW (.rgn) directly afterwards.

And your statement ("There's only need to delete it, if present, before updating manually by RGN [...]") just sounded as if you always have to delete it before importing an .rgn.

Now I was worried that if the whole thing happened again, I might not even be able to load the Cure.rgn, as there might be a corrupted GUPDATE.gcd on the device itself.