A brief affair with Manjaro

Chat about Linux in general
Forum rules
Do not post support questions here. Before you post read the forum rules. Topics in this forum are automatically closed 6 months after creation.
Locked
nanners

A brief affair with Manjaro

Post by nanners »

I had previously used Manjaro, albeit briefly, in 2015. At that point I hadn't yet burned my ties to Windows completely and when you know you are "just messing around" with a distro, it's easy to miss the finer points. So these past few months I've been with Mint exclusively and ran into an issue (see also: not an issue) with needing to compile a few packages, do a PPA hunt, etc., all stemming from my ridiculous need for the latest, greatest AMD drivers. After some cross-over forum searching I kept running back into Manjaro as the place to be for an AMD Radeon user. The internal MHWD (https://wiki.manjaro.org/index.php?titl ... Detection) program was almost purpose-built for staying on top of just-barely-stable and experimental open source drivers. Long story short, I made the switch after some VM tests and did a real install. I really like the direction of Manjaro and where the devs want to be. The have a surprisingly active and vocal community, rivaled only by THIS VERY FORUM of course.

Anyway, I did like AUR and learning exactly what is going on behind every GUI operation. I managed to compile a bunch of things without cheating, got around with pacman sans pamac/octopi and went through a few full system upgrades, one by hand in the terminal (with a web guide open). Just as I was getting comfortable, I made a single (huge) mistake on a single (major) dependency. It was my fault for sure, but that yaourt command and pamac "click and go" GUI setup they have in place for doing AUR source compiles is really easy to get cocky with. AUR is disabled by default, but honestly Arch isn't meant to keep you out of things, no matter the consequence. A very respectable stance in my eyes, by the way, just as Debian's principals are equally admirable for their goals.

So yeah, I shitbricked my system and felt the agony of defeat. I rolled back just fine and doing that was super fun and a nifty learning experience, but at that point the actual downside of ultra-edge-rolling set in. I wanted badly to find a "rolling Debian", but it's kind of an oxymoron. Debian-base is Debian-base because it stays a little behind. Mint allows me to add PPAs for the stuff I really need always updated and for everything else, who cares if my version of networkmanager's note applet is a few versions behind?

That's where I'm at now anyway. I'm sure I'll change my mind again after I discover the 4.9 experimental SI Radeon support isn't gonna work unless I go get myself the newest release candidate kernel.....

Note: In doing all of this I also discovered that both Manjaro Stable and Mint 18.1 run the very same kernel by default and the 4.8.* upgrade (like I just did for the hopeful wifi and radeon and KVM nesting) is much more stable in Mint.


[Edit: loling at the "unicorns" filter]
[Edit 2: Wanted to note for reference on the kernels that I was using Manjaro 16.10.03 which defaulted to the LTS 4.4.27 kernel, which I believe is what Mint 18.1 shipped with, perhaps a dev release off. Both offer an easy solution to upgrade at will.)
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
groze

Re: A brief affair with Manjaro

Post by groze »

nanners wrote:
Note: In doing all of this I also discovered that both Manjaro Stable and Mint 18.1 run the very same kernel by default and the 4.8.* upgrade (like I just did for the hopeful wifi and radeon and KVM nesting) is much more stable in Mint.


[Edit: loling at the "unicorns" filter]

nanners
Does that mean mint 18.1 will have the intel microcode issue? Here is quote from an article.
Arch implements the loading of Intel processor microcode updates at boot differently from other distributions. While other distributions include the microcode into the initramfs (the replacement of the initrd) image, Arch leaves this as a separate image, which is loaded by Arch's GRUB at the same time as the initramfs. Because the implementation of GRUB through the scripts in /etc/grub.d/ by other distrubutions doesn't account for this difference, other distributions' GRUB try to load the microcode image as if it was the actual initramfs, resulting in an immediate kernel panic.
nanners

Re: A brief affair with Manjaro

Post by nanners »

groze wrote:
nanners wrote:
Note: In doing all of this I also discovered that both Manjaro Stable and Mint 18.1 run the very same kernel by default and the 4.8.* upgrade (like I just did for the hopeful wifi and radeon and KVM nesting) is much more stable in Mint.


[Edit: loling at the "unicorns" filter]

nanners
Does that mean mint 18.1 will have the intel microcode issue? Here is quote from an article.
Arch implements the loading of Intel processor microcode updates at boot differently from other distributions. While other distributions include the microcode into the initramfs (the replacement of the initrd) image, Arch leaves this as a separate image, which is loaded by Arch's GRUB at the same time as the initramfs. Because the implementation of GRUB through the scripts in /etc/grub.d/ by other distrubutions doesn't account for this difference, other distributions' GRUB try to load the microcode image as if it was the actual initramfs, resulting in an immediate kernel panic.
I'm definitely not the most qualified, but I think the issue with Arch involved users with Intel proprietary firmware who had missed an important update to the package and how it installed in the OS. Users needed to alter initramfs parameters within their Arch/Manjaro install and my guess is some users just didn't get the memo or Intel/upstream had a secondary issue. It seems that Intel locked the ability to overclock using their firmware for a fairly popular model of CPU. That is just my impression from what I gleaned off the Arch Wiki and my forum time in Manjaro, but I could be way off on this. A quick Google search reveals there was a big issue with the kernel and the Intel microcode late last year, but it has been marked as resolved and patched as far as I can tell. I cannot find any credible Mint/Ubuntu user posts about having the problem, so it might have been limited to Gentoo and Arch, but again, that's an assumption. Also worth noting is that the Gentoo patch I did see was for x86, and Arch/Manjaro uses a combined 32/64bit ISO. Might have been limited to older architecture (I've been 100% AMD for 10 years or so, don't keep up with Intel).

Here is the one tab I have open about it right now and a generic link about the issue:

http://arstechnica.com/gadgets/2016/02/ ... de-update/
https://bbs.archlinux.org/viewtopic.php?id=188252
Locked

Return to “Chat about Linux”