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!
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).
(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!
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).
Hello,
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 :
It seems to me that this means that the eeprom is configured so that standby power consumption is minimal. Mine is still the default config ...HALT=0. This article (
https://www.jeffgeerling.com/blog/2023/r...ption-140x) says that this configuration can malfunction with certain hats. Is it possible to use this configuration ...HALT=1 with the Mac Arthur Hat on 220V or on 12V or both? I'm asking this question because with 12V it's the Mac Arthur Hat that powers the RPI, but with 220V it's the other way round.
2/ 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
I don't know the answer to these questions. This sounds more like general Raspberry Pi / OpenPlotter questions than something specific to the MacArthur HAT.
1) You do not need that config to cut power when using the power module because the module will do it for you. The consumption will be only 0.1 mA.
2) The warning about not checking the UUID of the new partition is in OP's docs because some paid charts might stop working and treat the system as a new one, losing the license.
(2024-11-02, 10:06 AM)Laurent PARIS Wrote: [ -> ] (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!
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).
Hello,
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 :
It seems to me that this means that the eeprom is configured so that standby power consumption is minimal. Mine is still the default config ...HALT=0. This article (https://www.jeffgeerling.com/blog/2023/r...ption-140x) says that this configuration can malfunction with certain hats. Is it possible to use this configuration ...HALT=1 with the Mac Arthur Hat on 220V or on 12V or both? I'm asking this question because with 12V it's the Mac Arthur Hat that powers the RPI, but with 220V it's the other way round.
2/ 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
Laurent,
I have an RPi5 with MacArthur Hat at home for development in addition to one on my boat, a sailing cat.
My home system is powered by USB-C. If OpenPlotter is configured properly for shutdown and you are
not connected to 12V, you will
not be able to boot the system!
Until I started checking
new UUIDS , could not copy between SD card, USB SSD drive, NVMe PCIe drive using
SD Card Copy (would not allow to copy to same UUID device).
Hey, we are all
noobs, always something more to learn!
(2024-10-13, 04:01 AM)Adrian Wrote: [ -> ]There is an issue with the CAN/NMEA2000 integration with the latest update of Raspberry Pi OS. See here on how to temporarily disable the problematic feature while the Linux wizards figure this one out:
https://forum.openmarine.net/showthread....1#pid31801
hi
I encountered this issue a few months ago and avoided it by not updating my pi after rebuilding it. I remember seeing this thread at the time and face palming as I didnt need to do a rebuild.... but there you go.
I have today installed pypilot and the issue has reappeared. The pi is headless and would be a pain to remove to work on at home. Even more irritatingly, I did a backup after installing pypilot but before rebooting and realising it was broken - so my backup also doesn't work! I have come back to look up how to fix it, but the thread is 'not found' and your link doesn't work. Do you recall the steps?
Thatll teach me for running outdated software!
It may sound stupid, but that thread was confusing the AI we are training to help with support and I had to delete it since the problem was solved by updating to the latest kernel
Just remove the MacArthur HAT, update the system and you are done:
sudo apt update
sudo apt full-upgrade
Thank you Sailoog - that is very helpful. I hadn't realised the new kernal fixed this, I thought i still needed to blacklist something.... I will give that a go tomorrow and report back if I run in to any issues.
All the best