(This works for me on Debian, but probably works on similar systems as well.)
If your grub menu does not list an OS partition which you know is installed, try running update-grub. If it still isn't listed, try installing os-prober (apt-get install os-prober). This is a program designed to locate non-linux OSes. Run sudo os-prober. Hopefully, it will detect the Windows installation you want it to, and it will print out a line indicating the device name and detected OS. If it doesn't, I can't really help you, but your next step would be to somehow get os-prober to detect the installation. Assuming you have os-prober detecting the OS as you want it too, try running update-grub again. It will print out a line indicating that it has detected the installation. When you reboot, the option should appear on the grub menu.
If os-prober is detecting the OS, but update-grub isn't, look for the file /etc/grub.d/30_os-prober (or something similar), that is the problem (either it isn't installed there, or it is misconfigured).
This really should be the first step you take if it isn't detecting a windows install properly. No need to do Wndows MBR recovery or any sort of custom grub.d configuration.
EDIT: I found that there can also be issues detecting the install if the Windows 7 bootmgr is corrupted (don't ask me how that happened). If you start up the windows recovery environment (you can download a recovery CD iso easily if you google) and then recover the boot manager, os-prober will now detect the install. Just run update-grub to add it to the startup menu.
Saturday, August 14, 2010
Thursday, August 12, 2010
Building Tartini on Debian
Tartini is a cool real-time "music analysis" program (http://miracle.otago.ac.nz/tartini/index.html). The issue is that the sources don't immediately compile on my Debian system.
UPDATE: I've actually gone through and fixed all the issues and created a Debian package for it. You can download the source at https://github.com/jeremysalwen/tartini-debian Hopefully it will be in debian too soon.
Obviously, as the instructions say, qt 4, fftw 3, and qwt 5 must be installed for it to compile. Installing the packages fftw3-dev and libqt4-dev is straightforward. Make sure that if qt3 is installed, all of the build tools point to the qt4 versions. However, be careful with qwt, as the debian repositories contain a package "qwt-dev" which is not version five. Instead, install libqwt5-qt4-dev.
As the build instructions state, you then have to modify pitch.pro to tell it where the includes and libraries are. On a typical debian system, the important part of the file should look like:
unix{
macx{ #MacOSX
MY_LIB_PATH += -L/Users/student/usr/local/lib
MY_INCLUDE_PATH += /Users/student/usr/local/include
}else{ #Linux
MY_LIB_PATH += -L/usr/lib
MY_INCLUDE_PATH += /usr/include/qt4 /usr/include/qwt-qt4 /usr/include
}
}
Then, qmake will still give you the error
RCC: Error in 'pitch.qrc': Cannot find file 'pics/tartinilogo.png'
For some reason it's looking for a png when the file is really a jpg. Just modify pitch.qrc to replace tartinilogo.png with tartinilogo.jpg
qmake will then work, but make will still complain about
error: invalid conversion from ‘const char*’ to ‘char*’
a bunch of times. mystring.cpp and mystring.h are the offending files. Basically there is a bunch of code that seems to be just *wrong* in how it handles constness. If you make the local variable "char * ext;" into "const char * ext;" in two functions, and make getFileExtension return type "const char*" instead of "char*", it will work. (don't forget to change the function in both the cpp and the header file.
Meanwhile, prony.cpp gives a cryptic warning about the included file "cstdio", which seems to be caused by the line:
#define _GLIBCXX_USE_C99
I am not really sure if this affects the functionality of the code, but when I comment it out, it compiles and runs fine. Apparently there is strange functionality surrounding this symbol anyway: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443234
You will also get a linking error because it tries to link with -lqwt, when the qwt5 package only provides qwt-qt4. Again, under the linux section of pitch.pro, replace the line
LIBS += $$MY_LIB_PATH -lfftw3f -lqwt -lasound
with
LIBS += $$MY_LIB_PATH -lfftw3f -lqwt-qt4 -lasound
Still, when you build it, it segfaults when you try to run fixing up calculateAnalysisData in mytransforms.cpp, we replace
if(chunk > 0 ) {
with
if(chunk > 0 && prevAnalysisData->highestCorrelationIndex!=-1) {
To stop the segmentation fault if the previous highest correlation index is -1 (not found).
And that should be enough to get a working Tartini build on Debian. I would post a diff or a zip of all the corrections, but I can't attach it here.
UPDATE: I've actually gone through and fixed all the issues and created a Debian package for it. You can download the source at https://github.com/jeremysalwen/tartini-debian Hopefully it will be in debian too soon.
Obviously, as the instructions say, qt 4, fftw 3, and qwt 5 must be installed for it to compile. Installing the packages fftw3-dev and libqt4-dev is straightforward. Make sure that if qt3 is installed, all of the build tools point to the qt4 versions. However, be careful with qwt, as the debian repositories contain a package "qwt-dev" which is not version five. Instead, install libqwt5-qt4-dev.
As the build instructions state, you then have to modify pitch.pro to tell it where the includes and libraries are. On a typical debian system, the important part of the file should look like:
unix{
macx{ #MacOSX
MY_LIB_PATH += -L/Users/student/usr/local/lib
MY_INCLUDE_PATH += /Users/student/usr/local/include
}else{ #Linux
MY_LIB_PATH += -L/usr/lib
MY_INCLUDE_PATH += /usr/include/qt4 /usr/include/qwt-qt4 /usr/include
}
}
Then, qmake will still give you the error
RCC: Error in 'pitch.qrc': Cannot find file 'pics/tartinilogo.png'
For some reason it's looking for a png when the file is really a jpg. Just modify pitch.qrc to replace tartinilogo.png with tartinilogo.jpg
qmake will then work, but make will still complain about
error: invalid conversion from ‘const char*’ to ‘char*’
a bunch of times. mystring.cpp and mystring.h are the offending files. Basically there is a bunch of code that seems to be just *wrong* in how it handles constness. If you make the local variable "char * ext;" into "const char * ext;" in two functions, and make getFileExtension return type "const char*" instead of "char*", it will work. (don't forget to change the function in both the cpp and the header file.
Meanwhile, prony.cpp gives a cryptic warning about the included file "cstdio", which seems to be caused by the line:
#define _GLIBCXX_USE_C99
I am not really sure if this affects the functionality of the code, but when I comment it out, it compiles and runs fine. Apparently there is strange functionality surrounding this symbol anyway: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443234
You will also get a linking error because it tries to link with -lqwt, when the qwt5 package only provides qwt-qt4. Again, under the linux section of pitch.pro, replace the line
LIBS += $$MY_LIB_PATH -lfftw3f -lqwt -lasound
with
LIBS += $$MY_LIB_PATH -lfftw3f -lqwt-qt4 -lasound
Still, when you build it, it segfaults when you try to run fixing up calculateAnalysisData in mytransforms.cpp, we replace
if(chunk > 0 ) {
with
if(chunk > 0 && prevAnalysisData->highestCorrelationIndex!=-1) {
To stop the segmentation fault if the previous highest correlation index is -1 (not found).
And that should be enough to get a working Tartini build on Debian. I would post a diff or a zip of all the corrections, but I can't attach it here.
Thursday, August 5, 2010
Wireless issues on Eeepc under linux
I was running into issues with network-manager (nm-applet) on my Eepc, where at one point I disabled the wireless networking by right clicking on it, but when I attempted to re-enable it, the check box was grayed out. Restarting and killing the applet did nothing. In addition, when I tried to connect using iwconfig and iwlist, I was getting errors with "network down". It seems that at least in my case, the issue was that the interface wlan0 was "down", the solution being "ifconfig wlan0 up". However, when I tried running that command, I would get the error "SIOCSIFFLAGS unkown error 132". After some amount of googling, it appears that this error is because of a hardware off switch on the laptop for the wireless. Confusingly, the Eeepc only had a key combo to disable the wireless, and I was under the impression that it wasn't working under linux, as most of the other hardware hotkey combos didn't. By pressing Fn-F2, I was able to toggle the Wireless card, and I noticed the little wireless light went on and off. Surprisingly, it was very inconsistent. If I pressed it once, sometimes the light and error wouldn't change. Other times, It would change the light, but get a different error message from ifconfig. The light sometimes would indicate that it was on, sometimes indicate that it was off. I figured out that if I pressed it four times and tried ifconfig between each press, at least one of the times it would run without an error.
Turning on the hardware switch meant that the wlan0 interface was "up", allowing me to run iwlist and iwconfig. However, the issue still remained with network-manager. Although I assume that the box was initially greyed out because of the hardware switch, it wouldn't un-grey out even when the wireless was back up. I realized that it was saving the "enabled" state in a configuration file somewhere. After editing /var/lib/NetworkManager/NetworkManager.state and setting "WirelessEnabled=true", I restarted nm-applet (/etc/init.d/network-manager restart), and suddenly wireless worked again. Although all the information you need to solve this problem is online, it took several levels of indirection to find it, and a lot of slogging through Ubuntu bug-reports. I figured I'd compile all the information together here.
Turning on the hardware switch meant that the wlan0 interface was "up", allowing me to run iwlist and iwconfig. However, the issue still remained with network-manager. Although I assume that the box was initially greyed out because of the hardware switch, it wouldn't un-grey out even when the wireless was back up. I realized that it was saving the "enabled" state in a configuration file somewhere. After editing /var/lib/NetworkManager/NetworkManager.state and setting "WirelessEnabled=true", I restarted nm-applet (/etc/init.d/network-manager restart), and suddenly wireless worked again. Although all the information you need to solve this problem is online, it took several levels of indirection to find it, and a lot of slogging through Ubuntu bug-reports. I figured I'd compile all the information together here.
Subscribe to:
Posts (Atom)