Problem installing PostgreSQL with APT
sudo apt-get update
sudo apt-get upgrade --show-upgraded
sudo apt-get install postgresql
When I run these commands, I get this error message:
Reading package lists… Done
Building dependency tree
Reading state information… Done
You might want to run ‘apt-get -f install’ to correct these:
The following packages have unmet dependencies:
postgresql : Depends postgresql-9.1 but it is not going to be installed
Now as I understand it, the advantage to using APT to install a package is that it will automatically install any dependent packages for you. On my EC2 instance, I could run the same commands as above and APT there would install all of postgresql's dependencies as well as postgresql itself.
Why doesn't APT on Debian install postgresql? Shouldn't it work the same here since Ubuntu is an offshoot of Debian?
Thanks!
8 Replies
1. I had some broken dependencies.
2. My root disk was full so I couldn't run "sudo apt-get -f install" to repair the broken dependencies.
Solution:
1. Create a new disk partition for /usr so I had room to install missing packages.
2. Run "sudo apt-get -f install" to fix the broken dependencies. This entailed installing the missing packages.
Perhaps I'm missing something. What do you suggest?
Thanks.
Debian places both the web root and the MySQL data storage under /var by default, along with all the logs and other stuff that "varies" over time. So /var is the only partition that really grows over time unless you have your web root under /home or some other path. Besides, a lot of web apps don't grow in size at all
It's also ridiculously easy to resize disks here, since all disks are virtual. With a physical disk in a physical server, you have to move partitions around if you want to resize anything in the middle, so it's important to get all the sizes right the first time. With virtual disks, it doesn't matter. If one of your disks grows too large, you can easily redistribute storage among your disks or upgrade your Linode for more storage. It only takes a few minutes and a reboot, which is nothing compared to the hassle of resizing partitions on a physical server.
Finally, this isn't EC2/EBS. Unless something has changed with the recent per-hour billing announcement, you don't get any discount for unallocated disk space. So it's best to allocate all the space that comes with your Linode. There's no reason to have a root partition smaller than a couple of GB's when you have 48GB or more to play with.
@rlfprog:
With virtual disks, does it not take any more time to access three different directories on the same partition as it would if they were on three different partitions? Thanks.
I think this falls under the category of "things that Linode doesn't want you to care about". How the disks are provisioned is an implementation detail that can change at any time, especially since they've been experimenting with SSDs lately. You have zero control over the physical location of your disk images on the actual platters.
Anyway, I'm guessing that there won't be a huge difference between one partition and multiple partitions because everything resides on the same RAID 10 array. Any difference will probably be due to how the kernel handles filesystems. But you could run some benchmarks if you're really curious
@Guspaz:
I don't believe its been true with real hard disks since the 90s either. Multiple partitions would reduce performance, if anything, by forcing additional seeking.
Agreed, I did the multiple partition thing once back then, the performance was bad. Fortunately RAID for the average consumer eventually came along and we could go back to one big partition or two.
Oh and the two times I really needed my expensive tape backup to work…it didn't. rsync and RAID or even just rsync saves the day.