Bugzilla – Full Text Bug Listing
| Summary: | Simplify oprofile installation procedure | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Roland Grunberg <rgrunber> |
| Component: | LinuxTools | Assignee: | OProfile Inbox <linux.oprofile-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | kksebasti, sgehwolf, wainersm |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Roland Grunberg
It seems that there are too many (inconsistent) instructions around regarding installation of native parts. For example here's an excerpt of the README file in org.eclipse.linuxtools.oprofile.core_*
---->8--------------------
An extra step is required to install the plugin (due to OProfile's lack of a user-space mode):
* Run the install script in the natives/linux/scripts directory (must be as root):
# ./install
* This will ensure all the necessary programs are installed, and create a wrapper for opcontrol
which prompts for the root password (since OProfile must be run as root). It will also load the
OProfile kernel module, however it is not loaded persistently. Hence, after the computer is
restarted and any functions of the plugin are used, there will be an extra prompt to run
opcontrol that would not normally appear.
------->8------------------
1.) There is no ./install (it's "install.sh")
2.) It doesn't seem to be doing what it claims it's doing. E.g. if you run that script without compiling (make) and installing (make install) opxml in native/linux/opxml first, it'll error out and claim that oprofile is not installed (or some such).
3.) There's also a README file in native/linux/opxml
4.) When oprofile is run and doesn't find a proper opxml installation, a giant error message pops up also providing instructions as to how to set things up properly.
Suggestion:
We should identify a *single* place where installation/configuration instructions are found (and merge both READMEs). Maybe the giant error message could also point to the single source of wisdom. I think that would be easier to maintain.
The whole problem goes away, though, if we could automate installation of those components as a whole.
Thoughts?
Automation would be awesome! Having a single location would also be really useful, and a good backup plan regardless of whether we do automation or not. If we're moving to a single location for the documentation, maybe it's a good opportunity to also look at using the Mylyn wikitexts and setting the wiki page as our single source? I agree with single-sourcing these instructions and having it more automated. I like the idea of having the instructions show up in your face, but having a click-able button that says "Click here to build and install the native intermediary" would be even better. There are a few cases we need to worry about: NFS installation with root squash, no sudo, etc. We should also make it clear that the user will need their machine's root password to complete the installation. Perhaps we should split this bug into some separate, actionable bugs? (In reply to comment #3) > I agree with single-sourcing these instructions and having it more automated. > I like the idea of having the instructions show up in your face, but having a > click-able button that says "Click here to build and install the native > intermediary" would be even better. There are a few cases we need to worry > about: NFS installation with root squash, no sudo, etc. We should also make > it clear that the user will need their machine's root password to complete the > installation. Sounds like an interesting task (or tasks?) to get my hands dirty and dive a little deeper into oprofile. :-) There's one more case to worry about (I think): Currently, oprofile uses consolehelper to do tasks as root. We should probably investigate what to use instead when consolehelper is not available on a Linux distro. > Perhaps we should split this bug into some separate, actionable bugs? I'm all for it. Makes sense to me. Created attachment 172428 [details]
Patch (add opxml compilation/installation to install script)
This should perform the opxml compilation and installation along with the install script. Maybe in the future something could call this from within eclipse-oprofile so the user doesn't have to drop to the command-line.
Created attachment 172616 [details]
Patch (add opxml compilation/installation to install script)
Fix uninstall to work for all archs.
Cool stuff :-)
>+ echo Attempting to compile the opxml binary
>+ user=`ls -l ../ | grep opxml | awk '{print $3}'`
>+ su ${user} -c 'make -C ../opxml && make -C ../opxml install'
I wonder if it would make sense to change this to (since su defaults to root and it's not necessarily what you want if somebody happens to change the opxml directory name):
if [ "${user}_" == "_" ]; then
# Do something
else
su ${user} -c 'make -C ../opxml && make -C ../opxml install'
fi
Thoughts?
Also, user=... could probably also be shortened to:
user=`ls -ld ../opxml | awk '{print $3}'`
I could just drop the user=... part and just run make as root (su). The make just generates the opxml and moves it into the right directory so as long as the user has execute privileges, it shouldn't matter who runs make. Created attachment 172688 [details]
Patch (add opxml compilation/installation to install script)
make as root.
It's better not to compile as root. Created attachment 174622 [details]
Patch (add opxml compilation/installation to install script)
Runs the installation as the user who owns the opxml directory. If for some reason the directory can't be found, installation is aborted.
Building opxml is now unnecessary as of Revision #25379, due to Bug #273337 , simplying the installation process a bit. Marking this as fixed. With the usage of PolicyKit and no reliance on opxml, we have simplified the installation. |