|
|
 slmingol posted this in tips & tricks on June 23rd, 2010, @ 4:53 amProblem
Sometimes you’ll get a dialog box that pops up saying that firefox is already running when you know in fact that it isn’t.
 Firefox Already Running Dialog Box Solution
This is typically caused by the existence of 2 files in your ~/.mozilla/firefox/<profile> directory. For example in my case:
1
2
3
| % ls -la ~/.mozilla/firefox/rhwevaqa.default/|egrep "lock |lock$"
lrwxrwxrwx 1 tstacct users 16 2010-06-22 18:49 lock -> 127.0.1.1:+11131
-rw-r--r-- 1 tstacct users 0 2010-06-22 18:49 .parentlock |
Just delete these 2 files and firefox should start right up.
References
For more info about Firefox startup issues check out this mozilla FAQ
NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.
slmingol posted this in tips & tricks on March 30th, 2010, @ 10:37 am
Background
From time to time I’ve run into an RPM that won’t install via yum. These usually pop up because I’ve mixed packages in from a 3rd party repository, and the 3rd party package has some overlapping files with an already installed RPM.
Problem
Here’s an example that happened to me recently on a Fedora 10 system where I was trying to install some pulseaudio related packages.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| % yum install xmms-pulse xine-lib-pulseaudio
Package xmms-pulse-0.9.4-6.fc10.i386 already installed and latest version
Resolving Dependencies
--> Running transaction check
---> Package xine-lib-pulseaudio.i386 0:1.1.16.3-2.fc10 set to be updated
--> Processing Dependency: xine-lib = 1.1.16.3-2.fc10 for package: xine-lib-pulseaudio-1.1.16.3-2.fc10.i386
--> Finished Dependency Resolution
xine-lib-pulseaudio-1.1.16.3-2.fc10.i386 from updates has depsolving problems
--> Missing Dependency: xine-lib = 1.1.16.3-2.fc10 is needed by package xine-lib-pulseaudio-1.1.16.3-2.fc10.i386 (updates)
Error: Missing Dependency: xine-lib = 1.1.16.3-2.fc10 is needed by package xine-lib-pulseaudio-1.1.16.3-2.fc10.i386 (updates)
You could try using --skip-broken to work around the problem
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest |
Solution
If you’re confident that this is a “false positive” type of error you can force your way around it like so. First download the RPM using the never mentioned command yumdownloader.
NOTE: yumdownloader is part of the yum-utils package.
1
| % yumdownloader xine-lib-pulseaudio |
Next try to install/upgrade the package.
1
2
3
| % rpm -Uvh --nodeps xine-lib-pulseaudio-1.1.16.3-2.fc10.i386.rpm
Preparing... ########################################### [100%]
file /usr/lib/xine/plugins/1.26/xineplug_ao_out_pulseaudio.so from install of xine-lib-pulseaudio-1.1.16.3-2.fc10.i386 conflicts with file from package xine-lib-1.1.16.3-18.fc10.i386 |
This is what I would consider a bogus error. For whatever reason, both RPMs share the same file, so let’s just install it already by doing a forced installation of the RPM.
1
2
3
| % rpm -Uvh --force --nodeps xine-lib-pulseaudio-1.1.16.3-2.fc10.i386.rpm
Preparing... ########################################### [100%]
1:xine-lib-pulseaudio ########################################### [100%] |
NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.
slmingol posted this in tips & tricks on March 12th, 2010, @ 11:10 am
Background
A system’s BIOS is a treasure trove of a lot of useful info about the capabilities of a computer. BIOS, which stands for Basic Input/Output System, contains information such as:
- motherboard manufacturer
- system’s serial number
- amount of RAM installed
- the CPUs speed & signature
Normally the BIOS is accessible by pressing the delete key or the F1 key while your computer is booting up.
Problem
Occasionally I’ve wanted to check out the BIOS settings of a system without having to go through the hassle of rebooting. With the help of this nifty command line tool, dmidecode, BIOS info can be had, without having to reboot.
Solution
…from the dmidecode man page…
dmidecode is a tool for dumping a computer’s DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system’s hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.
The DMI table doesn’t only describe what the system is currently made of, it also can report the possible evolutions (such as the fastest supported CPU or the maximal amount of memory supported).
SMBIOS stands for System Management BIOS, while DMI stands for Desktop Management Interface. Both standards are tightly related and developed by the DMTF (Desktop Manage- ment Task Force).
Example output from a Thinkpad T42 laptop
When you first run the dmidecode command it tells you a summary of how many structures are present within your system’s BIOS.
1
2
3
4
5
| % dmidecode
# dmidecode 2.9
SMBIOS 2.33 present.
61 structures occupying 2126 bytes.
Table at 0x000E0010. |
Each structure is represented by a handle ID which is a hex value of the form 0x001F, followed by it’s type and it’s size.
…. Continue reading → [one-liner]: Analyzing a System’s BIOS from the Command Line under Fedora, CentOS, or RHEL »»
slmingol posted this in tips & tricks on January 26th, 2010, @ 8:34 pm
Background
Recently I was trying to create a Ubuntu 9.04 vmware image using Vmware Server 1.08, but I was doing it remotely from my Fedora 10 laptop which was running Vmware Server 1.06. This can normally be done by using Vmware Server’s ability to remotely connect to other Vmware Servers.
 VMware Server Console Here’s my work flow. NOTE: Ubuntu 9.04 will be running on the vmware server on CentOS 5.4.
 VMware Workflow Problem
