I have a very strange hardware vs software situation that I could use some insight on.

I know that this doesn't completely relate to Manjaro itself, but I have a bit of an issue I have been struggling with for a while relating to Linux as a whole.

Anyways, here is the issue. I have a Dell XPS 9570 which works great with Manjaro XFCE. All of the hardware works great (and PROPERLY) out of the box if I boot the live ISO with the Nvidia driver and add a boot parameter. I also have access to all of the software I want through Flatpaks as well, which is a really nice touch.

There is one issue I have with Manjaro: the packaging.Before I continue, most of this is inherently Arch Linux related and none of it can really be fixed by any Arch distribution. I don't always use my laptop since I have a main desktop that works fine when I'm at home (obviously, it runs Manjaro). Therefore, I really only utilize my laptop to work or play games when I'm on the go or I cannot use my desktop for some reason. So, this definitely does not go well with an OS that is constantly updating. Even if I have a decent connection (which is very rare at my school, in a hotel, etc), there's always the chance something goes wrong and I wouldn't have access to my live USB. Plus, because some packages in Arch can only be installed through the AUR (mainly plugins, dxvk, etc), I'm essentially relying on packages that aren't always tested well. Therefore, I just don't think Manjaro works well for me.

Now, here's my Catch 22. I really want to avoid anything and everything Ubuntu. I hate Snap as a package format and I do not trust Canonical when it comes to whether or not they'll "transition" my favorite app from a Deb to a Snap. If I did use Ubuntu, I'd sooner or later end up installing a package with snapd as a "dependency" or it would just not exist in the repos at all. And this counts for everything based on Ubuntu, including Pop OS, Elementary, and Mint (although only the latter has an XFCE edition available) since they still use Ubuntu's repos.

Okay, so I don't use Ubuntu. What else is there? Solus and PCLinuxOS are also rolling-release distributions, so they wouldn't work. OpenSUSE and Debian don't have the necessary Xorg server to use Nvidia render offloading, nor a recent enough version of the driver at all in Debian's case. I've tried using Fedora, but not having a single "nonfree" repo makes everything 50x more difficult, even if you enable RPM Fusion. Also, if you don't use their GNOME spin, you basically have no (usable) GUI options for installing RPMs/Flatpaks. Not to mention how you get an unusable "stock" XFCE desktop, you receive poor support from their community, and you, as a desktop user, are treated like a second class citizen overall.

I've done some work with Mageia, a very small, yet interesting, Linux distro that also uses RPMs, but it has some problems. For one, they have the latest versions of Mesa, Intel firmware, and the Xorg server (which I really need) and some other packages while Firefox is provided as the ESR build, the Nvidia driver is at 430 so it doesn't meet my hardware requirements, and they have way too many outdated/strange/unnecessary applications installed by default. I can accept the other issues, but the Nvidia one is crucial. I'm doing some packaging for them, so maybe some of this may change in the future, but they've given me nothing in regards to when they'll provide the 440 drivers.

So, after this overly long and verbose post, what do you guys think? Is there an option I'm missing or anything else I could try? If not, what would you do in my situation?

Here's the inxi -Fxxxz --no-hostname for my laptop if needed:

System:
  Kernel: 5.6.7-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Xfce 4.14.2 tk: Gtk 3.24.13 info: xfce4-panel wm: xfwm4 
  dm: LightDM 1.30.0 Distro: Manjaro Linux 
Machine:
  Type: Laptop System: Dell product: XPS 15 9570 v: N/A serial: <filter> 
  Chassis: type: 10 serial: <filter> 
  Mobo: Dell model: 0YYW9X v: A04 serial: <filter> UEFI: Dell v: 1.15.0 
  date: 12/25/2019 
Battery:
  ID-1: BAT0 charge: 3.3 Wh condition: 84.2/97.0 Wh (87%) volts: 12.0/11.4 
  model: SMP DELL GPM0365 type: Li-ion serial: <filter> status: Charging 
CPU:
  Topology: 6-Core model: Intel Core i7-8750H bits: 64 type: MT MCP 
  arch: Kaby Lake rev: A L2 cache: 9216 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 52815 
  Speed: 800 MHz min/max: 800/4100 MHz Core speeds (MHz): 1: 800 2: 800 
  3: 800 4: 800 5: 800 6: 800 7: 801 8: 800 9: 800 10: 802 11: 800 12: 800 
Graphics:
  Device-1: Intel UHD Graphics 630 vendor: Dell driver: i915 v: kernel 
  bus ID: 00:02.0 chip ID: 8086:3e9b 
  Device-2: NVIDIA GP107M [GeForce GTX 1050 Ti Mobile] driver: nvidia 
  v: 440.82 bus ID: 01:00.0 chip ID: 10de:1c8c 
  Display: x11 server: X.Org 1.20.8 driver: modesetting,nvidia 
  alternate: fbdev,intel,nouveau,nv,vesa tty: N/A 
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 20.0.5 
  direct render: Yes 
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel 
  v: kernel bus ID: 00:1f.3 chip ID: 8086:a348 
  Sound Server: ALSA v: k5.6.7-1-MANJARO 
