I’m reading this article on the EOS wiki about arch-chroot
https://discovery.endeavouros.com/system-rescue/arch-chroot/2022/12/
My question is how to check/identify exactly which package/update breaks the system before I chroot? What’s the appropriate procedure?
you can check you pacman log
/var/log/pacman.log
What you mean by “breaks”, what are symptoms and last boot messages?
Maybe check the arch news first before updating ?
I have a fish function I run before updating that lists all the packages that are upgradeable. With this, I can somewhat narrow down which packages have caused an issue. It only works somewhat because I upgrade at most twice a week, but usually only on weekends, which means my updates are usually big.
If you update every day (or every few hours), then the function becomes more useful.
It is essentially the same as using a stripped-down and more date-specific version of the pacman.log file, but with less possibly unnecessary information.
The function and/or fish itself is not needed, but rather the packages they reference. In this case, checkupdates is needed and can be installed via the pacman-contrib package. For AUR packages, add your favorite AUR helper to the mix.
checkupdates && paru -Qua
The function automatically outputs the upgradeable package names to a file and then opens it in a text editor so that I can review it before proceeding with the update.
The full function (it can use yay -Qua and another text editor if preferred):
### Function to send checkupdates and paru -Qua to a file then open it in micro
function cup
set syu_date_format (date +"%Y-%m-%d_%H-%M-%S")
set syu_log_name "/path/to/output/file/syu-$syu_date_format.sh"
# Capture the output of checkupdates and paru -Qua
set checkupdates_output (checkupdates | sed 's/\x1b\[[0-9;]*m//g')
set paru_output (paru -Qua)
# Check if there are any updates
if test -n "$checkupdates_output" -o -n "$paru_output"
# If there are updates, create the file and write the output
printf "%s\n" $checkupdates_output > "$syu_log_name"
printf "%s\n" $paru_output >> "$syu_log_name"
sleep 0.1
micro "$syu_log_name"
# Remove the last two lines above if you don't need to see the output.
# They can be replaced with a `pacman -Syu` alias to update immediately.
# This is just good for logging the available updates before updating.
else
echo "No updates found."
end
end
You haven’t even mentioned how your system is broken? After updating it doesn’t boot? More information is needed and would be nice to see what the hardware is. When you arch-chroot you could post the hardware info.
inxi -Faz | eos-sendlog
After logging in over the KDE SDDM, I only saw the single mouse cursor in the middle of the black screen, nothing else. Unable to move the cursor. But I can use my shortcut key to restart or shutdown.
I also updated the “chirp-next” software, but when I clicked the icon, it tried to load but then failed after a couple seconds…
Hi. I had a similar thing happening. Yesterday was working fine but some update broke the graphics on both wayland and X11. Interestingly, as I also have Kodi installed, I could login to a Kodi desktop and would work fine. I’ve a laptop with amd iGPU.
After many hours and lack of sleep, trying to work out what specifically was the issue, restoring a snapshot and updating to the latest version, the issue would still persist. Stumbled upon a post here that includes the solution - https://forum.endeavouros.com/t/display-unresponsive-for-5-minutes-after-boot/77948/2
In the kernel options, I added amdgpu.dcdebugmask=0x10 and the desktop environment worked ok for me. Try it out.
Thank you for sharing your experience and link. I’m just curious how he figured out the solution without knowing the cause. I have the cursor freezing only on my Thinkpad P14s laptop, my other two Dell desktops are totally fine…
He used a clanker, ChatGPT. If my experience is anything to go by, I tried multiple things before realising that it had something to do with the screen. I could use ctrl+alt+del to navigate the shutdown menu without seeing it.
Not sure how this creeped up but there are a few people affected by this. The amdgpu.dcdebugmask=0x10 option removes the panel self-refresh. My laptop battery consumption increased close to 1W in idle from this change alone. Not something I’d intend to keep long term.
Another observation. My P14s wouldn’t boot to the EnOS installer / Live Mode via Ventoy. So I had to create a bootable USB for that…so weird.
you need to make sure ventoy is up to date and that secure boot is disabled (Through ventoy not the bios)
Might be an ddcutil issue….
I posted about here too: Computer freezing on loading screen after logging in on Plasma KDE - #8 by pjbcr
Thank you. I just downgraded ddcutil and it works. Just curious how they identified this package is the cause.
yes
Special Note
@apachecai You should make sure secure boot is turned off in the Bios if you haven’t turned it off as we do not support Secure Boot out of the box.
Logs….. 
Apparently the new ddcutils tries to access all the i2c devices and lacks permissions.
More details in the bug report
Thanks for reminding. I disabled secure boot on both Ventoy and BIOS, no luck…
are you using mbr or gpt?
gpt, as shown on my screenshot.
