This celebration season post covers installation of the VirtualBox guest additions on Fedora while using yum to update the kernel sources.
The steps were tested in Fedora 13 (GNOME), Fedora 14 (GNOME), and Fedora 15 (XFCE and KDE). A common problem in installing the guest additions on a new copy of Fedora is the guest additions install will complain about missing kernel sources. These steps show how to update the kernel sources to fix this problem and allow a successful install of the guest additions.
OS Set Up and Installation of Guest Additions
1) First update the kernel by typing following command.
yum -y update kernel
The latest kernel will be downloaded and updated.
2) Type following command after the kernel update.
After that, restart the Fedora virtual machine (VM).
3) Go to devices in VirtualBox console and select Install Guest additions.
This action will mount the VirtualBox guest additions and it will be visible on your desktop if it mounted successfully. Alternatively, you can find it in the file system (e.g. /media/VBox Additions CD).
4) Open a console terminal. Change directory to the Vboxadditions CD and run the following command.
sudo sh VBoxLinuxAdditions.run
Note: To run sudo you must be part of the /etc/sudoers file – e.g.
# User privilege specification
yourusername ALL=(ALL) ALL
or part of a Unix/Linux administration group.
5) It is possible after running the VirtualBox additions that you still need to install the current kernel-devel (files used for building kernel modules) in yum. In which case, the VBox additions install will tell you what to install (see an example below). After installing the kernel-devel, try running the VirtualBox additions installation again (sudo sh VBoxLinuxAdditions).
Building the VirtualBox Guest Additions kernel modulesThe headers for the current running kernel were not found. If the following module compilation fails then this could be the reason.The missing package can be probably be installed withyum install kernel-devel-2.6.32-100.28.5.el6.x86_64
Check the installation log to verify everything works.
Shared Folders
If you’re using shared folders, check the VirtualBox documentation on using them. Usually the thing you have to do after setting up your host to share folders with the Fedora guest is to add the Linux user you are using to the vboxsf user group.
Add a user to a group
Usermod is a command to change a user’s account settings.To add a user to a group, use the following: $ usermod -a -G newGroup username
Make sure to use the -a option so the user is added to newGroup while continuing to be a member of other groups. Otherwise the user is removed from all groups and only added to newGroup.
If you are experiencing low, degraded, or bad audio quality in the movies you created in Windows Movie Maker 2.6 (MM 2.6), check out possible solutions below.
The solutions are aimed at when you are adding audio to a movie such as adding soundtracks with wav and mp3 files. The quality of these input audio files may be high, but for some reason the output file (movie file you save) and the movie preview (storyboard or timeline) in MM has worse audio quality than the audio files you used for the soundtrack of the movie.
Check existing codecs
Playback issues for movies are often related to codecs installed on your machine. Codecs are likely the cause of most sound input issues since MM may use different codecs for playback when the audio files are in your collections as supposed to when the audio file is now part of your soundtrack. Solving issues with codecs is difficult since everyone computer will have different ones installed and being used during the MM preview and playback. Possible solutions are:
Observe if codec icons show up during movie playback or preview. Check the options for these codec icons.
Change audio codecs: you could uninstall audio codecs being used and use the Window defaults or install new audio codecs.
For advanced users, use a tool like G-Spot and check if you have the required codecs for an audio file installed.
Check Windows Movie Maker filters
In Windows Movie Maker, try going to “Tools > Options > Compatibility” and unchecking all the filters ending in .ax. It is possible these .ax filters are causing low audio quality in the movie preview and saving. This solution is common if you have installed a bunch of new codecs and filters. Also, if audio quality was fine before and now is low, it may be due to installation of new filters.
When saving the movie…
Check audio export settings during saving of movie
After you have completed your editing in MM and are ready to save your movie, look in “other settings” and select the appropriate audio settings. Note configuration of settings may work best with WMV output and may not solve problems with people saving to DV formats.
Convert soundtrack files to stereo or use alternative profiles when saving
Use alternative output file profiles (either the Windows Movie Maker defaults or custom profiles) within MM when saving the movie. Sometimes your audio may be configured to be mono only or stereo only which affects the soundtrack in the saved movie. WMV formats may allow more customization.
Audio file tuning
Here are possible solutions to common audio problems. They may not be useful if you really have codec issues, but can work if there are problems with the audio files used for your movie soundtrack.
If using MP3s, convert MP3s to wav. Use Audacity/TMPGEnc if you need to convert audio channels on sound files (e.g. mp3, wav) used in your soundtrack.
Play around with MP3 bitrate: e.g. if MP3 is at 256Khz, reduce it to 192Kbps @ 44.1kHz.
When running Windows, operating system tools allow you to find the mapping of a open TCP/UDP ports to a running service or application.
Netstat: Displays protocol statistics and current TCP/IP network connections
Use
> netstat /?
to find information about the options and usage for the command. To find all connections and listening ports, use:
> netstat -abo
To list the executables used in creating those connections, and finding the process ID for each connection. Using these commands, you can find all the open ports and process IDs listening on the system you are executing the netstat.
Task manager: Matching process IDs to processes
After obtaining the process ID from netstat, Windows Task Manager can be used to find out what those processes are. First add the PID column to the Task Manager processes list. After that, look for the process IDs you are interested in and found from netstat.
Tasklist: Getting service executable information
svchost.exe is a common service found in the task manager process list and sometimes there are several instances.
If you are using XP Professional, Vista, or Windows 7, to find more information on svchost, use the following command
tasklist /SVC
to find the executable name, process ID, and possibly some service information details.
To help users in troubleshooting problems with network connectivity and firewall rule implementations, included below are step by step commands one can execute on a Windows or Unix system.
Step 1: Confirm network connectivity
On the source server, perform a operating system level connectivity test on established ports from source server/firewall to destination server/firewall. The test should verify routing, network address translation, ports, and URLs where applicable.
Telnet
Telnet is a good command to start your network connectivity tests. Open a command prompt on your server (e.g. cmd.exe or Powershell on Windows and a console or SSH session in Unix) and execute the following:
Note for Windows 7 users, you may have enable the Telnet client/command. To enable telnet on Windows 7, search in the start menu for “Turn Windows features on or off”. Click into that menu item and turn on the “Telnet client”.
If there is connectivity from the source server to the destination, the telnet session should begin. On Windows and Unix, a blank screen or area should appear with a prompt. If there is no connectivity, it will just hang after the telnet command like the following:
Connecting To <destination_server>…
and then finally show:
Connecting To <destination_server>…Could not open connection to the host, on port <destination_port>: Connect failed.
Telnet hang on Windows PowerShell. Same thing happens on the normal cmd.exe window.
Moments later, we know the connectivity failed.
Other Telnet Failures
It is also possible you receive a message:
telnet: Unable to connect to remote host: Network is unreachable
This telnet message could occur from:
Routing issues – Try a ping to the destination server (ping <destination>). Hopefully the ping is successful, if not check the netstat -rn to examine gateways used for routing. It could be that a static/alternatve route needs to be created to the destination server using an alternative gateway.
Network infrastructure down – It is possible a piece of the network on the path to your destination server is down.
Incorrect information in telnet command - Make sure the IPs or fully qualified domains you are using in telnet are correct.
Terminology
<source_server> is the server we are coming from and where the command is being executed on the operating system. The firewall should be opened from the source server and its source ports to the destination server and its destination ports.
<destination> is the destination server IP or fully qualified domain name (FQDN). The IP should work whether you are using an IPv4 or IPv6 address. However, if you are testing IPv6 connectivity, it is likely you will use a FQDN due to the long length of IPv6 addresses.
<destination_port> is the port on the destination server you are trying to get to. The destination server should be listening on this port. The following command (netstat -a) can be used on the destination server to check if the port is listening and you should be looking for the port after the IP address and whether its state is listening:
$ netstat -a
Proto Local Address Foreign Address State
TCP 10.86.32.211:80 fcore:0 LISTENING
In this example, we know the machine where we are executing the command is listening on port 80 on the IP address 10.86.32.211.
If there is no connectivity, follow steps below for troubleshooting procedures.
Step 2: Check other stuff
Check firewall rule and network implementation
Check you have the right IPs, fully qualified domain names (FQDN), and ports for the servers. Sometimes firewall rules are not requested properly and more work needs to be done to make connectivity happen such as:
Security: VPN configuration, If applicable, ensure SSL certificate trust is in place and/or certificate exchanges installed and in place (e.g. 1-way, 2-way SSL certificates installed, and destination network can see successful SSL handshakes).
Servers may have several IPs – make sure the correct ones are used and seen on the firewall(s)
Another type of test: Application Interface Test (depending on application availability)
This type of testing occurs from the application running on the source server and is common if you do not have access to the servers themselves and may be easier to perform. In this test, the application on the source server generates a test message/request to be received on the destination server interface and source confirms a valid response. This test confirms URL in place and basic messaging interface is available.
Step 3: Network connectivity troubleshooting on server
1. Test Connectivity on source server(s)
a. Initial test by server operator:
Telnet to destination IP via destination port. If IPs are using network address translation (NAT), choose the appropriate IP from source server – the IP the firewall sees and translates from the source server.
b. If telnet fails:
Check if static routing is done in source server routing table. Make sure routing goes to the correct default gateway and ping default gateway to check if it works.
Netstat – Checking the IP configuration on the server
netstat -rn
to check IP configuration on server and:
ping <destination_server>
Runs in Windows natively and in Unix sometimes under /usr/sbin/ping
c. If server routing table is ok:
Conduct the telnet test while having network resources monitor firewalls between source and destination points.
d. If traffic is not picked up on firewall:
Check points along the network path. If possible trace the network route. Traffic bound for the destination address should be monitored in case source server IPs are not seen on the firewall.
Traceroute – Find network routes
Use:
/usr/sbin/traceroute
to destination server and check for default gateway (assuming devices along the way do not have ICMP blocked).
Step 4: Network protocol/packet analyzers
If you have exhausted the steps outlined above and there is still no connectivity …
you may have to use logging tools and applications traces.
The use of Wireshark, TCPdump, or similar tools for network protocol and packet analysis on the source and/or destination servers and firewalls will aid in the troubleshooting by checking for abnormalities or errors in packets.
Analyzing application logs
If you are working with applications that need the network connectivity, you can enable verbose logging on the application. When testing web services, you can enable logging for protocol level APIs. For example, if a Java application is a web service client and is connecting to the web service endpoint, we could enable logging of the HTTP implementation in Java via JVM arguments or look at the verbose logging of the Java SSL or Java Secure Socket Extension (JSSE) APIs.
After obtaining the process ID from netstat, Windows Task Manager can be used to find out what those processes are. First add the PID column to the Task Manager processes list. After that, look for the process IDs you are interested in and found from netstat.
svchost.exe is a common service found in the task manager process list and sometimes there are several instances.
