My keyboard works fine at the GRUB screen, enabling me to select the
kernel to boot. However, at gdm3 (and kdm as well now as the default),
neither mouse nor keyboard works.
Doing a hard reboot, I can boot into recovery mode and from there startx
and as root, keyboard and mouse work fine. But, logging out as root and
coming back to the login screen, again input devices are frozen.
Research from the web seems to suggest this is a known bug, but the
resolutions are confusing: some suggest rm -fr /run but that doesn't
work for me; others suggest it is something to do with udev, whilst
others think it has something to do with xorg.conf. So far, the only
workarounds seem to be hacks that work for some but not for others.
There do seem to be a number of bugs reported on this already.
I am currently using my user account, but had to get into it via
recovery mode, going to root and su to my user account. This seems to
be okay, but it is not a preferred route.
Can someone please give me some advice on how to fix this.
Am I looking at downgrading udev or upgrading it or ... ? And if
downgrading it, how do I do that without losing everything else that
seems to be dependent on it?
For reference, this is an installation from squeeze that was updated to
wheezy, but I have now read that this is an issue for those who have
done fresh wheezy installs as well.
Thanks for any help.
AG
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On 12/06/11 19:34, AG wrote:
My keyboard works fine at the GRUB screen, enabling me to select the
kernel to boot. However, at gdm3 (and kdm as well now as the
default), neither mouse nor keyboard works.
Doing a hard reboot, I can boot into recovery mode and from there
startx and as root, keyboard and mouse work fine. But, logging out as
root and coming back to the login screen, again input devices are frozen.
Research from the web seems to suggest this is a known bug, but the
resolutions are confusing: some suggest rm -fr /run but that doesn't
work for me; others suggest it is something to do with udev, whilst
others think it has something to do with xorg.conf. So far, the only
workarounds seem to be hacks that work for some but not for others.
There do seem to be a number of bugs reported on this already.
I am currently using my user account, but had to get into it via
recovery mode, going to root and su to my user account. This seems to
be okay, but it is not a preferred route.
Can someone please give me some advice on how to fix this.
Am I looking at downgrading udev or upgrading it or ... ? And if
downgrading it, how do I do that without losing everything else that
seems to be dependent on it?
For reference, this is an installation from squeeze that was updated
to wheezy, but I have now read that this is an issue for those who
have done fresh wheezy installs as well.
Thanks for any help.
AG
After further research, I downgraded udev_170-1_i386 to udev_167-3_i386
and libudev0_170-1_i386 to libudev0_167-3_i386 and rebooted.
The problem is now resolved. However, the Update Manager wants to
upgrade these two files to 170-1. Is there anyway to stop this from
happening, or do I manually deselect these when it is time to update?
Cheers
AG
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> The problem is now resolved. However, the Update Manager wants to
> upgrade these two files to 170-1. Is there anyway to stop this from
> happening, or do I manually deselect these when it is time to update?
echo "<package> hold" | dpkg --set-selections
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110613104151.GC19572@desktop">http://lists.debian.org/20110613104151.GC19572@desktop
06-13-2011, 10:59 AM
AG
No input devices in wheezy
On 13/06/11 11:41, Brian wrote:
On Mon 13 Jun 2011 at 11:10:51 +0100, AG wrote:
The problem is now resolved. However, the Update Manager wants to
upgrade these two files to 170-1. Is there anyway to stop this from
happening, or do I manually deselect these when it is time to update?
echo "<package> hold" | dpkg --set-selections
Thanks Brian
Just to be clear then, this will hold back the two udev* packages from
being updated?
At some point, I'm assuming the udev maintainer will fix the problems in
the udev_170-1 so how will I reverse this hold so that I can later
update to the fixed packages?
Cheers
AG
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Just to be clear then, this will hold back the two udev* packages from
> being updated?
Yes.
> At some point, I'm assuming the udev maintainer will fix the problems in
> the udev_170-1 so how will I reverse this hold so that I can later
> update to the fixed packages?
echo "<package> install" | dpkg --set-selecions
If you use it, it's possible aptitude can do hold/unhold.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110613141838.GE19572@desktop">http://lists.debian.org/20110613141838.GE19572@desktop
06-14-2011, 12:02 AM
Wolodja Wentland
No input devices in wheezy
On Sun, Jun 12, 2011 at 19:34 +0100, AG wrote:
> My keyboard works fine at the GRUB screen, enabling me to select the
> kernel to boot. However, at gdm3 (and kdm as well now as the
> default), neither mouse nor keyboard works.
Quite likely due to the /run + udev + initscripts transition that is still
ongoing in wheezy (o/ Md)
For now do either:
1. "rm -rf /run" + reboot
2. Upgrade udev, base-files and all binary packages built from the
initscripts source package to the versions in sid. Probably the easiest
way is to set the default release to "wheezy" and "aptitude -t sid"
them.
FWIW - I recommend the first approach. If you have further question either
come back here, or join #debian-next on irc.oftc.net.
My keyboard works fine at the GRUB screen, enabling me to select the
kernel to boot. However, at gdm3 (and kdm as well now as the
default), neither mouse nor keyboard works.
Hi Wolodja
Quite likely due to the /run + udev + initscripts transition that is still
ongoing in wheezy (o/ Md)
For now do either:
1. "rm -rf /run" + reboot
I came across this suggestion after researching this issue, but this
didn't work for me. Apparently, others had mixed success with this too
from what I read.
2. Upgrade udev, base-files and all binary packages built from the
initscripts source package to the versions in sid. Probably the easiest
way is to set the default release to "wheezy" and "aptitude -t sid"
them.
Actually, I tried doing this from experimental and from sid. The udev
was 170-1 and this was reported by apt as being the latest version.
What did work for me was downgrading udev and udev-utils to the previous
version and rebooting, so I don't know if version 170-1 is just toast or
whether the maintainer will work on this to sort out the bug(s), but for
now I am leaving that version well alone.
FWIW - I recommend the first approach. If you have further question either
come back here, or join #debian-next on irc.oftc.net.
Thanks for following up on this.
Good luck
Cheers
AG
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Mon, 2011-06-13 at 11:10 +0100, AG wrote:
> On 12/06/11 19:34, AG wrote:
> > My keyboard works fine at the GRUB screen, enabling me to select the
> > kernel to boot. However, at gdm3 (and kdm as well now as the
> > default), neither mouse nor keyboard works.
> >
> > Doing a hard reboot, I can boot into recovery mode and from there
> > startx and as root, keyboard and mouse work fine. But, logging out as
> > root and coming back to the login screen, again input devices are frozen.
> >
> > Research from the web seems to suggest this is a known bug, but the
> > resolutions are confusing: some suggest rm -fr /run but that doesn't
> > work for me; others suggest it is something to do with udev, whilst
> > others think it has something to do with xorg.conf. So far, the only
> > workarounds seem to be hacks that work for some but not for others.
> > There do seem to be a number of bugs reported on this already.
> >
> > I am currently using my user account, but had to get into it via
> > recovery mode, going to root and su to my user account. This seems to
> > be okay, but it is not a preferred route.
> >
> > Can someone please give me some advice on how to fix this.
> >
> > Am I looking at downgrading udev or upgrading it or ... ? And if
> > downgrading it, how do I do that without losing everything else that
> > seems to be dependent on it?
> >
> > For reference, this is an installation from squeeze that was updated
> > to wheezy, but I have now read that this is an issue for those who
> > have done fresh wheezy installs as well.
> >
> > Thanks for any help.
> >
> > AG
> >
>
> After further research, I downgraded udev_170-1_i386 to udev_167-3_i386
> and libudev0_170-1_i386 to libudev0_167-3_i386 and rebooted.
>
> The problem is now resolved. However, the Update Manager wants to
> upgrade these two files to 170-1. Is there anyway to stop this from
> happening, or do I manually deselect these when it is time to update?
>
> Cheers
>
> AG
You can lock the package version. I don't know how to do it by apt (you
need to read man apt, google ...), but for Synaptic
- mark the package
- then use pull down menu 'Package' > check 'Lock version'
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1308056707.2218.119.camel@debian">http://lists.debian.org/1308056707.2218.119.camel@debian