Hi all,
I flashed my sdram card with manjaro gnome which worked well on raspberry pi4. I use the hdmi safe param to get a HDMI output.
After a pacman -Syu or an update with the graphical software mantainence programm the reboot fails… I remember I have kicked manjaro because this happened quite often dated years back in time.
Can someone give me a hint how to safely update a system without trashing it… I find this quite wired.
What else do I need to run if pacman -Syu is not enough.
I have not yet configured SSH and stuff… so I want just be able to update.
Anyone having the same issues as me with gnome manjaro arm (current image) on rasp pi 4?
Isolating boot issues is tricky business, but by no means hopeless. When you write “the reboot fails…” I assume you mean that there is no output at all (in particular, no error messages). If that is the case, you can try the following:
Simultaneously press Ctrl+Alt+F2, which should take you to a terminal in case the problem lies with Plymouth (the boot splash screen) or Gnome/Wayland. If you can access the terminal this way, kindly post the output of cat /var/log/pacman.log so that we can narrow down the problematic package upgrade(s).
If accessing the terminal as explained in 1. fails, you should be able to view the logs from the last failed boot by inserting the SD card into (almost) any Linux computer on which you then run journalctl -D PATH_TO_SDCARD_MOUNTPOINT/var/log/journal -b 1. You can share the logs here for further troubleshooting.
Hi @robg thanks a lot for your quick response and help offer.
I could not switch to terminal. For the latter answere of yours - unfortunately - my second linux box (debian) does not support reading the journal from manjaro: it says something like function not available on file system … even reading the file directly with DEBUG… does not work.
last but not least
from my analytics I can conclude as follows… because switching to console does not work, nor any console output is happening at start… (there been some prompt in the original state at boot time) I infere the linux firmware is being updated turning my rasppi to a brick… The only and best thing would be to lock kernel and firmware… can this be done somehow?
Why do I need to update to a newer kernel version if there has been no testing beforehand? I remember this years ago still been a problem. Locking any packages would be great or at least allow for minor version updates but not major version updates.
I’ve seen linux-firmware among all packages being updated… I assume there are driver changes.
Since there seems to be no one else confirming your issue I assume the issue is likely to lie with your specific use case whether it be with your type of monitor/tv your are using or possibly something in your config.txt or cmdline.txt.
You have not given much info like your boot config files or which branch/kernel you are following but if you are following the stable branch and the latest linux-rpi4 kernel and firmware there has been plenty of testing on it.
Assuming you are using the stable branch (i’m not sure what the hdmi safe param you are using though) you might try changing dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d in config.txt. Maybe your monitor will be picked up better if the issue lies with the new firmware. You may have to fiddle with what ever hdmi safe param you are using also.
I do not run gnome but have no issues here. I have a VIZIO tv for a monitor and have always had to have a custom config for it to work with dtoverlay=vc4-kms-v3d because things are not standard with the reporting it’s EDID info.
I believe Darksky’s comment hits the nail on the head. Some monitors work better with the Raspberry Pi (and upstream kernel) than others, and you might have pulled the short straw…
In any case, regarding your question: To prevent packages from upgrading, proceed as explained here. (Kindly consult the ArchLinux Wiki before posting here; their documentation is exceptional!) I suggest you add the kernel, headers, and firmware to the ignore list.
To expand on Darksky’s suggestion: You can try forcing a monitor configuration that is “known to work”. By this I mean that you extract the EDID file (using, for example, get-edid) on a working Linux computer. You can then force the Raspberry Pi to apply the extracted EDID file using the hdmi_edid_file setting in /boot/config.txt
Thank you for raising the issue, only this way have I found this forum.
I can confirm the issue, have been facing exactly the same problem with exactly the same symptoms as you have described even on fresh manjaro installs.
also thanks to @Darksky and @robg for the fix suggestions, I will try them now and post my results as soon as I have them^^.