On Wed, Aug 6, 2008 at 7:38 PM, John Summerfield <debian(a)herakles.homelinux.org&gt; wrote: > What it wants is to download 1.7 Gbytes of stuff. I don't have that much > free space[1], but mounting a USB drive is possible. You've left out quite a few details if a 1.7 GB problem requires a 320 GB solution.

> What mount point should I use, and what do I need to copy to the drive > before mounting it there? /var/cache/yum Nothing needs to be copied, unless you wanted to preserve what has already been downloaded, but "yum clean all" took care of that...

> [1] To solve that properly requires acquiring a drive larger then 320 Gbytes > and cloning the existing drive - adding a drive isn't possible. F10 has to > suit me better than F9 does, or I'm more likely to give the space to > Windows. I won't even take *that* bait... :-)

On Wed, Aug 6, 2008 at 8:13 PM, John Summerfield <debian(a)herakles.homelinux.org&gt; wrote: > xen on F9 is basically useless (in my hands). > KVM is better, but prone to hanging guests. I was wondering... having heard that I won't go there... for production use anyway...

> VirtualPC and VirtualServer work. Good to know.

Mine will be my desktop work environment, so also needs the latest features in user interface, heterogeneous systems, and sadly, Windows - virtual and/or emulated.

I'm not familiar with VirtualServer. However, VirtualBox runs quite nicely on Fedora 9 for me.

On Thu, Aug 07, 2008 at 03:06:05PM +0800, John Summerfield wrote: > Scott Robbins wrote: > > > I have to say I'm impressed with VirtualBox:-( > > I downloaded it on my CentOS5 system , and then > rpm -ivh ... > and too a brief comfort break. > Came back to see the grub menu vanish as the system began booting. > > VirtualBox didn't start. A quick investigation showed no kernel module and no > magic kernel builder package (not mentioned as a prereq??). > "make && make install" in the right directory got the module. Great software, poor documentation, especially for RH based systems. If you're not yet disgusted with it, would you please try again after doing yum -y install gcc gcc-c++ make kernel-devel Like many things, it does require the basic build tools. (I've found that the above will almost always pull in everything else I need as deps, e.g., kernel-headers. I should put up a quick start guide, and probably will at some point. After adding the above programs, if your user name is john, as root or with root privilege gpasswd -a john vboxusers Log out completely as john, log back in, make sure you're a member of vboxusers. service vboxdrv setup This will take a little while, but even with a relatively slow box, probably less than 3 minutes. You should see that it completed successfully, making it unnecessary to do a modprobe. It will probably add the vboxdrv to automatically start upon boot--if that's OK, fine, if not then fix it with chkconfig or your tool of choice.

On Thu, Aug 07, 2008 at 03:06:05PM +0800, John Summerfield wrote: > Scott Robbins wrote: > > > I have to say I'm impressed with VirtualBox:-( > > I downloaded it on my CentOS5 system , and then > rpm -ivh ... > and too a brief comfort break. > Came back to see the grub menu vanish as the system began booting. > > VirtualBox didn't start. A quick investigation showed no kernel module and no > magic kernel builder package (not mentioned as a prereq??). > "make && make install" in the right directory got the module. Great software, poor documentation, especially for RH based systems. If you're not yet disgusted with it, would you please try again after doing yum -y install gcc gcc-c++ make kernel-devel Like many things, it does require the basic build tools. (I've found that the above will almost always pull in everything else I need as deps, e.g., kernel-headers.

I should put up a quick start guide, and probably will at some point. After adding the above programs, if your user name is john, as root or with root privilege gpasswd -a john vboxusers

Log out completely as john, log back in, make sure you're a member of vboxusers. service vboxdrv setup

This will take a little while, but even with a relatively slow box, probably less than 3 minutes. You should see that it completed successfully, making it unnecessary to do a modprobe. It will probably add the vboxdrv to automatically start upon boot--if that's OK, fine, if not then fix it with chkconfig or your tool of choice. By default, like qemu, it uses NAT networking. If that's OK for your needs, well and good, if you want it to be a separate host on the LAN, I have a page on that part of it, at http://home.nyc.rr.com/computertaijutsu/vboxbridge.html since their docs

