Unfortunately this bug report is being closed because we received no
response to the last inquiry for information. However, the Intrepid Ibex
8.10 Beta release was most recently announced -
http://www.ubuntu.com/testing/intrepid/beta . If you are able to confirm
this is still an issue with this mos
The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
There are one of two ways you should be able to test:
1) If you are comfortable
Like I wrote before, I cannot personally test this, because the hardware
is too old to run any recent release of Ubuntu. Anybody else with a
Toshiba APM BIOS should be able to try to repro this, though. Is there
a tag I could assign to this bug to indicate that testing help from
someone with suit
Hardy Heron 8.04 was recently released. It would be helpful if you
could test the new release and verify if this is still an issue -
http://www.ubuntu.com/getubuntu/download . You should be able to test
your bug using the LiveCD. Please let us know your results. Thanks.
** Changed in: linux (
The 18 month support period for Edgy Eft 6.10 has reached it's end of
life. As a result, we are closing the linux-source-2.6.17 Edgy Eft
kernel task. However, please note that this report will remain open
against the actively developed kernel. Thank you for your continued
support and help as we
To reiterate, I no longer have a Toshiba which uses APM, so I cannot
easily assess the effects of this bug any longer. The permissions have
not changed but the applications which use this API may have come up
with a different workaround. I presently have no way to test that.
--
/dev/toshiba cre
Can you clarify the following:
This issue is the same for every release upto & including Gutsy?
You solve this by changing /dev/toshiba from:[660 root:root] to [660
root:admin]?
I found one link which suggested Debian runs this as [666 root:root] -
although not suggesting you run like this as thi
Wouldn't in fact group "powerdev" ownership be a good solution? Where
are these standard groups documented?
--
/dev/toshiba created chmod 660 root:root
https://bugs.launchpad.net/bugs/57052
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here's what http://popcon.ubuntu.com/by_vote says:
#Format
#
# is the package name;
# is the number of people who installed this package;
# is the number of people who use this package regularly;
# is the number of people who installed, but don't use this package
#regularly;
# is the nu
Also http://ubuntuforums.org/showthread.php?t=16975 looks like
coincidental confirmation that others too have bumped into this, but
that's a pretty old thread (2005).
--
/dev/toshiba created chmod 660 root:root
https://bugs.launchpad.net/bugs/57052
You received this bug notification because you a
I still have the hardware where this happened but it cannot really run
any recent version of Ubuntu. However, I believe the repro steps should
be trivial (try to use the device as a non-root user) and the fix, one
way or another, straightforward. If there are newer Toshiba machines
with the same
This bug has had no activity for a considerable period. This is a check
to see if there is still interest in investigating this bug report.
** Changed in: linux-source-2.6.17 (Ubuntu)
Status: New => Incomplete
** Changed in: linux-source-2.6.15 (Ubuntu)
Status: New => Incomplete
--
The system where I originally discovered this was running a different
kernel, apparently 2.6.15
** Changed in: linux-source-2.6.17 (Ubuntu)
Sourcepackagename: toshutils => linux-source-2.6.17
** Also affects: linux-source-2.6.15 (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
/d
On second thought, maybe the permissions should remain, and wmtuxtime et
al. changed to cope accordingly instead (and then the bug assigned back
to toshutils)? Any opinions?
--
/dev/toshiba created chmod 660 root:root
https://bugs.launchpad.net/bugs/57052
You received this bug notification becau
This appears to be a problem in the kernel or a related package, since
it manifests even on a system which doesn't have toshutils installed.
Feel free to reject against toshutils and reassign ... most likely in
accordance with this:
vnix$ dpkg -S
/lib/modules/2.6.17-11-generic/kernel/drivers/acpi
The workaround turned out to be a textbook example of the modprobe
"install" directive. Including here just in case I need to remember what
I did ...
The solution hinges on the assumption that a particular group (in this
case, admin) corresponds to the users who are granted privilege to run
wmtuxt
I don't reboot that often (-: so I didn't notice until now, but
actually, /dev/toshiba is (of course) recreated each time you load the
toshiba module, and removed when it is rmmodded. Every time, you have to
go chmod or chgrp it in order for e.g. wmtuxtime to work. I plan to set
up a local rc.scrip
** Summary changed:
- /dev/toshiba created cmod 660 root:root
+ /dev/toshiba created chmod 660 root:root
** Description changed:
Running wmtuxtime as myself produces the helpful error message about the
kernel not having the necessary module, even though the toshiba module
is shown by lsmod
18 matches
Mail list logo
