There was a suggestion to re-integrate AppArmor back into Manjaro. Followed config changes are needed:

 CONFIG_SECURITY_APPARMOR=y
 CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
 CONFIG_DEFAULT_SECURITY_APPARMOR=y
 CONFIG_AUDIT=y

These were the reasons why we had removed it:

Effectively, disabling them was done because tomoyo/selinux/apparmor/others aren't officially supported (the user space packages required are only available in the AUR, and a large amount of user configuration is necessary for them to be of any use anyway).

It was also done to get rid of CONFIG_AUDIT, which has a high cost. It's the source of a significant number of kernel vulnerabilities, fills the kernel log with nonsense by default and forces all system calls down the slow path by default which has a high performance cost.

It produces several errors when building iso.

warning: directory permissions differ on /build/manjaro-tools/buildiso/net/x86_64/net-image/etc/polkit-1/rules.d/
filesystem: 700  package: 750

@philmmanjaro Please add this patch: http://permalink.gmane.org/gmane.linux.kernel.mmc/28281 to manjaro kernels. Some netbooks have only mmc memory, without this patch installing manjaro is not possible.

best regards,

vincent

Sorry guys, I am not sure if this is the right place to put this feature/support request

I have experienced extreme fluctuations in battery performance in linux41 series but did not have the time to investigate it properly at the time.

Unfortunately I only now have 4.1.11+ kernels backed up due to having run paccache. So I decided to go through this repo and rebuild all the others I used, starting from 4.1.3-2.

However, I soon discovered that there are a few commits that change PKGBUILD or other files without changing pkgrel. This really hurts reproducibility.

Is there a way to match exact commit to a kernel build that reached manjaro stable at the time? Or alternatively is there a 'downgrade mirror' for manjaro kernels I could use?

Thanks

Beginning with linux41 on i686 boot up crashes - kernel panic :

Since Canonical doesn't support this kernel anymore, we also should drop it ...

Kamal Mostafa
I am announcing the release of the Linux 3.13.11-ckt39 kernel.
Note that this is the FINAL 3.13.y-ckt RELEASE in this series.

Recent Linux kernels, pushed to the stable branch within the last update, suffered from a bug that can cause data corruption on file systems mounted with the discard option and residing on software RAID 0 arrays. Even if discard is not specified, the fstrim command can also trigger this bug. (If you do not use software RAID 0 or the discard option, then this issue does not affect you.)

Due to the nature of the bug, however, it is likely that data corruption has already occurred on systems running the aforementioned kernels. It is strongly advised to verify the integrity of affected file systems using fsck and/or restore their data from known good backups.

We will soon notify you, when we fixed this issue.

Please make manjaro-system openrc compatible at the haveged call.

https://forum.manjaro.org/index.php?topic=19525.msg177055#msg177055

Initial post contains the changes necessary if accepted.
It has certainly room for improvement to make the entire script aware of the init type.

As of now kernels lower than linux318 are not compatible to gcc 5.1.

Affected kernels:

• linux310
• linux312
• linux313 (not yet tested)
• linux314
• linux316

Common issues:

lib/mpi/generic_mpih-mul1.o: In function `mpihelp_add_1':
generic_mpih-mul1.c:(.text+0x0): multiple definition of `mpihelp_add_1'
lib/mpi/generic_mpih-lshift.o:generic_mpih-lshift.c:(.text+0x0): first defined here
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_add':
generic_mpih-mul1.c:(.text+0x70): multiple definition of `mpihelp_add'
lib/mpi/generic_mpih-lshift.o:generic_mpih-lshift.c:(.text+0x70): first defined here
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_sub_1':
generic_mpih-mul1.c:(.text+0x130): multiple definition of `mpihelp_sub_1'
lib/mpi/generic_mpih-lshift.o:generic_mpih-lshift.c:(.text+0x130): first defined here
lib/mpi/generic_mpih-mul1.o: In function `mpihelp_sub':
generic_mpih-mul1.c:(.text+0x1a0): multiple definition of `mpihelp_sub'
lib/mpi/generic_mpih-lshift.o:generic_mpih-lshift.c:(.text+0x1a0): first defined here

drivers/scsi/qla2xxx/qla_nx2.c:1541:1: error: static declaration of 'qla8044_need_reset_handler' follows non-static declaration
 qla8044_need_reset_handler(struct scsi_qla_host *vha)
 ^
In file included from drivers/scsi/qla2xxx/qla_def.h:3542:0,
                 from drivers/scsi/qla2xxx/qla_nx2.c:10:
