1 Persons are tagged with #manjaro

#manjaro

danie10@squeet.me
Danie

Manjaro’s Plasma 6 update has gone globally live today

Manjaro Linux info window showing the Plasma version as 6.0.
This was a major update from Plasma 5.27 to Plasma 6.0, but also along with just about everything else, and was a 6.8 GB download for me.

It all went off flawlessly apart from one applet I use for transparent folders, which seems to still only be a Plasma 5 applet. But that is not a major issue really. My desktop is slightly more responsive now, and the compositor issue I had before has been sorted it (it used to create a 30 sec delay on some things like a rectangular screenshot) – so really happy about that.

I also had to readjust some window rules that I had set for my Conky window for position, transparency, etc but it was a minor issue where Plasma 5.x was not case-sensitive for Window names, so I just had to change ‘conky’ to ‘Conky’ with a capital C.

Looking forward to retrying Wayland again soon as well, as I suspect its random freezes were also related to that older Nvidia driver, which is now updated.

See forum.manjaro.org/t/stable-upd…
#Blog, #linux, #manjaro, #technology

One person like that
michi@f.praschnig.com
Michi

20jahre Linux-User

Ich habe gerade festgestellt, dass ich in diesem Jahr mein 20jähriges #Jubiliäum als reiner #Linuxuser feiern kann. Ich habe schon vorher immer wieder experimentiert, aber 2004 komplett umgestellt (ausser zum Gamen gibts noch eine Windoofmaschine).
Und wisst ihr was? Abgesehen von einigen Hürden von Datenaustausch zwischen Programmen, habe ich die Umstellung wirklich nie bereut.
Meine Karriere ging von #SuseLinux, über #fedora, #Ubuntu, #gentoo zu #sabayon. Und als dieses vor ein paar Jahren aufgegeben wurde, wechselte ich zu #Manjaro und bin hier sehr glücklich. Die beiden Server laufen auf Ubuntu.

6 Likes
5 Comments
1 Shares
One person like that
8 Comments
1 Shares
mc@iviv.hu
mc

A #Linux-distro-a-day keeps the problems away and you don’t have to pay.

#linux #distros #my-selection

#INDEX

#4MLinux https://iviv.hu/posts/1579981

#Academix https://iviv.hu/posts/1581092

#antiX https://iviv.hu/posts/1582700

#Artix https://iviv.hu/posts/1584361

#AVLinux https://iviv.hu/posts/1585659

#Batocera https://iviv.hu/posts/1587077

#CROWZ https://iviv.hu/posts/1588676

#Cruncbangplusplus https://iviv.hu/posts/1590164

#CachyOS https://iviv.hu/posts/1592431

#Diamond https://iviv.hu/posts/1593569

#DietPi https://iviv.hu/posts/1595173

#DragonFlyBSD https://iviv.hu/posts/1596570

#Dragora https://iviv.hu/posts/1597447

#Exe-GnuLinux https://iviv.hu/posts/1599465

#Finnix https://iviv.hu/posts/1601139

#FreedomBox https://iviv.hu/posts/1602692

#GeckoLinux https://iviv.hu/posts/1605606

#Grml-LiveLinux https://iviv.hu/posts/1606978

#Guix-System https://iviv.hu/posts/1608320

#Haiku-OS https://iviv.hu/posts/1610171

#HardenedBSD https://iviv.hu/posts/1611525

#Kaisen https://iviv.hu/posts/1614979

#Karoshi https://iviv.hu/posts/1616490

#FreedomBox https://iviv.hu/posts/1617470

#Kwort-Linux https://iviv.hu/posts/1617920

#Manjaro https://iviv.hu/posts/1619475

#Murena-eOS https://iviv.hu/posts/1621997

#Navy-Linux https://iviv.hu/posts/1624130

#NetBSD https://iviv.hu/posts/1625881

#Netrunner https://iviv.hu/posts/1627259

#Obarun https://iviv.hu/posts/1630119

#OpenBSD https://iviv.hu/posts/1631492

#openmamba https://iviv.hu/posts/1634684

#OSGeoLive https://iviv.hu/posts/1636276

#OSMC https://iviv.hu/posts/1637728

#Parabola https://iviv.hu/posts/1639178

#Pearl-Linux-OS https://iviv.hu/posts/1640627

#PopOS https://iviv.hu/posts/1642087

#Porteus https://iviv.hu/posts/1643480

#PrimTux https://iviv.hu/posts/1645838

#Q4OS https://iviv.hu/posts/1647694

#RebeccaBlackOS https://iviv.hu/posts/1648947

#Redcore-Linux https://iviv.hu/posts/1650279

#Redo-Rescue https://iviv.hu/posts/1651483

#Salix https://iviv.hu/posts/1654392

#SELKS https://iviv.hu/posts/1655733

#Septor https://iviv.hu/posts/1657289

#Slint https://iviv.hu/posts/1659912

#SliTaz https://iviv.hu/posts/1661392

#Solus https://iviv.hu/posts/1662843

