It has been my pleasure! Hope it'll work out for ya!
HayadSont
joined 1 month ago
Mint has far too many issues to be a serious suggestion.
Would you mind elaborating on that?
Edit: Note that I've been a Linux^[Including the likes of: EndeavourOS, Fedora Atomic, Nobara and Zorin OS] user for a couple of years now, so no need to dumb down the answer for me. Just a heads-up*.
I do think uBlue is downstream
It's indeed downstream~ish. But perhaps just different enough to actually make a meaningful change.
I'm pretty clueless at that point. Never seen something like it. Apologies for not actually being able to help out. Hopefully it will be resolved soon, though.
This is probably not the advice you'd like to hear, but I wonder if rebasing to uBlue's Kinoite would make any difference. Regardless, wish you the best!
No Nvidia, just intel integrated graphics. Its a dell ispiron 7500.
Yeah, that shouldn't cause any pecularities.
LayeredPackages: alacritty bat btop distrobox fish flatpak-builder kpeoplevcard light lsd mako neovim parallel python3-neovim shellcheck swaybg swayfx swayidle swaylock syncthing tailscale tmux virt-manager waybar wlogout wlsunset wofi
Hmm..., nothing too outrageous, I think; still, consider rpm-ostree reset to at least rule out the possibility that any of the layered packages are to be blamed. If you're afraid of losing your working deployment, ensure to evoke the sudo ostree admin pin 1 command to pin it. (ASSUMING THAT THERE ARE ONLY TWO DEPLOYMENTS WHEN YOU DO THIS). After you've done the pinning, ensure that you pinned the correct one by checking this with rpm-ostree status; the deployment you wish to pin should state the fact that it's pinned.
journalctlshows nothing. That’s what I meant by no logs, I should have been clearer. It’s not even getting that far. It’s like it’s stuck in grub, but only when I try the new kernel.
Perhaps I had to be more clear and explicit, boot twice:
- first, into the now broken deployment, wait until the time your system should have booted otherwise. Then, hard reset.
- secondly, to your still working deployment, then evoke the
journalctl -b -1command. This should, unless something is wrong with how systemd is setup on your system, show you the logs of the previous boot. You could even compare it with your current boot (which can be accessed withjournal -b) and see where it diverges, though looking at the logs of the corrupt boot sequence should suffice.
The only deviation from the vanilla kargs have been for troubleshooting this and I did it in the grub editor so they aren’t persistent. I tried removing rhgb changed quiet to verbose and debug and loglevel=7 just to see if anything would happen. It still just hangs
Aight. Thank you for putting in the work so we can rule that out!
Anybody else experienced something similar?
FWIW, I just booted my laptop that runs a Fedora Atomic derivative -secureblue to be precise*- and updated to the 6.14.5-300 kernel. Afterwards, I rebooted and found a still functional system. Just so you know; GNOME is installed on my system instead of KDE Plasma, but I don't think it would have mattered.
Regardless, your issue remains and is rather peculiar. Uhmm..., I'm just thinking out loud at this point, but have you considered the following:
- Is this a system with Nvidia? If so, could it be somehow related?
- How 'pristine' is your system? Have you layered a bunch of packages? If so, do you think the issue would persist after a
rpm-ostree reset? - Beyond layering, I have experienced that kernel arguments could cause issues down the line. So, have you tinkered with any of that? If so, do you think the issue would persist if you would remove all user-added kernel arguments?
Aside from the above, I don't really know what would cause an issue as such.
Or know of a way I can get some more info out of the system
Consider accessing systemd's journaling with journalctl. This should be (easily) accessible on a successfully booted system. In your case, that would be your working deployment.
To clarify, this is just my list that I shared in the hope that others would follow suit 😅. (Which hasn't been successful so far...) Consider posting yours 😉!
I was hoping someone else would step in, but alas...
Look, if your goal is spreading awareness of software freedom, search manipulation isn't the way 😅
GNU's approach has become increasingly dogmatic while the ecosystem moves forward. Their stance on firmware blobs and microcode updates creates genuine security problems that projects like coreboot solve with a more balanced approach.
The FSF views software freedom as an absolute, even when it means sacrificing security or functionality - kinda like refusing to use an umbrella because it wasn't made with 100% free-range organic materials... while standing in a thunderstorm
This is why Torvalds rejected GPLv3 for the kernel and why distros are finding better ways to respect user freedom without the absolutism.
People discover valuable ideas when they solve real problems, not when they're forced into terminology debates. If GNU's philosophy is truly compelling, it'll spread on its own merits, no search engine tricks required!
Why? The likes of Alpine Linux and Chimera Linux don't adhere to GNU/Linux to begin with. Even Ubuntu has intentions to replace the GNU coreutils with alternatives that have been written in Rust.
Don't get me wrong; GNU has been instrumental for enabling the Linux ecosystem to begin with and will probs remain relevant (at least to some capacity) for the foreseeable future. However, I absolutely don't see any reason to be pedantic about this; especially as something like systemd -whether you like it or not- has become a lot more important for what mainstream Linux has become. Yet, nobody in their right minds would even consider to refer to Linux as systemd/Linux (thankfully so).
Thank you for the answer! Much appreciated.
Could you be more explicit? Like, I don't think it literally deletes itself from your drive. Right? So, what is it then?