This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unable to boot into RPi5 with latest updates
#1
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).
Reply
#2
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
Reply
#3
(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 :
Code:
POWER_OFF_ON_HALT=1
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
Reply
#4
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.
Reply
#5
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.
Reply
#6
(2024-11-07, 03:55 PM)Sailoog Wrote: 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.

Thanks for your reply
Reply
#7
(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 :
Code:
POWER_OFF_ON_HALT=1
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!
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)