RE: Re: [opensuse-factory] [Leap 42.1] [LUKS password at boot]
I can confirm this behavior but had it with Leap and Tumbleweed (latest snapshots) especially when using an USB hub or changing the keyboard right away (using another one than at install time - which triggered my scare about reprogrammed firmware). My setup is/was: /boot - unencrpyted and then encrypted LVM with root, swap and home. The behavior is: boots normally with normal keyboard function then, once you pass the grub: it is as if it is switched off, no corrent at all, numlock LED has not functionality when pressed, so it is as if it would be switched off. To the O.P.: try if you have to stick in a different usb-keyboard. If I am right you will then be able to input the password to unblock LUKS. So this would confirm a but which you and me share :-) Other test would be: take of the keyboard from the hub and put it directly on one of the usb-outlets of your machine (that is if you use a hub). Then also I experienced you can overcome the block.
-----Ursprüngliche Nachricht----- Von: Andrei Borzenkov Gesendet: Sa. 31.10.2015 10:39 An: opensuse-factory@opensuse.org Betreff: Re: [opensuse-factory] [Leap 42.1] [LUKS password at boot]
Zitat von Andrei Borzenkov :
root partition or user
31.10.2015 12:31, 0x90 пишет: partitions?
All partitions exept /boot/efi and
/boot are encrypted. It does not answer my question. I did not ask which partitions were encrypted - I asked with which partitions you had problems entering password. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----Ursprüngliche Nachricht Ende-----
--- Alle Postfächer an einem Ort. Jetzt wechseln und E-Mail-Adresse mitnehmen! http://email.freenet.de/basic/Informationen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
31.10.2015 12:46, stakanov@freenet.de пишет:
I can confirm this behavior but had it with Leap and Tumbleweed (latest snapshots) especially when using an USB hub or changing the keyboard right away (using another one than at install time - which triggered my scare about reprogrammed firmware). My setup is/was: /boot - unencrpyted and then encrypted LVM with root, swap and home. The behavior is: boots normally with normal keyboard function then, once you pass the grub: it is as if it is switched off, no corrent at all, numlock LED has not functionality when pressed, so it is as if it would be switched off.
It is possible that necessary drivers are missing from initrd. Could you show lsinitrd output? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Zitat von stakanov@freenet.de:
I can confirm this behavior but had it with Leap and Tumbleweed (latest snapshots) especially when using an USB hub or changing the keyboard right away (using another one than at install time - which triggered my scare about reprogrammed firmware). My setup is/was: /boot - unencrpyted and then encrypted LVM with root, swap and home. The behavior is: boots normally with normal keyboard function then, once you pass the grub: it is as if it is switched off, no corrent at all, numlock LED has not functionality when pressed, so it is as if it would be switched off.
To the O.P.: try if you have to stick in a different usb-keyboard. If I am right you will then be able to input the password to unblock LUKS. So this would confirm a but which you and me share :-) Other test would be: take of the keyboard from the hub and put it directly on one of the usb-outlets of your machine (that is if you use a hub). Then also I experienced you can overcome the block.
I tried different (usb) keyboards in different usb ports (now every possible usb slot tested). Usb hub or not makes no difference. Usually I use the ones at mainboard panel and do not change usb port. But now there is indeed a scary issue: I installed 13.2 and NOW there is also a problem with entering the password. BUT: in 13.2 I am able to enter the password, when replugging keyboard and hitting some keys. Simply replugging (same or another usb port) OR hitting some keys does not work. keys: combination of {ctrl,alt,backspace,esc,...}. By now I can not tell which keys or combination of keys work, but fuzzing works. In leap Build 265 this does not work. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-10-31 12:16, 0x90 wrote:
I tried different (usb) keyboards in different usb ports (now every possible usb slot tested). [...] But now there is indeed a scary issue: I installed 13.2 and NOW there is also a problem with entering the password. BUT: in 13.2 I am able to enter the password, when replugging keyboard and hitting some keys.
Something similar occurrs to me on an oldish IBM xServer 330 (or some related model). Once the USB keyboard is in Full HID mode (rather than the compat mode used during grub), the USB *chip* goes haywire after some seconds, leading to kernel messages similar to irq 19: nobody cared [no driver registered this irq] deactivating device suchandsuch And then it deactivates the USB chip. Replugging does not fix it, but reloading the USB kernel modules does - again, for some unspecified random amount of seconds only, repeating the issue. The only reliable way of doing local input on that machine is via a serial cable (and then remote once ssh is up). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2015-10-31 at 15:07 +0100, Jan Engelhardt wrote:
Something similar occurrs to me on an oldish IBM xServer 330 (or some related model). Once the USB keyboard is in Full HID mode (rather than the compat mode used during grub), the USB *chip* goes haywire after some seconds, leading to kernel messages similar to
irq 19: nobody cared [no driver registered this irq] deactivating device suchandsuch
And then it deactivates the USB chip. Replugging does not fix it, but reloading the USB kernel modules does - again, for some unspecified random amount of seconds only, repeating the issue. The only reliable way of doing local input on that machine is via a serial cable (and then remote once ssh is up).
Do you use MSI? Regards Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 02 Nov 2015 08:36:59 +0100, Oliver Neukum wrote:
On Saturday 2015-10-31 15:07, Jan Engelhardt wrote:
Something similar occurrs to me on an oldish IBM xServer 330 (or some related model). Once the USB keyboard is in Full HID mode (rather than the compat mode used during grub), the USB *chip* goes haywire after some seconds, leading to kernel messages similar to
irq 19: nobody cared [no driver registered this irq] deactivating device suchandsuch
And then it deactivates the USB chip. Replugging does not fix it, but reloading the USB kernel modules does - again, for some unspecified random amount of seconds only, repeating the issue. The only reliable way of doing local input on that machine is via a serial cable (and then remote once ssh is up).
Do you use MSI?
(I had the opportunity to visit the machine...) Yes, MSI is used, but not for the USB parts. As such, the issue persists after using pci=nomsi. It may however be related to some bad RAM - which is marked as being of the ECC Registered kind, so Linux does not have a problem with it, but maybe the DMA path behind the CPU does? Who knows, it'll just be written off anyway, given the age. Until then, winning the race at boot, or using a serial console works to enter the passphrase. Model: IBM xserver 236, AMD CPU. /proc/interrupts in normal operation: CPU0 CPU1 0: 46 0 IO-APIC-edge timer 1: 1 2 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 10: 213 99789 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 11: 146 5587 IO-APIC-fasteoi sata_svw 12: 1 4 IO-APIC-edge i8042 14: 86 205 IO-APIC-edge pata_serverworks 15: 0 0 IO-APIC-edge pata_serverworks 64: 0 667 PCI-MSI-edge eth0 65: 0 2 PCI-MSI-edge eth1 NMI: 0 0 Non-maskable interrupts LOC: 5112 7042 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts IWI: 532 374 IRQ work interrupts RTR: 0 0 APIC ICR read retries RES: 8390 7637 Rescheduling interrupts CAL: 2936 349 Function call interrupts TLB: 66 55 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 1 1 Machine check polls THR: 0 0 Hypervisor callback interrupts ERR: 0 MIS: 0 With with pci=nomsi: CPU0 CPU1 0: 46 0 IO-APIC 2-edge timer 1: 0 2 IO-APIC 1-edge i8042 8: 0 1 IO-APIC 8-edge rtc0 9: 0 0 IO-APIC 9-fasteoi acpi 10: 241 4680 IO-APIC 10-fasteoi 0000:01:0e.0 11: 316 199686 IO-APIC 11-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 12: 0 4 IO-APIC 12-edge i8042 14: 6 605 IO-APIC 14-edge pata_serverworks 15: 0 0 IO-APIC 15-edge pata_serverworks 16: 2 808 IO-APIC 10-fasteoi eth0 17: 0 1 IO-APIC 11-fasteoi eth1 NMI: 0 0 Non-maskable interrupts LOC: 7088 12114 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts IWI: 3 4 IRQ work interrupts RTR: 0 0 APIC ICR read retries RES: 7530 7288 Rescheduling interrupts CAL: 2781 455 Function call interrupts TLB: 56 167 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts DFR: 0 0 Deferred Error APIC interrupts MCE: 0 0 Machine check exceptions MCP: 2 2 Machine check polls ERR: 0 MIS: 0 PIN: 0 0 Posted-interrupt notification event PIW: 0 0 Posted-interrupt wakeup event -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
0x90 -
Andrei Borzenkov -
Jan Engelhardt -
Oliver Neukum -
stakanov＠freenet.de