2024-11-02, 10:06 AM
(2024-10-13, 02:46 AM)CaptIgmu Wrote: This was a first. System not usable, would not fully boot after latest RPi5 update. If I removed the MacArthur Hat, everything worked. I have now set my boot order on the RPi5 to SD card then USB drive then NVMe drive, so I can at least recover. Looks like it slows down at some type of raspi-config and gets hung trying to access the network, happens before the initialization of OpenPlotter. Would be nice to have a grub and ARM64 CloneZilla when this happens!Hello,
My sudo -E rpi-eeprom-config —edit now looks like this:
[all]
BOOT_UART=1
BOOT_ORDER=0xf641
POWER_OFF_ON_HALT=1
Will backup to SD card before any updates in future, so I can always go backwards . . .
Always remember to tick new partition UUIDs when doing any copying (SD Card Copy).
I started using RPI 5 + OpenPlotter + Mac Arthur Hat a few months ago as a French bearded noob! And before plugging it into 12V on my sailboat, I work on it at home on 220V. I haven't had problem after updating my RPI for the moment because I decided not to update my RPI anymore until the issues are resolved. I only do the updates suggested by OpenPlotter.
But I have a few questions :
1/ I saw your eeprom config :
Code:
POWER_OFF_ON_HALT=12/ For backup to SD card, you says : ‘Always remember to tick new partition UUIDs when doing any copying (SD Card Copy).’ OpenPlotter 4 doc says: ‘DO NOT tick the New Partition UUIDs option. Some programs require the original and the copy to be exactly the same to work correctly.’ Is it necessary to tick the new partition UUIDs when using an NVMe SSD on the RPI? Does this make it possible to have a bootable SD card copy of the Openplotter configuration? When I make a copy of my NVMe on SD card with SD card copier without ticking new partition UUIDs , the RPI systematically reboots on the NVMe even though it is in second position. However, my boot order on the eeprom is 461, so SD card then NVMe then USB.
Thank you in advance to reply.
Laurent

