[Bug 8078] kmilo plugin unuseable

bugzilla-daemon at bugzilla.ubuntu.com bugzilla-daemon at bugzilla.ubuntu.com
Wed Sep 21 17:57:11 UTC 2005


Please do not reply to this email.  You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=8078
Ubuntu (kubuntu, laptop) | kubuntu-live





------- Additional Comments From alankila at bel.fi  2005-09-21 18:57 UTC -------
I would like that the system created nvram group by default. (Not only on live
cd but also in default install.) The current requirements to shoot yourself in
the foot are:

- create nvram group
- modprobe nvram
- adduser <your user> nvram
- log in with KDE and have kmilo turned on

I propose that we reduce the unobvious steps in the way and by default at least
create the nvram group (udev is already configured to expect the existence of
this group) so that users who want nvram are already pointed at new direction by
seeing the 0660 moded device file with root.nvram permissions. Additionally, I
do think nvram module should be mentioned at /etc/modules (because it's
"hardware" you got and you should have its driver loaded without action from
user's part).

Even if you disagree with the latter idea, it's okay. I really only want the
nvram group to be created. Without the group, even users who *want* to use kmilo
simply don't know how to setup their system correctly; witness the comment #1
from Jonathan Riddell, who advices the incorrect solution.

Users who want to use it still need to add themselves into the nvram group and
login again before things such as kmilo works. There is now some increased
danger for the root user, but then again, there are many files in /dev already
that cause awful results if randomly poked at, so nothing new there. As far as I
know, there should be no permanent damage to computer even in worst-case nvram
hacks because all it takes to repair the computer is to reset BIOS through the
on-board jumper to place it back to a known state. Okay, in principle users
might place computer into horrible overclocking settings, and try cook up their
hardware if their BIOS+hardware is sufficiently permitting, but it also is
overwhelmingly unlikely. I believe that most BIOSes have a checksumming
algorithm that determines whether the RAM has been meddled with, and will
reinitialize/ignore the RAM if its checksum does not match. (Because the RAM
state changes when the clear CMOS jumper is being used, and the BIOS needs to
reliably detect it and recover.)

-- 
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the kubuntu-bugs mailing list