abrer

Corrod

While I generally agree: in this case - you hit most of the points I cared to have mentioned. But considering that lack of participation that comes with small(er) communities, I’d rather have provided some input (visual or otherwise) to encourage further participation, or to at least have furthered the perception.

Otherwise, I don’t have much to add. We just need more bodies doing more things here at the Fediverse in more niche communities that we care about. The issue with the larger audience is it tends to transform into the “Hive Mind” that we all know and love. Because lurkers (such as myself) don’t typically add to conversations when we feel our thoughts have been well enough captured (eg - “this”).

A double-edged sword, for sure.

This.

No worries. When checking that output, it is for the working 6.4.8-arch1-1 kernel. The broken kernel boot attempt would be most useful, but I don’t want to make you suffer to get it, if you are back to a working system. I think at this point it is safe to say your laptop isn’t a fan of the newer kernels.

I would :

1. (fresh install/andor working machine) update your /etc/pacman.conf to ignore updates to packages linux and linux-lts
2. Devise a way to add multiple systemd-boot boot entries. I was working on this just a bit ago but I don’t have it fool proof and it drops you to an emergency shell. So I am hesitant to share this at the moment.

–

Ideally: You could (from a working system) install a known working LTS image (pkg linux-lts), and exclude that from updates until you land on a working kernel release (keep an eye on testing and core repos once a week or so). in this way, you’ll have a working LTS, and can upgrade/downgrade mainline kernels as you please, booting back into LTS to correct issues should they arise.

edit: minor

Does EndeavourOS use pacman?

You might consider modifying /etc/pacman.conf to include the option IgnorePkg=linux linux-lts until this is resolved. 6.4.12.arch1-1 was added ~4 days ago. If you check the releases arch linux kernel releases here, they have nearly a weekly cadence. This may be a case you can ride out until a newer kernel is released that might solve your issue.

If you need access to older releases, see the archive.

For root cause analysis – is it possible for you to extract/view the journal logs now that you have upgraded the kernel causing the issue? – /var/log/journal is a good start. My time is limited, but I’m curious to see what’s going on in there. In any case per your and Illecors’ testing, it seems you have isolated the issue to the linux package.

I just realized you’re also on systemd-boot (I am too). I’ll check into a way to revert back to prior kernels (for I also may run into a similar issue).

edit: updated IgnorePkg line to include both your mainline and LTS kernel (Pacman -Syu updates both) if you opt to hold them for updates.

So this occurs after an update. Is it not possible to boot into the prior kernel?

If possible to boot into the prior kernel, can you inspect logs or the journal to see where your error is cropping up?

This issue sounds like a regression of sorts with a driver, but log/debug would help confirm. This would be one worth reporting to upstream if you can rescue some logs (I gather you can if you can boot the disk from another enclosure).

If you can boot into the machine, investigate note from the journal:

• journalctl --list-boots
• journalctl -b -1,
• • where -1 was the prior boot, -2, the one before that, etc

– If you are booting into a live environment or are otherwise mounting the disk:

• journalctl -D /var/log/journal/ID_GOES_HERE
• example path: /var/log/journal/2dff8304d5114c44bfb1311357a3cd87

– Keep us posted.

If truly a driver regression, but you can boot from the prior kernel (if you don’t have it, install it via livecd or so), definitely report this one and remain on the prior kernel until resolved. Bleeding edge things.

I read that with Guga cadence.

++ for no bar.

Draw.io is pretty amazing.

RHEL> AD:

I haven’t had time for root cause analysis, but a recent patch cycle (last few months of patches) in our environment broke RHEL7/8 AD integration with via SSSD.

Did anyone run into this? I’ll post the fix when I get home should any other admins run into this gem.