Every kernel previous seems to be working fine, but every time I try updating to 3.11-0 or 3.11-1, I can't unlock my LVM partition, because neither my keyboard or mouse seem to function. They won't even emit any light, which makes me think my USB ports as a whole have died somehow. Unplugging and replugging does nothing, and the keyboard still works in the GRUB menu (thankfully), so I was able to downgrade back to 3.10-10.

I don't even get any errors when I install the kernels. They compile smoothly; it just doesn't respond to any input.

Hopefully this isn't a common issue that I missed the answer to somehow. I don't know if specificity is needed as to my hardware or anything.

Just to state the obvious(?), so you have an encrypted rootfs on lvm2 and can't enter the password, when the initramfs hooks prompt you for it?

Which version of initramfs-tools do you have installed?

If you still have more than one old/ working kernel installed, it would be great if you could refresh the initramfs of one of those, to rule out that being an issue (I'm thinking about the recent udev update). You can do that by booting into one of the old, working, kernel and running "update-initramfs -k $(uname -r) -u" as root.

If you still have an older PS/2 keyboard, it would be great if you could check that as well (in contrast to USB, PS/2 is not hotpluggable, so make sure to switch off your PC before (dis-)connecting any PS/2 device, as your mainboard might be permanently damaged otherwise).

Just to state the obvious(?), so you have an encrypted rootfs on lvm2 and can't enter the password, when the initramfs hooks prompt you for it?

Correct.

I ran the update-initramfs command, and that may have been the problem, because now it tries updating initramfs-tools when I run a dist-upgrade. But it also wants to remove forty other packages, most of which are xserver-related and would clearly break my display if I agreed to that. Dependency issues ahoy.

I didn't know when I encrypted my disk that I'd have to run update-initramfs regularly, and not just the one time when setting it up. So this is a learning experience.

EDIT: Oh! There might be an unrelated dist-upgrade issue with xserver at the moment. That's some odd timing on my part.

ANOTHER EDIT: Alright, so I ran "apt-get install initramfs-tools" and upgraded it singularly without bothering with a dist-upgrade for the moment. Then I tried upgrading the kernel and had the same dead peripherals. But initramfs-tools is no longer out of date. So I guess that's no longer a factor. Back into 3.10-10-slh.1 for now.

So now I have version 0.114 of initramfs-tools. I'll attempt finding an older keyboard in the morning.

I didn't know when I encrypted my disk that I'd have to run update-initramfs regularly, and not just the one time when setting it up. So this is a learning experience.

No, you haven't, the initramfs for a kernel is built automatically if a new kernel is installed (and with the install of a few other packages as well). The initramfs of already installed kernels is just not updated, so that a dist-upgrade isn't effecting (negatively) older kernels – as updating all initramfs's would have meant for you that you could no longer boot any kernel currently.
(so slh suspicion is correct, "something" is breaking your setup currently irrespective of kernel version involved).

_________________MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor

gregfrankenstein

Post subject:Posted: 23.09.2013, 09:20

Joined: 2013-09-22
Posts: 22

Status: Offline

Found an old PS/2 keyboard, upgraded the kernel again, and YES, it works. And once the password is entered and LVM2 is unlocked, the USB mouse lights back up and functions normally. It's as though whatever is killing the USB peripherals only does so during the initramfs stage.

gregfrankenstein

Post subject:Posted: 23.09.2013, 10:10

Joined: 2013-09-22
Posts: 22

Status: Offline

Found a variable in /etc/initramfs-tools/initramfs.conf called KEYMAP that was set to "n", so I tried setting it to "y". Didn't help.

gregfrankenstein

Post subject:Posted: 23.09.2013, 10:36

Joined: 2013-09-22
Posts: 22

Status: Offline

Attempted, as per this page, adding the following to /etc/initramfs-tools/modules:

If you still have more than one old/ working kernel installed, it would be great if you could refresh the initramfs of one of those, to rule out that being an issue (I'm thinking about the recent udev update). You can do that by booting into one of the old, working, kernel and running "update-initramfs -k $(uname -r) -u" as root.

Please read this bit again and ask questions if you are unsure what it means. The idea is to test an old kernel with an initramfs built using the current everything else (in particular udev) to determine if the problem is with the kernel itself or with something else (e.g. udev).

Sorry if I'm misreading your posts and you have tried this, but I don't think you have.

Please read this bit again and ask questions if you are unsure what it means. The idea is to test an old kernel with an initramfs built using the current everything else (in particular udev) to determine if the problem is with the kernel itself or with something else (e.g. udev).

Sorry if I'm misreading your posts and you have tried this, but I don't think you have.

Ah. Sorry. I think I misunderstood a little bit and updated initramfs-tools before trying 3.11 again.