drivers/scsi/qla2xxx/qla_gbl.h:732:20: note: previous declaration of 'qla8044_need_reset_handler' was here
 extern inline void qla8044_need_reset_handler(struct scsi_qla_host *vha);
                    ^
drivers/scsi/qla2xxx/qla_gbl.h:732:20: warning: inline function 'qla8044_need_reset_handler' declared but never defined
scripts/Makefile.build:308: recipe for target 'drivers/scsi/qla2xxx/qla_nx2.o' failed

drivers/staging/rtl8187se/r8180_wx.o: In function `ieee80211_increment_scans':
r8180_wx.c:(.text+0x1720): multiple definition of `ieee80211_increment_scans'
drivers/staging/rtl8187se/r8180_core.o:r8180_core.c:(.text+0x38c0): first defined here
drivers/staging/rtl8187se/r8180_wx.o: In function `ieee80211_get_scans':
r8180_wx.c:(.text+0x1730): multiple definition of `ieee80211_get_scans'
drivers/staging/rtl8187se/r8180_core.o:r8180_core.c:(.text+0x38d0): first defined here
drivers/staging/rtl8187se/r8180_rtl8225z2.o: In function `ieee80211_increment_scans':
r8180_rtl8225z2.c:(.text+0x570): multiple definition of `ieee80211_increment_scans'
drivers/staging/rtl8187se/r8180_core.o:r8180_core.c:(.text+0x38c0): first defined here

drivers/staging/rtl8192e/rtl8192e/r8192E_phy.o: In function `rtllib_increment_scans':
r8192E_phy.c:(.text+0x3f0): multiple definition of `rtllib_increment_scans'
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.o:r8192E_dev.c:(.text+0xd0): first defined here
drivers/staging/rtl8192e/rtl8192e/r8192E_phy.o: In function `rtllib_get_scans':
r8192E_phy.c:(.text+0x400): multiple definition of `rtllib_get_scans'
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.o:r8192E_dev.c:(.text+0xe0): first defined here

Downloaded the docker package from main repo's and it failed to run due to an issue with devicemapper not being able to attach a loopback device? Looked up docs and they suggest using overlay/overlay2 storage drivers, these are supposed to be available in the kernel though as you can see below that doesn't appeaer to be the case. Without a working storage driver I'm unable to use Docker.

$ sudo modprobe overlay
modprobe: FATAL: Module overlay not found in directory /lib/modules/4.8.4-1-MANJARO
$ sudo modprobe overlay2
modprobe: FATAL: Module overlay2 not found in directory /lib/modules/4.8.4-1-MANJARO
$ sudo modprobe overlayfs
modprobe: FATAL: Module overlayfs not found in directory /lib/modules/4.8.4-1-MANJARO

revert-intel-asoc.patch is no longer needed as CONFIG_DW_DMAC_CORE=y is set in current manjaro config (same in arch). Also it should now work even without this option set.

In any case this patch is now redundant and could be dropped.

arch/x86/built-in.o: In function `__apm_bios_call_simple':
apm_32.c:(.text+0x21963): undefined reference to `apm_bios_entry'
arch/x86/built-in.o: In function `__apm_bios_call':
apm_32.c:(.text+0x21a83): undefined reference to `apm_bios_entry'
Makefile:785: recipe for target 'vmlinux' failed

we have to check why that is ...

For anyone planning to use manjaro as a multi-user system, the access rights are way too permissive. Since all users share membership in the same default primary group "users", the current default umask value allows anyone to peek into anyone else's data.

My expectation was that personal data would be private by default. At this point, I've changed the situation on my box, but y'all may want to check, for instance, your .ssh and gnupg folder permissions.

Also, my expectation (coming from debian, as I do) was that each user would be assigned a 'personal group', instead of being lumped together with every other user by default.

Since I keep seeing this during upgrade

warning: manjaro-keyring: local (20151108-1) is newer than core (20150809-1)

I went to check what's going on with this pkg but I cannot see any commits since August and no hint of a version 20151108 anywhere.
In any case, do I downgrade?

For I2S broadwell audio interface (available in some laptops i.e. dell xps) snd-soc-sst-broadwell sound module is needed.

Unfortunately it isn't compiled by default in kernel >=4.5 (4.4 works fine) because of torvalds/linux@a92ea59.

To fix it, the following changes in kernel compile config is needed:
CONFIG_DW_DMAC=y
CONFIG_SND_SOC_INTEL_HASWELL_MACH=m
CONFIG_SND_SOC_INTEL_BROADWELL_MACH=m

For reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1317214
https://bugzilla.redhat.com/show_bug.cgi?id=1308792
https://bugs.archlinux.org/task/48936

Please apply this patches for linux44 series due major regressions:

• Revert patch mmc: sdhci: enable tuning for DDR50 due
  FS#47778 4.4.x sdhci regression
  
  patch -Rp1 -i "${srcdir}/0001-rev_mmc-sdhci-enable tuning_for_DDR50.patch"
  
  Patch code
• Applying patch base/platform: fix binding for drivers without probe callback for fix due
  FS#47805 4.4.x asus_laptop module causes a kernel panic
  
  Patch code
  
  
  Reference: FadeMind/archpkgbuilds@f85f374

@philmmanjaro

I applied them for linux-mainline (4.4) - build fine, kernel working as expexted.

Currently we have followed initramfs/vmlinuz structure:

initramfs-310-x86_64-fallback.img
initramfs-310-x86_64.img
initramfs-312-x86_64-fallback.img
initramfs-312-x86_64.img
initramfs-313-x86_64-fallback.img
initramfs-313-x86_64.img
initramfs-314-x86_64-fallback.img
initramfs-314-x86_64.img
initramfs-316-x86_64-fallback.img
initramfs-316-x86_64.img
initramfs-318-x86_64-fallback.img
initramfs-318-x86_64.img
initramfs-319-x86_64-fallback.img
initramfs-319-x86_64.img
initramfs-40-x86_64-fallback.img
initramfs-40-x86_64.img
intel-ucode.img
linux310-x86_64.kver
linux312-x86_64.kver
linux313-x86_64.kver
linux314-x86_64.kver
linux316-x86_64.kver
linux318-x86_64.kver
linux319-x86_64.kver
linux40-x86_64.kver
vmlinuz-310-x86_64
vmlinuz-312-x86_64
vmlinuz-313-x86_64
vmlinuz-314-x86_64
vmlinuz-316-x86_64
vmlinuz-318-x86_64
vmlinuz-319-x86_64
vmlinuz-40-x86_64

Since 40 is lower than for example 310, kernel 4.0 get noticed as oldest kernel installed. Therefor it will be listed last in grub.cfg on multible kernel installations. Moving to followed structure will fix this:

initramfs-3.10-x86_64-fallback.img
initramfs-3.10-x86_64.img
initramfs-3.12-x86_64-fallback.img
initramfs-3.12-x86_64.img
initramfs-3.13-x86_64-fallback.img
initramfs-3.13-x86_64.img
initramfs-3.14-x86_64-fallback.img
initramfs-3.14-x86_64.img
initramfs-3.16-x86_64-fallback.img
initramfs-3.16-x86_64.img
initramfs-3.18-x86_64-fallback.img
initramfs-3.18-x86_64.img
initramfs-3.19-x86_64-fallback.img
initramfs-3.19-x86_64.img
initramfs-4.0-x86_64-fallback.img
initramfs-4.0-x86_64.img
intel-ucode.img
linux310-x86_64.kver
linux312-x86_64.kver
linux313-x86_64.kver
linux314-x86_64.kver
linux316-x86_64.kver
linux318-x86_64.kver
linux319-x86_64.kver
linux40-x86_64.kver
vmlinuz-3.10-x86_64
vmlinuz-3.12-x86_64
vmlinuz-3.13-x86_64
vmlinuz-3.14-x86_64
vmlinuz-3.16-x86_64
vmlinuz-3.18-x86_64
vmlinuz-3.19-x86_64
vmlinuz-4.0-x86_64

Seems we have an issue due gcc 6.1 compiler to compile 3.16.35 (works with gcc5, though):

In file included from drivers/hv/hv_util.c:25:0:
include/linux/module.h:138:40: error: storage size of ‘__mod_vmbus__id_table_device_table’ isn’t known
   extern const struct type##_device_id __mod_##type##__##name##_device_table \
                                        ^
drivers/hv/hv_util.c:418:1: note: in expansion of macro ‘MODULE_DEVICE_TABLE’
 MODULE_DEVICE_TABLE(vmbus, id_table);
 ^~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:257: recipe for target 'drivers/hv/hv_util.o' failed
make[2]: *** [drivers/hv/hv_util.o] Error 1
scripts/Makefile.build:404: recipe for target 'drivers/hv' failed
make[1]: *** [drivers/hv] Error 2
make[1]: *** Waiting for unfinished jobs....

