[Testing Update] 2018-11-28 - Kernels, Plasma5, Cinnamon, Deepin, XFCE, Firefox, Systemd

update
testing

#8

No error in update with gnome !

But still have little heating problem :confused:


#10

fist attempt to update stalled so i had to cancel the install.
the second attempt as follows.
Transaction Successfully finished apart from pamac gave the following warning/issue:

“Warning: failed retrieving file ‘linux419-headers-4.19.5-2-x86_64.pkg.tar.xz’ from ftp.cc.uoc.gr : The requested URL returned error: 404 Not Found”


#11

for those who got no updates or failed part way through, before starting an update always check on the mirror-check service link to see if the servers are actually synchronised.


#12

My update on 2018-11-27 (pacman -Syyuu) seemed to go well until I rebooted. Cinnamon crashed immediately and I had a degraded desktop without my app menu. However, today I was able to update (pacman -Syu) and reboot from a terminal. After updating some Cinnamon applets, everything is fine again. Great Job, devs! (i7-7500U Dell laptop, not my baytrail x32, which is also fine at the moment)


#13

Don’t use this mirror, use the ones from Germany as they get updated faster. Greek here


#14

Good update. No problems here.

System:    Kernel: 4.19.5-2-MANJARO x86_64 bits: 64 Desktop: KDE Plasma 5.14.4 Distro: Manjaro Linux 
Machine:   Type: Desktop Mobo: ASUSTeK model: H170M-PLUS v: Rev X.0x serial: <root required> UEFI: American Megatrends v: 3805 
           date: 05/16/2018 
CPU:       Topology: Quad Core model: Intel Core i5-6600K bits: 64 type: MCP L2 cache: 6144 KiB 
           Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 
Graphics:  Device-1: Intel HD Graphics 530 driver: i915 v: kernel 
           Display: x11 server: X.Org 1.20.3 driver: intel unloaded: modesetting resolution: 1920x1080~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) v: 4.5 Mesa 18.2.5 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k4.19.5-2-MANJARO 
Network:   Device-1: Intel Ethernet I219-V driver: e1000e 
           IF: eth0 state: up speed: 1000 Mbps duplex: full
