#manjaro

mc@iviv.hu

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

danie10@squeet.me

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

danie10@squeet.me

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

bliter@diaspora-fr.org

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

mauve75@diaspora-fr.org

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

daniel01@diasp.org

And eventually RH PR where able to get the hands on also over #LateNightLinux which has been historically and geographically an #Ubuntu bastion... I am concerned about this trend, #LNL is one of my favorite podcast it would be a shame stopping to listen it because the continuous RH PR, this is the reason why I stopped to listen #destinationLinux

I understood it is also a manifestation that Ubuntu is everyday lesser relevant on the #LinuxDesktop, now there is the rising up of the worst: #Manjaro ; #Fedora #SilverBlue ; #Flatpak etc...

Not that I really care about all this crap I already left the Linux space but this RH/Linux mono-culture is boring, #GNU/Linux was cool also because diversity, heterogeneity, variety and so on...

#freesoftware #opensource #linuxPodcast

polecanoe@sysad.org

Hey everyone, I’m #newhere. I’m interested in #artix, #artixlinux, #manjaro, #mxlinux, #peace, and #water. . Moving over here from Joindiaspora due to it's planned closure.

I work for clean water. I speak truth to power, I grow and breed garlic chilis tomatoes, berries, greens. I drink oolong tea but not alcohol. I pole my canoe upstream in class 2+ rivers. I hike and ride my bicycle. I practice fearlessness and like to read about self awareness and spirituality, particularly Pema Chodron. I value new and old friends and consider my spirituality to be love-based. I am inspired by live music singer-songwriters and small venues. I’m trying to learn to play guitar. I live in northwestern Connecticut. I’m single male heterosexual. I enjoy nature especially in aquatic settings: fish birds etc. Efficiency, simplicity, humility sustainability honesty impress me ,