After reading a bit on the new pacman hooks, I think it enables new approach to manjaro-system?

If I understood correctly, the hooks are per transaction.
Could this solve some shortcommings with manjaro-system being upgraded first?
Could manjaro-system become (a) pacman hook(s)?

right now its not possible to install manjaro 16.06 to any computer with a GCN1.1 Card (Hawaii, Bonaire, Kaveri blah blah)
its because of our change to support those cards with AMDGPU.

now the installer -> mhwg defaults to AMDGPU and crashes because the experimental support dont work.

now my wich is to remove the IDs for all GCN 1.1 cards/APUs from mhwd-amdgpu prober. so that all thos cards will use "radeon"(xf86-video-ati) again and the amdgpu kernel module will not be loaded.

is there a list with those PCIIDs somewhere or do we have to collect them by ourself?

The affected PCI IDs are 0x6900, 0x6901, 0x6902, 0x6903, and 0x6907 for the Topaz/Iceland GPUs that are marked as experimental. However they are now defaulting to amdgpu which creates issues for our users. Using radeon would be better for them as of now.

Hi Guys!

First thanks for making the best Linux distro ever - Manjaro with Xfce!!!

I have a rather new NUC Intel Skull Canyon, and they have drivers for Ubuntu and Fedora, and also
all drivers are open source.

As a bleeding edge distro, I think that Manjaro shoud have this drivers.
https://01.org/linuxgraphics/blogs/vega/2016/released-intelr-graphics-update-tool-linux-os-v2.0.2

Currently Manjaro Xfce just says "unsupported controller" when trying to run LiveDVD.

Is this the best site to solve this bug? Or should this be directed towards ARCH repositories ?

I am willing to make a donation to get this done also. But dont know where would be the best place.

I also added this on stackoverflow:
http://stackoverflow.com/questions/39708312/manjaro-linux-how-to-get-it-working-on-intel-nuc-skull-canyon/39708821?noredirect=1#comment66724983_39708821

Thanks!

The packager was not set in the latest kernel builds.
The kernel packages show "unknown" packager.

Seems I found another kernel regression in two of the current point releases:

Two different kernels, same issue. Seems I've to check the patch set once more. Other kernels released on the same day are not affected.

We should think about when it will be best to drop this depreciated kernel series. There is no ESS kernel planned for it

It seems we have an issue regarding gcc61 as 3.18.x and 3.19.x won't compile due following error:

In file included from drivers/hid/hid-hyperv.c:16:0:
include/linux/module.h:138:40: error: storage size of ‘__mod_vmbus__id_table_device_table’ isn’t known
   extern const struct type##_device_id __mod_##type##__##name##_device_table \
                                        ^
drivers/hid/hid-hyperv.c:594:1: note: in expansion of macro ‘MODULE_DEVICE_TABLE’
 MODULE_DEVICE_TABLE(vmbus, id_table);
 ^~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:263: recipe for target 'drivers/hid/hid-hyperv.o' failed
make[2]: *** [drivers/hid/hid-hyperv.o] Error 1
scripts/Makefile.build:402: recipe for target 'drivers/hid' failed
make[1]: *** [drivers/hid] Error 2
make[1]: *** Waiting for unfinished jobs....

Should we replace those packages with the stable versions in testing and unstable until this issue is fixed?
https://forum.manjaro.org/index.php?topic=26301.msg223333#msg223333

Not sure what the correct repo is for this, unable to write a forum post about it as no matter how many times I've tried to get the verification e-mail(hotmail/outlook account) I fail to receive it(including spam/junk folder). It seems other users(some posted on manjaro subreddit) about this problem, outlook accounts don't receive the e-mails forums are sending at all.

I've been using QEMU/KVM via virt-manager to install and run VMs For some reason Manjaro boots but fails to get passed [ OK ] Started TLP system startup/shutdown. during preventing me from installing the various spins I've tried. Other distro's are fine so I'm not sure what's going on with Manjaro(my host is Manjaro KDE if that matters).

Any information I can provide to figure this out? I'd really like to use Manjaro via VMs managed by virt-manager(Q35 chipset).

Due issue AL#51818 and in general having most things done now with hooks if possible we also adopt for the function mkinitcpio to alpm hooks.

• linux310 (prepared with 3ddae15)
• linux312 (prepared with ad2f02c)
• linux316 (prepared with 5d28b8d)
• linux318 (prepared with eeb74a2)
• linux41 (prepared with a412a13)
• linux44 (prepared with 6b13c4c)
• linux48 (prepared with 0ac6a22)
• linux49 (prepared with 8d35e9f)