Drives:    Local Storage: total: 232.89 GiB used: 157.42 GiB (67.6%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB 
Partition: ID-1: / size: 227.94 GiB used: 157.42 GiB (69.1%) fs: ext4 dev: /dev/sda2 
Info:      Uptime: 12m Memory: 7.65 GiB used: 3.49 GiB (45.7%) Shell: bash inxi: 3.0.27

#15

Following this update the sandbox error came back in brave.

sudo sysctl kernel.unprivileged_userns_clone=1’ sorted the problem.

is there a way to fix this permanently from the terminal?


#16

Yes, should be:
sudo echo ‘kernel.unprivileged_userns_clone=1’ > /etc/sysctl.d/00-local-userns.conf


#17

Thanks EDO,
i am sure i tried that previously but got an error. it worked today so maybe i made a syntax error.


#18

updated my vm with yakuake - no problems - manjaro KDE


#19

all good on kde


#20

Ooh, Scheduler has now changed with this kernel bump.

[kdemeoz@Manjaro18KDE_beta_VM ~]$ sudo tlp-stat -d|grep Sch
[sudo] password for kdemeoz: 
  Scheduler = mq-deadline

[kdemeoz@Manjaro18KDE_beta_VM ~]$ uname -a
Linux Manjaro18KDE_beta_VM 4.19.5-2-MANJARO #1 SMP PREEMPT Wed Nov 28 18:19:10 UTC 2018 x86_64 GNU/Linux
[kdemeoz@Manjaro18KDE_beta_VM ~]$

With 4.19.4 & below it was Scheduler = cfq


[Testing Update] 2018-12-09 - Kernels, Nvidia, Matcha, Pamac, Thunderbird, Wine
#21

Hello, block multi-queue (blk-mq) mode is enabled in 4.19.5-2.

cfq is a single queue scheduler so it is not available in this mode.

Testing…

$ cat /sys/block/sd*/queue/scheduler
[mq-deadline] kyber bfq none

To get back cfq

  1. Disable blk-mq mode in grub boot option.
    GRUB_CMDLINE_LINUX_DEFAULT="quiet scsi_mod.use_blk_mq=0"
  2. update-grub
  3. Reboot.

[Stable Update] 2018-12-04 - Systemd
#22

Thanks for the interesting info. Just to clarify. my post was not intended to complain, nor to intimate any problem per se, but instead only to inform other Manjaroos if they’d not otherwise been aware of this recent change.

The context for my interest in this is that, as i’d previously posted elsewhere in the forum, my Tower had experienced a series of nasty total freezes over months, which defied all diagnostic attempts to find root cause, until i discovered that it was using BFQ. I was going to then change it myself to CFQ but happily Phil at that time independently decided to provide CFQ as default in an update… & all my freezes immediately stopped. Hence with every 4.19.x update since then i have rechecked to see if it was still CFQ, which it was. I’ve been dreading a possible return to BFQ. Thus yesterday’s different change surprised me. That’s only in my Testing VMs, but obviously it will soon come to my Stable real Manjaroos… so i shall be a bit nervous to see if the freezes come back then or not.

It had not only been me making older posts about schedulers & concern about BFQ, so i hoped my post today might be of interest also to those Manjaroos.


#23

Well, cfq or bfq-sq is still better for systems with HDD’s. blk-mq mode has no real-world benefit for people still using HDD’s as far as I know.

Also, mq-deadline is not the best scheduler for rotational disks. The user gives up a lot of system response when writing non-trivial amounts of data to HDD. This is not good for workstations.

Users should not rely on these I/O scheduler defaults during the transition to blk-mq. There is much variation in real-world performance between different modes.


#24

In no way do i dismiss legitimate concerns like that. However, in order of priority i rate my Tower NOT freezing as being #1, then if that requirement is met, i’m happy to contemplate viable opportunities for performance improvements. My Tower has Manjaro & /home on SSD, & some other data + all my VMs on HDD… fyi.


#25

FWIW, I use mq-deadline on my SSD’s, and bfq-mq on my spinner; haven’t had any issues…


#26

Also here:

right click on the green info star/ Pamac/Updates.
is leading to udeterministic freezes and the cpu is running hot with 94 - 100% cpu-usage.
(e.g. 1 of 4 rightclicks/pamac/updates is freezing)
as found in:


#27

Receiving this still, yet rolling back to stable removes it.

Nov 30 22:59:01 xmg systemd[1]: Stopping User Manager for UID 992...
Nov 30 22:59:01 xmg systemd[2870]: Stopping D-Bus User Message Bus...
Nov 30 22:59:01 xmg systemd[2870]: Stopped target Default.
Nov 30 22:59:01 xmg systemd[2870]: Stopped D-Bus User Message Bus.
Nov 30 22:59:01 xmg systemd[2870]: Stopped target Basic System.
Nov 30 22:59:01 xmg systemd[2870]: Stopped target Timers.
Nov 30 22:59:01 xmg systemd[2870]: Stopped target Paths.
Nov 30 22:59:01 xmg systemd[2870]: Stopped target Sockets.
Nov 30 22:59:01 xmg systemd[2870]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Nov 30 22:59:01 xmg systemd[2870]: Closed GnuPG network certificate management daemon.
Nov 30 22:59:01 xmg systemd[2870]: Closed Sound System.
Nov 30 22:59:01 xmg systemd[2870]: Closed p11-kit server.
Nov 30 22:59:01 xmg systemd[2870]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Nov 30 22:59:01 xmg systemd[2870]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Nov 30 22:59:01 xmg systemd[2870]: Closed GnuPG cryptographic agent and passphrase cache.
Nov 30 22:59:01 xmg systemd[2870]: Closed D-Bus User Message Bus Socket.
Nov 30 22:59:01 xmg systemd[2870]: Reached target Shutdown.
Nov 30 22:59:01 xmg systemd[2870]: Starting Exit the Session...
Nov 30 22:59:01 xmg systemd[2871]: pam_unix(systemd-user:session): session closed for user sddm
Nov 30 22:59:01 xmg systemd[1]: Stopped User Manager for UID 992.
Nov 30 22:59:01 xmg systemd[1]: Stopping User Runtime Directory /run/user/992...
Nov 30 22:59:01 xmg systemd[1]: Stopped User Runtime Directory /run/user/992.
Nov 30 22:59:01 xmg systemd[1]: Removed slice User Slice of UID 992.

closed #28

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.