While going through the setup I encountered a problem I hadn’t seen before where the arrow keys didn’t appear to be working within GRUB while I was installing Ubuntu 9.04.
 broken arrow keys Solution
Turns out there is an option you can enable (i.e. set to TRUE) in the $HOME/.vmware/preferences file which fixes this.
1
| xkeymap.nokeycodeMap = "TRUE" |
NOTE: This change was made to the Vmware Server that was running on the Fedora 10 box.
…. Continue reading → Broken Arrow Keys during an Ubuntu 9.04 install on Vmware Server 1.X »»
slmingol posted this in tips & tricks on September 28th, 2009, @ 11:00 am
Background
A while back I was trying to get the vim textile plugin installed and ran into a problem. Apparently the vim that’s included with Fedora 10, 11, and CentOS 5 doesn’t include ruby support. This bug report explains what’s wrong with vim and how it’s missing ruby support. The problem is visible with this command:
1
2
3
4
| % vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind
...
... |
The –ruby tells us that ruby support isn’t enabled. The only solution I’ve seen thus far is to rebuild vim. Not really a huge deal but it’s work non the less 8-).
Rebuilding vim with ruby support
Here’s how I fixed it.
download vim Source RPM (SRPM)
1
| % wget http://mirrors.xmission.com/fedora/updates/10/SRPMS/vim-7.2.148-1.fc10.src.rpm |
confirm that ruby is installed
1
2
3
4
5
6
| % yum list installed ruby*|column -t|grep ruby
ruby.i386 1.8.6.287-2.fc10 installed
ruby-devel.i386 1.8.6.287-2.fc10 installed
ruby-irb.i386 1.8.6.287-2.fc10 installed
ruby-libs.i386 1.8.6.287-2.fc10 installed
ruby-rdoc.i386 1.8.6.287-2.fc10 installed |
make sure you have your own rpmbuild directory
1
2
3
4
| % mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
# caution with this second command if you already have your own .rpmmacros, this will overwrite!
% echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros |
rebuild vim / re-install vim
1
2
| rpmbuild --rebuild vim-7.2.148-1.fc10.src.rpm
rpm --force -Uvh /root/rpmbuild/RPMS/i386/vim-{c,e,m,X}* |
check that vim now has ruby support
1
2
3
4
| % vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind
...
... |
Ahh. a +ruby means it worked.
Textile Plugin for vim
Now onto installing the vim textile plugin.
First things first, we need to install rubygems
Next we need to install the RedCloth gem, it’s required by the textile plugin
1
2
3
4
5
6
| % gem install RedCloth
Building native extensions. This could take a while...
Successfully installed RedCloth-4.2.2
1 gem installed
Installing ri documentation for RedCloth-4.2.2...
Installing RDoc documentation for RedCloth-4.2.2... |
Finally, install the textile plugin
Downloading the textile plugin from here,
…. Continue reading → Fixing Ruby Support in Vim on Fedora 10, 11, and CentOS 5 & Installing the Vim Textile plugin »»
slmingol posted this in tips & tricks on September 27th, 2009, @ 3:17 am
Now that I’ve been using OpenVZ for several months I’d gotten to the point where I wanted/needed to “yum update” all my VEs. I currently have 11 images running on my OpenVZ Server. I thought I could just vzctl exec … yum -y update all the VEs, but quickly ran into some issues with this brute force approach. Doing the yum -y update broke several of my VEs so I opted to restore the unrecoverable ones from backups.
For my second attempt, I opted to do each VE independently, to get a better understanding of what the best approach would be for doing mass upgrades like this now, and in the future. The first hurdle to overcome had to do with some of the VEs running out of memory (RAM) during the upgrade process.
NOTE: A VE = Virtual Environment (aka. a virtual host), while HN = Host Node
Issue #1, not enough RAM for yum to run
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| # RAM budgets for VEs
# NOTE: values are in # of pages (1 pg. = 4K)
% (printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources)|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 31904 82215 65536 69632 2
/proc/bc/102/resources: privvmpages 119803 196620 166400 179200 9517
/proc/bc/103/resources: privvmpages 27125 35974 65536 69632 0
/proc/bc/104/resources: privvmpages 56251 107250 104960 115200 0
/proc/bc/105/resources: privvmpages 73559 82926 98304 103304 0
/proc/bc/106/resources: privvmpages 30219 68097 65536 69632 0
/proc/bc/108/resources: privvmpages 30081 84291 65536 69632 1
/proc/bc/109/resources: privvmpages 32790 74199 98304 103304 0
/proc/bc/110/resources: privvmpages 40497 69408 65536 69632 1
/proc/bc/111/resources: privvmpages 26990 35371 65536 67840 0
# NOTE: converted the columns to megabytes (MB), it's just easier to read
(printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources|awk '{sub($3,$3*4096/2^20) sub($4,$4*4096/2^20) sub($5,$5*4096/2^20) sub($6,$6*4096/2^20)}1')|column -t
vm feature held maxheld barrier limit failcnt
/proc/bc/101/resources: privvmpages 124.625 321.152 256 272 2
/proc/bc/102/resources: privvmpages 467.98 768.047 650 700 9517
/proc/bc/103/resources: privvmpages 105.957 140.523 256 272 0
/proc/bc/104/resources: privvmpages 219.73 418.945 410 450 0
/proc/bc/105/resources: privvmpages 287.34 323.93 384 403.531 0
/proc/bc/106/resources: privvmpages 118.043 266.004 256 272 0
/proc/bc/108/resources: privvmpages 117.504 329.262 256 272 1
/proc/bc/109/resources: privvmpages 128.086 289.84 384 403.531 0
/proc/bc/110/resources: privvmpages 158.191 271.125 256 272 1
/proc/bc/111/resources: privvmpages 105.43 138.168 256 265 0 |
According to this data 4 of the 11 images had gone over their allocation of RAM. So I tried restarting these and re-running yum update within the problem VEs. Again the update failed and so I needed to increase their allocation of memory. I didn’t want to devote more memory permanently, just a enough temporarily to do the upgrade. So I used this trick to temporarily bump up a VEs allocated memory.
1
2
3
4
5
6
7
8
9
| # increase the RAM by 100MB
vzctl set 101 --privvmpages $((256+100))m:$((272+100))m --save
# ...
# do the upgrade (yum update)
# ...
# decrease the RAM back to the original value
vzctl set 101 --privvmpages 256m:272m --save |
For the remaining 3 VEs that needed additional memory I used these commands to increase their allocations of RAM
1
2
3
4
5
6
7
8
9
| # cmds. to increase RAM by 100MB
vzctl set 102 --privvmpages $((650+100))m:$((700+100))m --save
vzctl set 108 --privvmpages $((256+100))m:$((272+100))m --save
vzctl set 110 --privvmpages $((256+100))m:$((272+100))m --save
# cmds. to decrease
vzctl set 102 --privvmpages 650m:700m --save
vzctl set 108 --privvmpages 256m:272m --save
vzctl set 110 --privvmpages 256m:272m --save |
Issue #2, not enough diskspace for yum to run
The next snag I ran into had to do with a couple of the VEs running out of diskspace. And here’s the commands I used to reconfigure more diskspace.
…. Continue reading → Keeping CentOS 5 OpenVZ images up to Date with Yum »»
|
June 23rd, 2010, @ 4:53 am |
Tags: 
Category: 