What diferencies has EXCATCLY the manjaro and arch kernels?

Replace in config file:

CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_MICROCODE_INTEL_EARLY is not set
# CONFIG_MICROCODE_AMD_EARLY is not set

for:

CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y

Seems with gcc 6.1 we face some issues: error: storage size of ‘__mod_x86cpu_device_table’ isn’t known

In file included from arch/x86/crypto/aesni-intel_glue.c:25:0:
include/linux/module.h:87:32: error: storage size of ‘__mod_x86cpu_device_table’ isn’t known
 extern const struct gtype##_id __mod_##gtype##_table  \
                                ^
include/linux/module.h:140:3: note: in expansion of macro ‘MODULE_GENERIC_TABLE’
   MODULE_GENERIC_TABLE(type##_device,name)
   ^~~~~~~~~~~~~~~~~~~~
arch/x86/crypto/aesni-intel_glue.c:1348:1: note: in expansion of macro ‘MODULE_DEVICE_TABLE’
 MODULE_DEVICE_TABLE(x86cpu, aesni_cpu_id);
 ^~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:308: recipe for target 'arch/x86/crypto/aesni-intel_glue.o' failed
make[2]: *** [arch/x86/crypto/aesni-intel_glue.o] Error 1
scripts/Makefile.build:455: recipe for target 'arch/x86/crypto' failed
make[1]: *** [arch/x86/crypto] Error 2

Description

The vulnerability, CVE-2016-0728, lives in the keyring facility built into the various flavors of Linux. The keyring encrypts and stores login information, encryption keys and certificates, and makes them available to applications. In a report published by Perception Point, researchers said the vulnerability is a reference leak that can be abused to ultimately execute code in the Linux kernel.

Running the full exploit will take about 30 minutes to run on a Intel Core i7-5500 CPU.

How to check

You can check if your kernel is affected with following code:

    #include <stddef.h>
    #include <stdio.h>
    #include <sys/types.h>
    #include <keyutils.h>

    int main(int argc, const char *argv[])
    {
        int i = 0;
        key_serial_t serial;

        serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
                "leaked-keyring");
        if (serial < 0) {
            perror("keyctl");
            return -1;
        }

        if (keyctl(KEYCTL_SETPERM, serial,
               KEY_POS_ALL | KEY_USR_ALL) < 0) {
            perror("keyctl");
            return -1;
        }

        for (i = 0; i < 100; i++) {
            serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
                    "leaked-keyring");
            if (serial < 0) {
                perror("keyctl");
                return -1;
            }
        }

        return 0;
    }

If, after the program has run, there something like the following line in /proc/keys:

3f3d898f I--Q---   100 perm 3f3f0000     0     0 keyring   leaked-keyring: empty

with a usage count of 100 * the number of times the program has been run, then the kernel is malfunctioning. If leaked-keyring has zero usages or has been garbage collected, then the problem is fixed.

Affected kernels

(when checked, the kernel is patched and therefor fixed)

• linux310 (fixed with 3.10.95-1)
• linux312 (fixed with 3.12.53-1)
• linux313 (fixed with 3.13.11.33-1)
• linux314 (fixed with 3.14.59-1)
• linux316 (fixed with 3.16.7.23-1)
• linux318 (fixed with 3.18.26-1)
• linux319 (fixed with 3.19.8.13-1)
• linux41 (fixed with 4.1.15-2)
• linux42 (fixed with 4.2.8.2-1)
• linux43 (fixed with 4.3.4-1)
• linux44 (fixed with 4.4.0-4)

I just noticed your change on linux 319rc3 bump to rc4, i notced on the rc3 version my power manager stuff is broke in plasma but works on 318. like below it is working with linux 318.. with linux 319rc3 its "X"ed out and completely blank..

After installation of 16.06-pre2 on Parallels, I'm hitting a panic on first boot:

Reported by محمد صبحي قباني by e-mail:

Trying to shutdown results in Cgroup : option or name mismatch , new:0x0 '''', old:0x4 "systemd" Shutdown[1]: failed to finalize file systems , ignoring

Similar issues already posted at:

[arch] cgroup : option or name mismatch, new: 0x0"", old: 0x4 "systemd"
[arch] [systemd mkinitcpio ] New weird messages during shutdown after upgrade
[cup of linux] Has any of you experienced trouble like this?
[manjaro] Startup error and shutdown hang.

Ignore all this: my bad, apologies:) details as to why, in second comment

in kernel 3.15.4 microcode is 0x3000014
cat /proc/cpuinfo

...
processor   : 3
vendor_id   : AuthenticAMD
cpu family  : 18
model       : 1
model name  : AMD A6-3400M APU with Radeon(tm) HD Graphics
stepping    : 0
microcode   : 0x3000014
...

but in kernel 3.12
microcode is 0x3000027
========= from dmesg in 3.12.24-1:

...
[    8.541068] microcode: CPU0: patch_level=0x03000014
[    8.637140] microcode: CPU0: new patch_level=0x03000027
[    8.642110] microcode: CPU1: patch_level=0x03000014
[    8.646894] microcode: CPU1: new patch_level=0x03000027
[    8.652352] microcode: CPU2: patch_level=0x03000014
[    8.655745] microcode: CPU2: new patch_level=0x03000027
[    8.659119] microcode: CPU3: patch_level=0x03000014
[    8.661920] microcode: CPU3: new patch_level=0x03000027
[    8.668698] microcode: Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba
...

I've noticed some patches in 3.12 which aren't applied on 3.14 (probably for a good reason?maybe because kernel changed too much? guessing), from PKGBUILD:

...
# AMD fixes
        '1-4-ramdisk-Export_relocated_ramdisk_VA.patch::https://lkml.org/lkml/diff/2013/12/5/621/1'
        '2-4-microcode-Share_native_MSR_accessing_variants.patch::https://lkml.org/lkml/diff/2013/12/5/620/1'
        '3-4-microcode-AMD-Fix_early_ucode_loading.patch::https://lkml.org/lkml/diff/2013/12/5/626/1'
        '4-4-microcode-Move_to_a_proper_location.patch::https://lkml.org/lkml/diff/2013/12/5/698/1'
...

I haven't tried to find a solution for this yet.
Thank you.

EDIT: probably worth noting that extra/intel-ucode is the only microcode package that I could find but it's for intel processors;
Hmm, the amd microcode seems to be in /usr/lib/firmware/amd-ucode/

$ ls -la /usr/lib/firmware/amd-ucode/
total 48
drwxr-xr-x  2 root root  4096 28.06.2014 19:06 ./
drwxr-xr-x 73 root root 12288 28.06.2014 19:06 ../
-rw-r--r--  1 root root 12684 12.06.2014 19:31 microcode_amd.bin
-rw-r--r--  1 root root   490 12.06.2014 19:31 microcode_amd.bin.asc
-rw-r--r--  1 root root  7876 12.06.2014 19:31 microcode_amd_fam15h.bin
-rw-r--r--  1 root root   490 12.06.2014 19:31 microcode_amd_fam15h.bin.asc

which comes with linux-firmware package, maybe I just need to find a way to make kernel load it, will check.

EDIT2: forgot to mention that these kernel configs were in effect with 3.15.4
[*] CPU microcode loading support CONFIG_MICROCODE
[*] AMD microcode loading support CONFIG_MICROCODE_AMD
[*] Early load microcode CONFIG_MICROCODE_EARLY

Also I've tried putting the firmware into kernel(because it worked for SUMO / radeon driver) but I forgot that it couldn't have worked because This option provides functionality to read additional microcode data at the beginning of initrd image. and I guess maybe that's what those patches do (which I haven't really looked at)
Trying with microcode being a module ...
EDIT3: looks like it's working when it's module:

...
[    0.998553] [drm] Loading SUMO Microcode
...
[   12.744073] Registering platform device 'microcode'. Parent at platform
[   12.744076] device: 'microcode': device_add
[   12.744090] bus: 'platform': add device microcode
[   12.744148] microcode: CPU0: patch_level=0x03000014
[   12.744155] platform microcode: firmware: using built-in firmware amd-ucode/microcode_amd.bin
[   12.744180] microcode: CPU0: new patch_level=0x03000027
[   12.744189] microcode: CPU1: patch_level=0x03000014
[   12.744202] microcode: CPU1: new patch_level=0x03000027
[   12.744468] microcode: CPU2: patch_level=0x03000014
[   12.745373] microcode: CPU2: new patch_level=0x03000027
[   12.745397] microcode: CPU3: patch_level=0x03000014
[   12.745413] microcode: CPU3: new patch_level=0x03000027
[   12.745427] device: 'microcode': device_add
[   12.745517] microcode: Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba
...

but wait, I left the two amd .bin files as firmware inside kernel, removing and recompiling (but will probably still work) brb

Seems with using gcc all new kinds of issues occur ...

3.19.8.21

In file included from include/linux/compiler.h:54:0,
                 from include/uapi/linux/stddef.h:1,
                 from include/linux/stddef.h:4,
                 from ./include/uapi/linux/posix_types.h:4,
                 from include/uapi/linux/types.h:13,
                 from include/linux/types.h:5,
                 from include/linux/page-flags.h:8,
                 from kernel/bounds.c:9:
include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc6.h: No such file or directory
 #include gcc_header(__GNUC__)
                              ^
compilation terminated.

$ sudo lxc-checkconfig
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

User Namespace support missing, but lxc-1.1.1 in the repos.

As noted down in the forums I'm not sure the kernel package itself is the best place to place bootloader updating.
For example MSM is already better, and there wouldn't be any problem should you decide to add complexity in code to support more bootloaders.

Relates to manjaro/manjaro-settings-manager#52

aufs4.1-20150921.patch.bz2 mssing
Doesn't build

==> Empfange Quellen...
  -> linux-4.1.tar.xz gefunden
  -> patch-4.1.8.xz gefunden
  -> config gefunden
  -> config.x86_64 gefunden
  -> config.aufs gefunden
  -> linux41.preset gefunden
==> FEHLER: aufs4.1-20150921.patch.bz2 wurde nicht im build Verzeichnis gefunden und ist keine URL.

I'm seeing a bug of some sort which is causing mesa to fallback to software rendering (llvmpipe) if i'm using any kernel 4.2.x or above.

My GPU is an AMD Radeon 7770, and if i boot using kernel 3.19.x or 4.1.x, mesa utilizes the radeonsi driver, providing openGL 4.1 core profile, OpenGL 3.0, and OpenGLES 3.0. If, however, i boot up any kernel 4.2 or higher, mesa uses the llvmpipe software rasterizer.

I'd thought it was a firmware issue, with the linux-firmware package perhaps not having been updated to support the latest kernels, but even when I installed linux-firmware-git from the AUR to replace the standard linux-firmware package and then booted linux 4.3-rc7, mesa was still using llvmpipe instead of radeonsi. Pwering down the computer and booting linux 3.19.8 or 4.1.11 instead of 4.3-rc7 does get radeonsi to be used correctly, but I'd like to not be stuck on this kernel because I can't obtain 3D acceleration on new kernels.

The Xorg.0.log after booting kernel 4.3 contains the following:
4.591 [KMS] Kernel modesetting enabled.
4.591 RADEON(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
4.591 RADEON(0): Depth 24, (--) framebuffer bpp 32
4.591 RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
4.591 RADEON(0): Default visual is TrueColor
4.591 RADEON(0): RGB weight 888
4.591 RADEON(0): Using 8 bits per RGB (8 bit DAC)
4.591 RADEON(0): Chipset: "VERDE" (ChipID = 0x683d)
4.591 RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
4.591 Loading sub module "shadow"
4.591 LoadModule: "shadow"
4.591 Loading /usr/lib/xorg/modules/libshadow.so
4.592 Module shadow: vendor="X.Org Foundation"

However, Xorg.0.log after I boot kernel 4.1.11 shows that under that kernel, the proper dri driver is active:
4.662 [KMS] Kernel modesetting enabled.
4.662 RADEON(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
4.662 RADEON(0): Depth 24, (--) framebuffer bpp 32
4.662 RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
4.662 RADEON(0): Default visual is TrueColor
4.662 RADEON(0): RGB weight 888
4.662 RADEON(0): Using 8 bits per RGB (8 bit DAC)
4.662 RADEON(0): Chipset: "VERDE" (ChipID = 0x683d)
4.662 Loading sub module "dri2"
4.662 LoadModule: "dri2"
4.662 Module "dri2" already built-in
4.662 Loading sub module "glamoregl"
4.662 LoadModule: "glamoregl"
4.662 Loading /usr/lib/xorg/modules/libglamoregl.so
4.672 Module glamoregl: vendor="X.Org Foundation"
[ 4.672] compiled for 1.17.2, module version = 1.0.0
[ 4.672] ABI class: X.Org ANSI C Emulation, version 0.4
4.672 glamor: OpenGL accelerated X.org driver based.

The complete dmesgs, Xorg.0.logs, and list of (could-be) relevant installed packages are available upon request in text file format, as the website says "Attaching documents requires permission to this repository." I can pastebin as needed to view log/s.

linux310

[phil@manjaro Arbeitsfläche]$ lsmod | grep xfs
[phil@manjaro Arbeitsfläche]$ sudo modprobe xfs
modprobe: ERROR: could not insert 'xfs': Unknown symbol in module, or unknown parameter (see dmesg)
[phil@manjaro Arbeitsfläche]$ uname -a
Linux manjaro 3.10.68-1-MANJARO #1 SMP Fri Feb 6 17:09:08 UTC 2015 x86_64 GNU/Linux
[phil@manjaro Arbeitsfläche]$ pacman -Ql linux310 | grep xfs
linux310 /usr/lib/modules/3.10.68-1-MANJARO/kernel/fs/xfs/
linux310 /usr/lib/modules/3.10.68-1-MANJARO/kernel/fs/xfs/xfs.ko.gz

linux312

[phil@manjaro Arbeitsfläche]$ lsmod | grep xfs
[phil@manjaro Arbeitsfläche]$ sudo modprobe xfs
modprobe: ERROR: could not insert 'xfs': Unknown symbol in module, or unknown parameter (see dmesg)
[phil@manjaro Arbeitsfläche]$ uname -a
Linux manjaro 3.12.37-1-MANJARO #1 SMP PREEMPT Sat Jan 31 22:00:15 UTC 2015 x86_64 GNU/Linux
[phil@manjaro Arbeitsfläche]$ pacman -Ql linux312 | grep xfs
linux312 /usr/lib/modules/3.12.37-1-MANJARO/kernel/fs/xfs/
linux312 /usr/lib/modules/3.12.37-1-MANJARO/kernel/fs/xfs/xfs.ko.gz

linux314

[phil@manjaro Arbeitsfläche]$ lsmod | grep xfs
[phil@manjaro Arbeitsfläche]$ sudo modprobe xfs
modprobe: ERROR: could not insert 'xfs': Unknown symbol in module, or unknown parameter (see dmesg)
[phil@manjaro Arbeitsfläche]$ uname -a
Linux manjaro 3.14.32-1-MANJARO #1 SMP PREEMPT Fri Feb 6 17:50:54 UTC 2015 x86_64 GNU/Linux
[phil@manjaro Arbeitsfläche]$ pacman -Ql linux314 | grep xfs
linux314 /usr/lib/modules/3.14.32-1-MANJARO/kernel/fs/xfs/
linux314 /usr/lib/modules/3.14.32-1-MANJARO/kernel/fs/xfs/xfs.ko.gz

Filesystems related to crc32c are affected too.

Manjaro have versatile offer of kernels (even RT one) so I don't see any reason to not provide this as well. There are already grsec-common, gradm and pax tools in repos so grsecurity looks as an obvious missing link here.

At first it could be just plain copy from arch if you are much time constrained (it would give auto update option instead of constantly checking arch website).

Please consider.

Seems we have an issue currently in x86_64 with extramodules for 4.7.2. They all fail with following issue:

==> Starting build()...
make -C /lib/modules/4.7.2-1-MANJARO/build M=/home/phil/dev/git/manjaro/repositories/extra/linux47-extramodules/acpi_call/src/acpi_call-1.1.0 modules
make[1]: Entering directory '/usr/lib/modules/4.7.2-1-MANJARO/build'
make[2]: *** No rule to make target 'tools/objtool/objtool', needed by '/home/phil/dev/git/manjaro/repositories/extra/linux47-extramodules/acpi_call/src/acpi_call-1.1.0/acpi_call.o'.  Stop.
make[1]: *** [Makefile:1457: _module_/home/phil/dev/git/manjaro/repositories/extra/linux47-extramodules/acpi_call/src/acpi_call-1.1.0] Error 2
make[1]: Leaving directory '/usr/lib/modules/4.7.2-1-MANJARO/build'
make: *** [Makefile:8: default] Error 2
==> ERROR: A failure occurred in build().

linux47.preset file is missing in repo but invoked in PKGBUILD so makepkg fails. Generic preset file should be copied from linux4x repo.

New kernels are out:

• 3.10.101
• 3.12.57
• 3.14.65
• 3.19.8.17
• 4.1.20
• 4.2.8.6
• 4.4.6

Would it be possible to have the new drivers enabled in the coming RC? They have already been mainlined, and are quite stable (on my compiled kernel).
CONFIG_INTEL_ISH_HID is the config option.

sha256sums in PKGBUILD of linux46 repo should be updated after 0e8314e commit. Currently sha256sums of added patches are missing.