Network:
  Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter 
  vendor: Bigfoot Networks driver: ath10k_pci v: kernel port: 3000 
  bus ID: 3b:00.0 chip ID: 168c:003e 
  IF: wlp59s0 state: down mac: <filter> 
  Device-2: Qualcomm Atheros type: USB driver: btusb bus ID: 1-4:2 
  chip ID: 0cf3:e301 
Drives:
  Local Storage: total: 238.47 GiB used: 10.91 GiB (4.6%) 
  ID-1: /dev/nvme0n1 vendor: Toshiba model: KXG50ZNV256G NVMe 256GB 
  size: 238.47 GiB speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: AADA4104 
  scheme: GPT 
Partition:
  ID-1: / size: 29.30 GiB used: 10.00 GiB (34.1%) fs: btrfs 
  dev: /dev/nvme0n1p1 
  ID-2: /home size: 189.41 GiB used: 930.0 MiB (0.5%) fs: ext4 
  dev: /dev/dm-0 
  ID-3: swap-1 size: 15.62 GiB used: 0 KiB (0.0%) fs: swap 
  dev: /dev/nvme0n1p2 
Sensors:
  System Temperatures: cpu: 47.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 2501 fan-2: 2520 
Info:
  Processes: 309 Uptime: 4m Memory: 15.31 GiB used: 804.4 MiB (5.1%) 
  Init: systemd v: 244 Compilers: gcc: 9.3.0 Shell: zsh v: 5.8 
  running in: xfce4-terminal inxi: 3.0.37 

Thanks a lot for reading this. I've been dealing with this for a while and I apologize if I could've condensed this better.

So if I understand correctly, your issue is that Manjaro (not Arch) is a rolling release distro and if you are not at home with your laptop, and an update becomes available, and that update breaks your laptop for some reason, you cannot roll back to a previous stable state ?

Not exactly, I use BTRFS with Timeshift so technically I could. However, this still should only be a last resort, not a common practice.

Then since you have BTRFS and Timeshift you are covered. Is it the size of the updates ?

Sort of, but again it's not always reliable since I'll still have to eventually fix the issue.

What's not reliable?

I shouldn't say reliable. Rather, it's putting a band aid over the problem rather than fixing it, so to speak. I still have to stop what I'm doing, restore the backup, reboot my machine, enter my encryption password, enter my user password, then restart all my programs. Then, I'll still have to go out of my way to troubleshoot. It just doesn't seem right.

This is an easy answer - although you won't like it.

Manjaro is solid and very rarely updates makes a fuzz. Yes you hear about it all the time - read about it everywhere - but the truth is - it is all about what you install and tinker with - and the knowledge you are willing to gain.

Don't decouple your brain - thinking everything is dandy - Manjaro cannot possibly ensure updates work equally good on every combination of hardware/software/custom packages available.

Know this - you are not forced to update if you are satisfied with the way it works - but it is your responsibility if an update stalls your system.

If you want to make sure Manjaro updates without issues you need to learn a few things.

  1. AUR packages - always assume AUR packages needs rebuild on updates
  2. Before updating - you should consider which AUR packages you have on the system - verify it is safe to update.
  3. Consider updating the system using the console - (not just a virtual terminal)
    • If the update is huge
    • Contains important system packages like kernel, systemd, Xorg, graphic drivers etc.
  4. Either edit the grub command line (add the number 3 to end of the line) or switch to console using Ctrl+Alt+F4.
  5. Ensure you have a ventoy formatted disk with a recent Manjaro ISO file (community repo)
1 Like

I appreciate the advice, although I generally do all of the above. My problem is that I still do not ALWAYS have a USB drive with me, with or without ventoy. My problem isn't specifically with Manjaro ITSELF, rather that I am forced to use it despite my problems with it.

I follow all of these practices on my desktop which always has an internet connection and is in the same room as a keep my USB drives and other recovery tools. And yet, I still have to manually clear the Pacman cache or rebuild the initramfs from a live USB once in a while. My point is that I don't want to do "maintenance" on my laptop.

Again, I do appreciate all the help you gave. But I wouldn't say it is relevant to my situation.

So don't do an update in those situations.

Create a pacman hook to do this automatically.

Choose a distro with an update policy that fits your usage pattern.

Choose a distro with an update policy that fits your usage pattern.

That is exactly where my problem is: There isn't one. I don't mean to be rude, but you might've missed that part in my original post.

Oh, I got that. Despite the many words used in the first post it boils down to :point_up: for you. But if you're using a rolling distro you're in for some "maintenance" - there is no way around it. Same as washing will get you wet..
In some time all those point release distros will have caught up und you can switch to one of them.

2 Likes

Yeah I guess so. Thanks for replying, though!

pclinuxos and openmandriva are similar to mageia but have wholly separate repos so the packages their may be newer(or older).

You could use something like mx-linux and then enable the testing repo

Other than that, you could always use a static distro with older packages and build the packages you need to be newer yourself.

3 Likes

Other than that, you could always use a static distro with older packages and build the packages you need to be newer yourself.

That's what I think I might do. Thanks for the advice

1 Like

Didn't think of that one - but depending on the packages this could be more trouble than following manjaro stable :slight_smile:

Forum kindly sponsored by