#SolydXK https://iviv.hu/posts/1664296

#Trisquel https://iviv.hu/posts/1665975

#Ufficio-Zero https://iviv.hu/posts/1667306

#Vanilla-OS https://iviv.hu/posts/1668744

#Voyager https://iviv.hu/posts/1670173

#Whonix https://iviv.hu/posts/1671604

#XigmaNAS https://iviv.hu/posts/1673122

#Xubuntu https://iviv.hu/posts/1674647

#MX-Linux https://iviv.hu/posts/1676135

4 Likes
3 Comments
danie10@squeet.me
Danie

Finally got Timeshift on Linux to do a system restore when I really needed it

System dialogue screen showing restore progress
I’ve had issues in the past when testing out restores with Timeshift. But today I really needed it as I did some over-aggressive pacman optimisations yesterday (mass deleting circular dependencies was not a good idea) and my system was spitting out SSL errors and the web browser could not even reach websites.

So no choice today but to face Timeshift restore. I did the whole chroot thing from a live CD but for some reason Timeshift –restore on the command line kept saying no snapshots found on the backup drive. I also could not list any files as the mount was not being seen.

So I backtracked and stuck with the plain manjaro-chroot, and saw it definitely mounted the partitions needed (but still gave an error mounting the MacOS partition (which was the trigger for my next step).

This time I did not run Timeshift from the command line where the chroot was active. I ran Timeshift from the menu for the GUI version. But again it said can’t mount partitions. Something said to me, try changing that MacOS mount to leave as root (I was not going to use it anyway), and bang it started checking the backup files in the snapshot. After that it went through fine and restored all the system files back to 13:00 yesterday. Did a reboot, and all up and running.

This post is really to remind me again next time what to look at, and serves as a reminder to anyone else using Linux to remember to setup Timeshift and left it do it’s daily snapshots of all the system files. And of course, be very wary of any mass deletions with pacman.
#Blog, #linux, #manjaro, #opensource, #technology, #Timeshift

2 Likes
7 Comments
danie10@squeet.me
Danie

After many months, I seem to have solved my very long boot up times on Manjaro KDE

Terminal screen showing text 'task blocked more than 120 seconds'
The last many months I’ve been struggling with having a boot up time of a good 10 – 15 minutes with Manjaro KDE. As this is a rolling distro, my configs are many years old as I don’t do refresh installs every major release, and there have also been many modbus writes made to the kernel for various hardware I’ve bought over the years. So, the login screen would appear fairly quickly, but the KDE desktop only started responding efficiently after 15 minutes or so (after I’d gone to make a cup of coffee).

I won’t go through all the fixes I’ve tried as there are many, including delaying auto start apps, the usual cleaning of cache files, build files, trying ZRAM, etc.

Some really useful commands that helped me were:
* systemd-analyze blame – to see what affects the desktop startup times.
* systemd-analyze blame –user – this was a new one today I tried and it did indicate the app Keybase was causing long delays, so I did remove that app today.
* journalctl -b -p err – this is a good one to show systemd boot related issues, and it for example showed if my USB headphones adaptor was plugged in without the headphones connected, it spend time trying to find them.

I had really eliminated most issues, but one thing remaining were a few kernel messages moaning about a task that had been blocked for more than 122 seconds. The task was sometimes different, and although speeds were OK after the boot process finished, I’d see some fresh errors reported about tasks hanging for over 122 seconds, such as ‘kernel: INFO: task APEX_CONTEXT_WO:2401 blocked for more than 122 seconds’.

But today was a GOOD day as my long-lost parcel turned up at the SA Post Office (no notification of course sent to me), so I thought I’d spin the wheel of fortune one more time, and I found the linked article below.

So, after trying this out, the reboot was much quicker. The desktop was responding within a minute after login, and I even noticed that opening apps, as well as browser tabs, was also a bit snappier. I’ve done two reboots now, and it really does seem to have sorted it out.

The explanation, especially for those who have a system with a lot of RAM (I have 32 GB of RAM): This is a known bug. By default, Linux uses up to 40% of the available memory for file system caching. After this mark has been reached, the file system flushes all outstanding data to disk, causing all following IOs going synchronous. For flushing out this data to disk this there is a time limit of 120 seconds by default. In the case here, the IO subsystem is not fast enough to flush the data within 120 seconds. This especially happens on systems with a lot of memory.

Essentially the system is waiting way too long when some tasks don’t respond, so it seems to need a quicker break out, and systems with more RAM have not hit the 40% threshold. It essentially involved editing the sysctl.conf file and adding two lines to clean up these wait states:
sudo nano/etc/sysctl.conf
Add these two lines at the end of that file, save, and reboot:
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
But yes, I’m not sure why Linux does not lower that flush threshold if it sees the RAM is more. Maybe it did and my older install did not get some updated config files.

See https://www.blackmoreops.com/2014/09/22/linux-kernel-panic-issue-fix-hung_task_timeout_secs-blocked-120-seconds-problem/
#Blog, #bootup, #KDE, #linux, #manjaro, #technology

7 Likes
3 Comments
14 Likes
3 Shares
bliter@diaspora-fr.org
Bliter Underground 🇫🇷 ☠ ♫ ☯ ☮ ♽

Peut-on #jouer sous #Linux ? - #LesDocs

Je lance les #jeux suivants sous Linux #Manjaro :

Jeux natifs Linux :
- #LTris
- #Foobillard

Jeux exécutables sous #Windows via #Wine :
- #SimCity 4
- #Syberia (Benoit Sokal)
- #Warblade

Jeux sous émulateur #ScummVM :
- Blade Runner

Jeux via #Steam :
- Goat Simulator
- Life is strange
- Elite Dangerous
- Stardew Valley
- Firewatch
- Cyberpunk 2077

Via #GOG
- Exhumed (Powerslave)

Via Itch.io
- Steel Heroes

https://www.youtube.com/watch?v=1URXGV0SfPQ
#jeuxvideo #games #videogame

2 Likes
14 Comments
mauve75@diaspora-fr.org
M V

Putting an AMD Ryzen based HP x360 Envy (13-ar0xxx) into legacy S3 suspend mode

#Linux #Manjaro #AMD #Ryzen #x360 #13ar0xxx #s2idle #s0ix #s3 #deepsleep #acpi
WARNING : This tutorial is specific to that exact computer model, but the general idea may help debug other systems.
So, to whom may find that tutorial useful …
Context :
I have a 2020 HP X360 Envy 13-ar0xxx (Ryzen 7 3700U based, nothing fancy but nice hardware) ; bios version F.25 dated 04/2022
The darn thing has never been able to sleep under Linux because HP screwed buyers by only allowing the s2idle method to put the computer into sleep mode, and that method is broken on AMD Ryzen based platforms. Work is being done to support s2idle in kernel, but at a glacially slow pace.
HP refuses to acknowledge the problem (unlike Dell or Lenovo) and locked the AMI Bios option to switch between S2idle and the more common S3 (deep sleep) method. Thankfully, hibernation has always worked and the SSD is fast enough it’s not too painful. But. But it’s MY computer and I’m not going to be told what I can, can’t or should do.

After months of trying every “legal” way to make it happen without success, I finally (thanks to a bout of COVID) took some days to stick my greasy fingers into the root cause of the problem : ACPI tables.

 First you need to install the acpi-tools. With Manjaro, use snap :

https://snapcraft.io/install/acpi-tools/manjaro

- create a work directory and place yourself inside that directory

- run : 
acpi-tools.acpidump -o tables 
to create a file with the currently running tables then
acpi-tools.acpixtract -a tables 
to extract the individual tables (we need both FACP and DSDT tables)

- FACP :
acpi-tools.iasl -d facp.dat to disassemble the FACP table
edit facp.dsl
increase the “Oem Revision” field at the top by 1
set the “Hardware Reduced (V5)” field to 0
acpi-tools.iasl -sa facp.dsl to assemble your modified table

- DSDT :
acpi-tools.iasl -e ssdt*.dat -d dsdt.dat
(if you don’t xref ssdt tables, you won’t be able to recompile dsdt)
edit dsdt.dsl
add 1 to the last parameter of the DefinitionBlock() line - that’s the OEM version number
search for XS3 ; replace with _S3 (one occurence)
acpi-tools.iasl -sa dsdt.dsl to assemble your modified table

- Make the following folder structure: payload/kernel/firmware/acpi/
In the acpi/ folder add your compiled facp.aml and dsdt.aml
In the payload/ folder, run:
find kernel | cpio -H newc --create > overrideacpi.img

- Move the resulting overrideacpi.img to your /boot folder
Edit /etc/default/grub
Add mem_sleep_default=deep as the last parameter of the line GRUB_CMDLINE_DEFAULT
(like so : ) GRUB_CMDLINE_DEFAULT="... mem_sleep_default=deep"
Create a new line just below like so :
GRUB_EARLY_INITRD_LINUX_CUSTOM="overrideacpi.img"
Save /etc/default/grub
Update grub as usual : sudo update-grub

- Finally reboot. Check in dmesg your modified ACPI tables are indeed loaded, and do a :
cat /sys/power/mem_sleep, it should now return :
s2idle [deep]

Try putting the computer to sleep and enjoy the sound of silence… and be amazed when it wakes up at the slightest touch of the space bar !

last words : I haven’t tested all the the scenarios where this could go wrong (plugging or unplugging AC power while the computer is suspended, for instance), but it seems to do the job so far. In S3 suspend mode, the computer draws less than 1% of the battery per hour.

This solution was heavily inspired by the work of Jordan Maris : https://gitlab.freedesktop.org/drm/amd/-/issues/1230#note_580057

Install acpi-tools on Manjaro Linux using the Snap Store | Snapcraft

Get the latest version of acpi-tools for on Manjaro Linux - ACPICA tools