[arch-dev-public] 3.13 packages in testing
I am now starting to push Linux 3.13 to testing. This has taken a bit, since i686 refused to boot at all, and the actual cause of the problem is still a mystery to me. Anyway, I found a semi-permanent workaround. For more information, please see [1] and the discussion that will hopefully follow. I already built lirc, nvidia and nvidia-304xx and tested nvidia on x86_64, successfully. The community packages bbswitch, r8168, rt3562sta, tp_smapi, vhba-module, virtualbox-guest-modules and virtualbox-host-modules still need a rebuild, I like won't get to it now. The respective maintainers should update these ASAP. One major change is coming (and Tom will be happy about it): Keyboard support is entirely modular, even for AT(PS/2) keyboards. Beware that in order to have keyboard input during early boot, you need the 'keyboard' hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A post-install message has been added. [1] http://marc.info/?l=linux-kernel&m=139072738431286&w=2
Am 26.01.2014 12:41, schrieb Thomas Bächler:
The community packages bbswitch, r8168, rt3562sta, tp_smapi, vhba-module, virtualbox-guest-modules and virtualbox-host-modules still need a rebuild, I like won't get to it now. The respective maintainers should update these ASAP.
Okay, I finished those modules as well. But I tested none of them.
On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler <thomas@archlinux.org> wrote:
One major change is coming (and Tom will be happy about it): Keyboard support is entirely modular, even for AT(PS/2) keyboards. Beware that in order to have keyboard input during early boot, you need the 'keyboard' hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A post-install message has been added.
Awesome :-) \o/ -t
Am 26.01.2014 13:56, schrieb Tom Gundersen:
On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler <thomas@archlinux.org> wrote:
One major change is coming (and Tom will be happy about it): Keyboard support is entirely modular, even for AT(PS/2) keyboards. Beware that in order to have keyboard input during early boot, you need the 'keyboard' hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A post-install message has been added.
Awesome :-) \o/
-t
As it turns out, many people have no keyboard at all due to a bug (blame Tom). Please refrain from updating unless you have some other way to type 'modprobe atkbd' until we decide what exactly we should do.
Am 26.01.2014 18:54, schrieb Thomas Bächler:
Am 26.01.2014 13:56, schrieb Tom Gundersen:
On Sun, Jan 26, 2014 at 12:41 PM, Thomas Bächler <thomas@archlinux.org> wrote:
One major change is coming (and Tom will be happy about it): Keyboard support is entirely modular, even for AT(PS/2) keyboards. Beware that in order to have keyboard input during early boot, you need the 'keyboard' hook in mkinitcpio.conf. In other news, this breaks 'rdinit=/bin/sh'. A post-install message has been added.
Awesome :-) \o/
-t
As it turns out, many people have no keyboard at all due to a bug (blame Tom). Please refrain from updating unless you have some other way to type 'modprobe atkbd' until we decide what exactly we should do.
Okay, there are two problems: 1), the i8042 module was lacking modaliases. This is resolved by this patch http://pastebin.com/bKydQZLF 2) Some machines to not export the i8042 controller by either ACPI or PNP - for example, on my machine. Loading i8042 works just fine, but it will never be autodetected. This message is probably related: [14287.808024] i8042: PNP: No PS/2 controller found. Probing ports directly. So, should we just apply the patch and leave it as a module, or should we make it built-in again and close https://bugs.archlinux.org/task/27555 as "Won't fix"?
Hi Thomas, On Sun, Jan 26, 2014 at 7:04 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 26.01.2014 13:56, schrieb Tom Gundersen: Okay, there are two problems: 1), the i8042 module was lacking modaliases. This is resolved by this patch http://pastebin.com/bKydQZLF
I'll submit this upstream (and cc stable).
2) Some machines to not export the i8042 controller by either ACPI or PNP - for example, on my machine. Loading i8042 works just fine, but it will never be autodetected.
This message is probably related: [14287.808024] i8042: PNP: No PS/2 controller found. Probing ports directly.
Hm, this sucks a bit, as the manual probing (at least in my tests) will delay boot quite significantly. I was told that the manual probing stuff was not really relevant anymore, but if you are running into it that info seems dubious.
So, should we just apply the patch and leave it as a module, or should we make it built-in again and close https://bugs.archlinux.org/task/27555 as "Won't fix"?
So I'm obviously biased, but I'd prefer if we kept this as a module. Given the problem you ran into, I see two options: inform about the possible need to force-load the module in a post-install message (if we work from the assumption that it will be a rare issue). Or, if the problem appears to be more wide-spread, simply ship a modules-load.d fragment that will load the module. This will at least will give people the option to mask the fragment if they don't need the module to avoid the boot-delays (and spurious error message in dmesg). Cheers, Tom
Am 26.01.2014 19:37, schrieb Tom Gundersen:
Hm, this sucks a bit, as the manual probing (at least in my tests) will delay boot quite significantly. I was told that the manual probing stuff was not really relevant anymore, but if you are running into it that info seems dubious.
This is a bleeding edge PC with Intel H87 chipset. I don't actually use the PS/2 though since I have everything on USB.
Am 26.01.2014 19:37, schrieb Tom Gundersen:
So, should we just apply the patch and leave it as a module, or should we make it built-in again and close https://bugs.archlinux.org/task/27555 as "Won't fix"?
So I'm obviously biased, but I'd prefer if we kept this as a module. Given the problem you ran into, I see two options: inform about the possible need to force-load the module in a post-install message (if we work from the assumption that it will be a rare issue). Or, if the problem appears to be more wide-spread, simply ship a modules-load.d fragment that will load the module. This will at least will give people the option to mask the fragment if they don't need the module to avoid the boot-delays (and spurious error message in dmesg).
For the moment, I'll upload the kernel with the fixed aliases and see what happens. It is no problem to revert to built-in before we move to core.
participants (2)
-
Thomas Bächler
-
Tom Gundersen