for bridging in Fedora were incomplete last time I looked. > modprobe ... > Instant panic, system reboots. > Defaults to same kernel, panics and reboots.... I've never run into that with it, especially on CentOS. With CentOS, it's always been a pretty smooth install.

Jerry Amundson wrote: > On Wed, Aug 6, 2008 at 7:38 PM, John Summerfield > <debian(a)herakles.homelinux.org&gt; wrote: >> What it wants is to download 1.7 Gbytes of stuff. I don't have that much >> free space[1], but mounting a USB drive is possible. > > You've left out quite a few details if a 1.7 GB problem requires a 320 > GB solution. > See below, I need to buy a new drive and clone and retire the existing drive. There's no space for a new drive.

On Thu, Aug 07, 2008 at 09:13:40AM +0800, John Summerfield wrote: > Jerry Amundson wrote: >> On Wed, Aug 6, 2008 at 7:38 PM, John Summerfield >> <debian(a)herakles.homelinux.org&gt; wrote: >>> What it wants is to download 1.7 Gbytes of stuff. I don't have that much >>> free space[1], but mounting a USB drive is possible. >> You've left out quite a few details if a 1.7 GB problem requires a 320 >> GB solution. >> > See below, I need to buy a new drive and clone and retire the existing > drive. There's no space for a new drive. Well, another solution is "delete 1.7 GB of data". You could for example remove -devel packages (and definately debuginfo if you have any): yum remove \*-devel \*-debuginfo

and if that doesn't give enough space, consider temporarily removing some applications to free up enough space to do the update, then put them back after, e.g.: yum groupremove 'Office/Productivity' Check for huge logfiles in /var/log and delete or compress old ones, etc.

John Summerfield wrote: > The first step in recovering wasted space is to find where it's used. > Deleting installed software isn't going to recover anything like 1.7 > Gbytes (it's about all of the installed software). John: have you installed baobab {Disk Usage Analyzer} ?

I find it's really helpful at visualizing the big consumers.

John Summerfield wrote, On 08/07/2008 02:22 AM: > Chuck Anderson wrote: >> On Thu, Aug 07, 2008 at 09:13:40AM +0800, John Summerfield wrote: >>> Jerry Amundson wrote: >>>> On Wed, Aug 6, 2008 at 7:38 PM, John Summerfield >>>> <debian(a)herakles.homelinux.org&gt; wrote: >>>>> What it wants is to download 1.7 Gbytes of stuff. I don't have >>>>> that much >>>>> free space[1], but mounting a USB drive is possible. >>>> You've left out quite a few details if a 1.7 GB problem requires a 320 >>>> GB solution. >>>> >>> See below, I need to buy a new drive and clone and retire the >>> existing drive. There's no space for a new drive. >> >> Well, another solution is "delete 1.7 GB of data". You could for >> example remove -devel packages (and definately debuginfo if you have >> any): >> >> yum remove \*-devel \*-debuginfo > And if my -devel packages are essential? >> >> and if that doesn't give enough space, consider temporarily removing >> some applications to free up enough space to do the update, then put >> them back after, e.g.: >> >> yum groupremove 'Office/Productivity' >> >> Check for huge logfiles in /var/log and delete or compress old ones, >> etc. >> > > My space vanishes in chunks of several gigabytes; it's chock fill of > (not very functional) virtual computers. > > I'm well-practiced at recovering space; if I need to resort to those > measures, a new disk drive is cheaper. > > The first step in recovering wasted space is to find where it's used. > Deleting installed software isn't going to recover anything like 1.7 > Gbytes (it's about all of the installed software). > After reading all of the above, I have three possible suggestions: 1) you can mkdir myempty;cd myempty yum update oof* yum clean all yum update kde* yum clean all yum update gn* yum clean all yum update i.e., update the large chunks and then there will be less to update in one chunk. 2) get a large (bigger than 2GB) USB mass storage device and mount /dev/myExt[23]FormattedUsbDrive /var/cache/yum yum update

3) get a really large (bigger than 20 GB) USB mass storage device and get a mirror of the development repository on it,

modify /etc/yum.repos.d/fedora-updates.repo to point to baseurl=file:///where/my/big/repo/is/at and comment (put a # at the begging of the line) the mirrorlist=. [yum is apparently smart enough to know that if the files are on a file system it can access, it does not need to copy them before using rpm on them.] yum update