Please do yourself a favor and follow the REISUB llink/instructions I shared… you’re method of dealing with a “freeze” (likely just a desktop freeze, and not a full linux freeze) has a high probability for corrupting file/data/nodes/journal… fsck might have been able to help you so far, but there will be a day when the mkinitcpio images corrupt and your linux won’t boot; requiring you to learn about manjaro-chroot to sudo mkinitcpio -P and sudo update-grub to recover; or reinstall manjaro from scratch.
Update overall went fine.
Ran into one (irritating) issue regarding KDE font sizes and or icon spacing.
All desktop icons and KDE Widgets got displaced in width as though icon size was set to 9 or 10. Noticed this as my FF has a Window Rule to it to a fixed width.
Checked Font config global size was set to 8, so nothing had changed.
Checked Desktop Settings Icons Label width was also still set to Narrow. Unless a narrower setting was removed, nothing got changed.
The size step though between font sizes 7 and 8 now seem much bigger compared to going from 9 > 8. From what I remember setting this up after the KDE6 update.
I think you should concentrate on the underlying issue - what causes the freeze.
The most common cause is when the system runs out of memory.
It is a common perception to not create swap on systems with a lot of memory. But a little swap is always better than none. See Swap - Manjaro for information on swap.
If you have no swap you will run into issues if an ill behaved application or an unlimited docker instance consumes memory with no where to offload memory not currently accessed. This will lead to the kernel OOM killer to randomly kill processes to release memory.
Doing updates using the Pamac GUI with AUR enabled is a known way to exhaust memory.
Even though the GUI may become unresponsive - usually switching to TTY will work - it may be slow to respond but usually it will switch.
If the freeze is during update - forcefully restarting the system is a really, really bad idea. Not only may you damage the filesystem but transactional hooks are also lost and your system may become inoperable.
If the freeze is not during an update switch to TTY, login and restart userspace
systemctl soft-reboot
Then proceed to add swapspace as described in the wiki.
Just to let you know, still useful.
I’ve tried to change values to =1 but plasma doesn’t appears. I have had to write back values to =0
I’m using DELL G7 7700 with hybrid Intel/Nvidia GPU
inxi -G ✔
Graphics:
Device-1: Intel CometLake-H GT2 [UHD Graphics] driver: i915 v: kernel
Device-2: NVIDIA TU106M [GeForce RTX 2060 Mobile] driver: nvidia
Updated, everything went smoothly.
However I noticed this output
==> WARNING: Deprecated option 'ALL_microcode' found. Update '/etc/mkinitcpio.d/linux67.preset' to use the 'microcode' hook instead.
-> -k /boot/vmlinuz-6.7-x86_64 -g /boot/initramfs-6.7-x86_64.img
==> ERROR: '/lib/modules/6.7.12-1-MANJARO' is not a valid kernel module directory
==> Building image from preset: /etc/mkinitcpio.d/linux67.preset: 'fallback'
==> Using default configuration file: '/etc/mkinitcpio.conf'
==> WARNING: Deprecated option 'ALL_microcode' found. Update '/etc/mkinitcpio.d/linux67.preset' to use the 'microcode' hook instead.
-> -k /boot/vmlinuz-6.7-x86_64 -g /boot/initramfs-6.7-x86_64-fallback.img -S autodetect
==> ERROR: '/lib/modules/6.7.12-1-MANJARO' is not a valid kernel module directory
==> Building image from preset: /etc/mkinitcpio.d/linux68.preset: 'default'
Is this because of the old kernel modules?
Probably : 6.7 kernel has been deprecated some time ago. You should remove it from your configuration, and add another one like 6.9 or 6.6 that is LTS.
KNetWalk not work. Wine work with errors.
Linux 6.7 and 6.8 is no longer in the repo.
See → the wiki comment above
Linux 6.8 is still in repo !
As you can see it is going away - removed from unstable and in a short while … stable as well
$ mbn info linux68 -q
Branch : testing
Name : linux68
Version : 6.8.12-3
Repository : core
Build Date : Mon 10 Jun 2024 10:13:46
Packager : Manjaro Build Server <build@manjaro.org>
Branch : stable
Name : linux68
Version : 6.8.12-3
Repository : core
Build Date : Mon 10 Jun 2024 10:13:46
Packager : Manjaro Build Server <build@manjaro.org>
The new version of sudo seems to have a curious bug.
I have /root/bin added to $PATH in ~/.zshrc and ~/.profile for both the root user and my own user. And up until now I could run my pre/post upgrade backups
by running sudo system_backup. Since upgrading, I now get:
$ sudo system_backup
sudo: system_backup: command not found
It seems it’s not properly searching within the $PATH variable, because:
$ sudo echo $PATH
/home/tony/bin:/usr/lib/perl5/vendor_perl:/usr/local/bin:/home/tony/.local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/java/j2re1.4.0_01/bin:/sbin:/usr/sbin:/usr/local/sdk/tools:/usr/local/sdk/platform-tools:/root/bin
Gives the proper path for my own user, whereas:
sudo which system_backup
which: no system_backup in (/usr/local/sbin:/usr/local/bin:/usr/bin)
Clearly isn’t searching with the $PATH variable.
Downgrading sudo fixes the problem, thus confirming where the problem lies.
Have you merged sudoers with sudoers.pacnew file?
Sudoers.pacnew came with an “secure_path” variable uncommented (“Uncomment to use a hard-coded PATH instead of the user’s to find commands”). Can this be the cause of your issue?
4 Likes
AHA!
I’d never edited the sudoers file, so it just went ahead and over-wrote it. Commenting that line out solved the problem.
Thanks!
4 Likes
One issue so far: amule crashes (see below), more or less a standard Xfce installation.
type or paste code here2024-07-30 18:39:54: amuleAppCommon.cpp(335): Initialising aMule GIT compiled with wxGTK2 v3.2.5 and Boost 1.83 (Debugging) (Snapshot: rev. 2.3.3)
2024-07-30 18:39:54: amuleAppCommon.cpp(382): Checking if there is an instance already running...
2024-07-30 18:39:54: amuleAppCommon.cpp(413): No other instances are running.
2024-07-30 18:39:54: ListenSocket.cpp(67): ListenSocket: OK
Assertion failed: /usr/src/debug/wxwidgets/wxWidgets/src/common/sizer.cpp:DoInsert:2269: Assertion 'CheckSizerFlags(!((flags) & (wxALIGN_CENTRE_VERTICAL)))' failed. wxALIGN_CENTRE_VERTICAL will be ignored in this sizer: only horizontal alignment flags can be used in vertical sizers
DO NOT PANIC !!
If you're an end user running a program not developed by you, please ignore this message, it is harmless, and please try reporting the problem to the program developers.
You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to suppress all such checks when running this program.
If you're the developer, simply remove this flag from your code to avoid getting this message. You can also call wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, but this is strongly not recommended.
Backtrace follows:
[3] wxOnAssert(char const*, int, char const*, char const*, wxString const&) in /usr/lib/libwx_baseu-3.2.so.0[0x7f3bd2639abe]
[4] wxBoxSizer::DoInsert(unsigned long, wxSizerItem*) in /usr/lib/libwx_gtk3u_core-3.2.so.0[0x7f3bd2bdc5a0]
[5] ?? in amule[0x56211c339f34]
[6] ?? in amule[0x56211c2f2003]
[7] ?? in amule[0x56211c19fcf6]
[8] ?? in amule[0x56211c1a0190]
[9] ?? in amule[0x56211c0e43a1]
[10] ?? in amule[0x56211c19eb8e]
[11] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-3.2.so.0[0x7f3bd26a6222]
[12] ?? in amule[0x56211c04fd29]
[13] ?? in /usr/lib/libc.so.6[0x7f3bd204dc88]
[14] __libc_start_main in /usr/lib/libc.so.6[0x7f3bd204dd4c]
[15] ?? in amule[0x56211c061375]
Abgebrochen (Speicherabzug geschrieben)
1 Like
thanks for the fast reply. I have the version 2.3.3.8 from stable, and using the “export WX…” it runs again. Now i have to figure out how to put this in the launcher entry. Maybe a wrapper script.
HP
1 Like
(It’s much easier the second option: downloading only 2.3.3-9 amule package and install it. Works fine.)
1 Like
Lost function keys to change brightness, volume, etc. Completely supported before.
Noticed the 6.9 kernel will be EOL at some point like you said in the announcements. Why bake a 6.9 ISO and no 6.10 ?
No, the 6.8 will soon be EOL. The 6.9 is still here for a moment. The 6.10 seems a bit “experimental” at least for the latest hardwares. You should have a 6.6 that is LTS, as a backup in case od problem with a newest kernel.
1 Like