Re: [vox-tech] I'm out of space on /
Quoting Ken Bloom ([EMAIL PROTECTED]): > Still won't work. after mv moves the /lib somewhere else, the ln command > won't be able to find the libs it needs to run. Yes, indeed. I'm aware of that. I was just expressing the general principle that you would want to combine the mv and the ln when moving _any_ important subtrees. I already said that I _would not move_ /lib off the root filesystem, on a number of obvious general principles; the fact that doing so breaks SO links (presumably unless you _also_ first update /etc/ld.so.conf and run ldconfig) was interesting but academic. > You might be able to get away with a statically linked copy of ln, but > to be much safer, the way to avoid this problem is to use the version > of busybox (a shell with lots of basic commands built-in) which is > statically linked, from the package busybox-static. Thanks, but I'd _greatly_ prefer to do any maintenance on that level of invasiveness from separate maintenance media, for lots of reasons. > By the way, moving /lib out of the way may make a whole lot of > difference becuase the system can't free the space from the disk anyway > until no applications are using those libraries -- despite the fact that > you've unlinked them, they still need to be on disk until they are no > longer in use. As I said, this whole thing is rather academic since moving /lib just isn't the right solution in the first place, but surely one wouldn't be crazy enough to attempt such things on anything but a highly quiescent system. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Rick Moen wrote: > Quoting Jay Strauss ([EMAIL PROTECTED]): > > Will moving the contents of lib somewhere else, like /usr/mylib and soft linking /lib->/usr/mylib work as a workaround? Will my machine be able to boot correctly? >>> >>>I see no reason why not -- but personally I'd find some other >>>(long-term) solution. >> >>Well I can tell you, it sure doesn't work on a live system. I moved >>/lib and afterward had no unix commands at my disposal. Had to boot >>with knoppix and repair my error > > > Er, I'd assumed that, if at all, you'd have done something > all-in-one-step so that the shell lands on a sane system, like this: > > # cd / > # mv /lib /usr/cruciallibs && ln -s /usr/cruciallibs /lib > > ...and I'd still have kept that maintenance disk handy. ;-> Still won't work. after mv moves the /lib somewhere else, the ln command won't be able to find the libs it needs to run. You might be able to get away with a statically linked copy of ln, but to be much safer, the way to avoid this problem is to use the version of busybox (a shell with lots of basic commands built-in) which is statically linked, from the package busybox-static. By the way, moving /lib out of the way may make a whole lot of difference becuase the system can't free the space from the disk anyway until no applications are using those libraries -- despite the fact that you've unlinked them, they still need to be on disk until they are no longer in use. --Ken Bloom -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. signature.asc Description: OpenPGP digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
On Thu, Jun 30, 2005 at 12:12:36PM -0700, Rick Moen wrote: > Quoting Micah J. Cowan ([EMAIL PROTECTED]): > > [noatime on some filesystems:] > > > Well, yeah: but only of the directory, yes? > > And subdirectories thereof, if/when they are stat'ed. > > > (Brief experimentation seems to confirm this.) Seems like an > > incredibly small advantage. > > It cost me all of seven one-time keystrokes per filesystem. Heh. Excellent point! -- Micah J. Cowan [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Micah J. Cowan ([EMAIL PROTECTED]): [noatime on some filesystems:] > Well, yeah: but only of the directory, yes? And subdirectories thereof, if/when they are stat'ed. > (Brief experimentation seems to confirm this.) Seems like an > incredibly small advantage. It cost me all of seven one-time keystrokes per filesystem. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
On Thu, Jun 30, 2005 at 12:53:15AM -0700, Rick Moen wrote: > Quoting Troy Arnold ([EMAIL PROTECTED]): > > > I understand the reasoning behind all your boot options except the > > noatime on /var/* and /tmp. What's the scoop on that ? > > Small speed advantage. Fewer timestamp updates means faster access. > (Don't forget that atime has to get updated if you merely "ls" a > directory.) Well, yeah: but only of the directory, yes? (Brief experimentation seems to confirm this.) Seems like an incredibly small advantage. -Micah ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Troy Arnold ([EMAIL PROTECTED]): > I understand the reasoning behind all your boot options except the > noatime on /var/* and /tmp. What's the scoop on that ? Small speed advantage. Fewer timestamp updates means faster access. (Don't forget that atime has to get updated if you merely "ls" a directory.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
On Wed, Jun 29, 2005 at 12:24:51PM -0700, Rick Moen wrote: > > For whatever it's worth, here's my server's (main system's) current > fstab. Note mount options: > > # > proc/proc procdefaults0 0 > /dev/sda5 / ext3defaults,errors=remount-ro 0 1 > /dev/sda1 /boot ext2nodev,nosuid,noexec 0 2 > /dev/sdb1 /home ext3nodev,nosuid0 2 > /dev/sdb5 /tmpext2noatime,nodev,nosuid 0 2 > /dev/sdb8 /usrext2nodev,ro0 2 > /dev/sda9 /usr/local ext3defaults0 2 > /dev/sdb7 /varext3noatime,nodev,nosuid 0 2 > /dev/sda8 /var/logext2noatime,nodev,nosuid 0 2 > /dev/sda7 noneswapsw 0 0 > /dev/sdb6 noneswapsw 0 0 > /dev/fd0/media/floppy0 autorw,user,noauto 0 0 > /dev/sda6 /mnt/recovery ext2rw,noauto 0 2 I understand the reasoning behind all your boot options except the noatime on /var/* and /tmp. What's the scoop on that ? I'd like to be able to mount /tmp noexec but among other things, Debian packages like to run postinst scripts from there. -troy ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
on Wed, Jun 29, 2005 at 02:16:24PM -0500, Jay Strauss ([EMAIL PROTECTED]) wrote:
> Thanks Karsten
>
> Actually, /var, /home, and /usr are on separate partitions (I think I
> deleted them in the interest of the email)
>
> hydrogen:/# df -h
> FilesystemSize Used Avail Use% Mounted on
> /dev/hda1 133M 111M 15M 89% /
> tmpfs 189M 4.0K 189M 1% /dev/shm
> /dev/hda8 27G 1.4G 24G 6% /home
> /dev/hda7 361M 8.1M 334M 3% /tmp
> /dev/hda5 4.6G 905M 3.5G 21% /usr
> /dev/hda6 2.8G 115M 2.6G 5% /var
> fe:/home 50G 16G 32G 34% /mnt/fe/home
With the exception of root, most of those look sane.
I'm finding that 3 GiB for /usr isn't comfortable anymore (I like to
load up on docs), and distros seem to grow with time. 5-6 is probably a
good ballpark.
Peace.
--
Karsten M. Self http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
You...display numerous pro-Microsoft bumper stickers ("Honk if you
hate anti-trust laws") on your car.
- http://mail.nl.linux.org/humorix/1999-11/msg8.html
signature.asc
Description: Digital signature
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Jay Strauss ([EMAIL PROTECTED]): > Actually, /var, /home, and /usr are on separate partitions (I think I > deleted them in the interest of the email) Ja, 133MB is a bit too small for a modern root partition, even with /home, /tmp, /usr, and /var housed elsewhere. (Watch out for /opt, too. You might consider creating /usr/local/opt and symlinking /opt to that.) For whatever it's worth, here's my server's (main system's) current fstab. Note mount options: # proc/proc procdefaults0 0 /dev/sda5 / ext3defaults,errors=remount-ro 0 1 /dev/sda1 /boot ext2nodev,nosuid,noexec 0 2 /dev/sdb1 /home ext3nodev,nosuid0 2 /dev/sdb5 /tmpext2noatime,nodev,nosuid 0 2 /dev/sdb8 /usrext2nodev,ro0 2 /dev/sda9 /usr/local ext3defaults0 2 /dev/sdb7 /varext3noatime,nodev,nosuid 0 2 /dev/sda8 /var/logext2noatime,nodev,nosuid 0 2 /dev/sda7 noneswapsw 0 0 /dev/sdb6 noneswapsw 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 /dev/sda6 /mnt/recovery ext2rw,noauto 0 2 The last item listed is my fallback maintenance-boot partition, which houses a compact, duplicate installed system. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
I'd agree with a larger root partition Jay Karsten M. Self wrote: on Tue, Jun 28, 2005 at 05:06:20AM -0700, Shwaine ([EMAIL PROTECTED]) wrote: On Sun, 26 Jun 2005, Jay Strauss wrote: hydrogen:/# du -hxs * 2.7Mbin 8.3Mboot 0 cdrom 88K dev 6.9Metc 1.0Kinitrd 0 initrd.img 79M lib This suggests a couple of kernels. Current (2.6) kernels are running ~40 MiB in modules. You can spare space by: - Deleting unused kernels. - Copying older kernel's modules to an alternate location and linking them back. Kernel won't be bootable, but you'll be able to undo the damage if necessary. If you use an initrd to load boot-required drivers, this actually *will* work. - Compiling your own kernel with only necessary modules. SCSI, ISDN, bluetooth, telephony, atm, and many network drivers can be dropped for considerable savings. Alternatively, you could copy driver trees not needed at boot to another partition and symlink them back. Post-boot, module loads will work. Because of kernel bloat, I'm currently recommending a minimum of ~150, and preferably ~250 MiB+ for root. 385Mproc On Mon, 27 Jun 2005, Jay Strauss wrote: hydrogen:/# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda1 133M 107M 19M 86% / tmpfs 189M 4.0K 189M 1% /dev/shm /dev/hda8 27G 1.4G 24G 6% /home /dev/hda7 361M 8.1M 334M 3% /tmp /dev/hda5 4.6G 821M 3.6G 19% /usr /dev/hda6 2.8G 113M 2.6G 5% /var fe:/home 50G 16G 32G 34% /mnt/fe/home Off the bat a few things popped at me... first double-check the size on /proc. That seems a bit high, particularly given your second email that says the partition is not even that large. /proc is a virtual filesystem, it doesn't exist. Most files in it report a filesize of zero. The exceptions are any symlinks (always report a size of 1), and /proc/kcore, which reports memory size. From which, we can assume Jay's got 386MB RAM on his box. If you have a rogue process chewing up disk space, you'll want to solve that first. Second, also check the inodes available with df -i just in case this is a case of inode exhaustion instead of disk space. Good suggestion but doesn't seem to fit the data as presented. My final thought is to look through /lib and see if you need all the libraries you have installed as it seems to be the lion's share of the partition. My lib directory is about half the size of yours, but I tend to be minimalistic with my installations. You've likely only got one kernel installed. ...and for comparison, local partitions, and root FS sizes: FilesystemSize Used Avail Use% Mounted on /dev/hda2 228M 196M 21M 91% / tmpfs 475M 4.0K 475M 1% /dev/shm /dev/hda1 38M 28M 8.8M 76% /boot /dev/hda9 259M 197M 63M 76% /tmp /dev/hda10 1004M 820M 185M 82% /var /dev/hda113.0G 2.8G 143M 96% /usr /dev/hda12 1004M 493M 512M 50% /usr/local /dev/hda13 12G 11G 720M 94% /home And root utilization: # du -s bin dev etc lib root sbin 4364 bin 95 dev 34960 etc 115593 lib 33286 root 4909sbin Peace. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Thanks Karsten Actually, /var, /home, and /usr are on separate partitions (I think I deleted them in the interest of the email) hydrogen:/# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda1 133M 111M 15M 89% / tmpfs 189M 4.0K 189M 1% /dev/shm /dev/hda8 27G 1.4G 24G 6% /home /dev/hda7 361M 8.1M 334M 3% /tmp /dev/hda5 4.6G 905M 3.5G 21% /usr /dev/hda6 2.8G 115M 2.6G 5% /var fe:/home 50G 16G 32G 34% /mnt/fe/home I'll follow your guide when I repartition (eminently) Jay Karsten M. Self wrote: on Sun, Jun 26, 2005 at 11:28:01PM -0500, Jay Strauss ([EMAIL PROTECTED]) wrote: Hi, I was trying to install kernel-image-2.6.8-2-686, on debian sarge. But I'm getting: dpkg: error processing /var/cache/apt/archives/kernel-image-2.6.8-2-686_2.6.8-16 _i386.deb (--unpack): failed in buffer_write(fd) (8, ret=-1): backend dpkg-deb during `./lib/modules/ 2.6.8-2-686/kernel/sound/pci/trident/snd-trident-synth.ko': No space left on device I don't know what's taking up space and what I can delete. I did a hydrogen:/# du -hxs * 2.7Mbin 8.3Mboot 0 cdrom 88K dev 6.9Metc 1.0Kinitrd 0 initrd.img 79M lib 12K lost+found 3.0Kmedia 6.0Kmnt 385Mproc 3.3Mroot 3.6Msbin 1.0Ksrv 0 sys 13K tmp 0 vmlinuz That's part of the answer. You need to specify your filesystems too. If you're running a single filesysytem, the above is comprehensie. Looks like you're missing /var and /usr from there. 'df -h' is what you want to show. In my case we'd see: FilesystemSize Used Avail Use% Mounted on /dev/hda2 228M 196M 21M 91% / tmpfs 475M 4.0K 475M 1% /dev/shm /dev/hda1 38M 28M 8.8M 76% /boot /dev/hda9 259M 154M 106M 60% /tmp /dev/hda10 1004M 818M 187M 82% /var /dev/hda113.0G 2.8G 143M 96% /usr /dev/hda12 1004M 493M 512M 50% /usr/local /dev/hda13 12G 11G 742M 94% /home (I like lots of partitions ;-) To track down specific filesystem usage, I like: du -sx * | sort -nr ...which will sort utilization of directories (and files) within the current directory. Going down the subdirectories tends to be pretty fast due to disk caching. A really nice graphical utility for identifying where storage issues exist is 'filelight': http://www.methylblue.com/filelight/ ...which shows usage graphically, allows drilling down to see what specifically is using space. My current partitioning recommendations are here: http://twiki.iwethey.org/Main/NixPartitioning Now I'm a bit afraid to reboot my machine, for fear its been left in a damaged state. Should only be the new kernel that's not properly installed. Since its installation didn't complete, you shouldn't have to worry about it. Bootable disks (Knoppix, LNX-BBC, DSL, etc.) will pretty much always get you back into your system even if you've mucked something up badly. Peace. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
on Tue, Jun 28, 2005 at 05:06:20AM -0700, Shwaine ([EMAIL PROTECTED]) wrote: > On Sun, 26 Jun 2005, Jay Strauss wrote: > > >hydrogen:/# du -hxs * > >2.7Mbin > >8.3Mboot > >0 cdrom > >88K dev > >6.9Metc > >1.0Kinitrd > >0 initrd.img > >79M lib This suggests a couple of kernels. Current (2.6) kernels are running ~40 MiB in modules. You can spare space by: - Deleting unused kernels. - Copying older kernel's modules to an alternate location and linking them back. Kernel won't be bootable, but you'll be able to undo the damage if necessary. If you use an initrd to load boot-required drivers, this actually *will* work. - Compiling your own kernel with only necessary modules. SCSI, ISDN, bluetooth, telephony, atm, and many network drivers can be dropped for considerable savings. Alternatively, you could copy driver trees not needed at boot to another partition and symlink them back. Post-boot, module loads will work. Because of kernel bloat, I'm currently recommending a minimum of ~150, and preferably ~250 MiB+ for root. > >385Mproc > On Mon, 27 Jun 2005, Jay Strauss wrote: > > >hydrogen:/# df -h > >FilesystemSize Used Avail Use% Mounted on > >/dev/hda1 133M 107M 19M 86% / > >tmpfs 189M 4.0K 189M 1% /dev/shm > >/dev/hda8 27G 1.4G 24G 6% /home > >/dev/hda7 361M 8.1M 334M 3% /tmp > >/dev/hda5 4.6G 821M 3.6G 19% /usr > >/dev/hda6 2.8G 113M 2.6G 5% /var > >fe:/home 50G 16G 32G 34% /mnt/fe/home > > > Off the bat a few things popped at me... first double-check the size on > /proc. That seems a bit high, particularly given your second email that > says the partition is not even that large. /proc is a virtual filesystem, it doesn't exist. Most files in it report a filesize of zero. The exceptions are any symlinks (always report a size of 1), and /proc/kcore, which reports memory size. From which, we can assume Jay's got 386MB RAM on his box. > If you have a rogue process chewing up disk space, you'll want to > solve that first. Second, also check the inodes available with df -i > just in case this is a case of inode exhaustion instead of disk space. Good suggestion but doesn't seem to fit the data as presented. > My final thought is to look through /lib and see if you need all the > libraries you have installed as it seems to be the lion's share of the > partition. My lib directory is about half the size of yours, but I > tend to be minimalistic with my installations. You've likely only got one kernel installed. ...and for comparison, local partitions, and root FS sizes: FilesystemSize Used Avail Use% Mounted on /dev/hda2 228M 196M 21M 91% / tmpfs 475M 4.0K 475M 1% /dev/shm /dev/hda1 38M 28M 8.8M 76% /boot /dev/hda9 259M 197M 63M 76% /tmp /dev/hda10 1004M 820M 185M 82% /var /dev/hda113.0G 2.8G 143M 96% /usr /dev/hda12 1004M 493M 512M 50% /usr/local /dev/hda13 12G 11G 720M 94% /home And root utilization: # du -s bin dev etc lib root sbin 4364bin 95 dev 34960 etc 115593 lib 33286 root 4909sbin Peace. -- Karsten M. Self http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? I myself am often surprised at life's little quirks. - Princess Bride signature.asc Description: Digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
on Sun, Jun 26, 2005 at 11:28:01PM -0500, Jay Strauss ([EMAIL PROTECTED]) wrote: > Hi, > > I was trying to install kernel-image-2.6.8-2-686, on debian sarge. But > I'm getting: > > dpkg: error processing > /var/cache/apt/archives/kernel-image-2.6.8-2-686_2.6.8-16 > _i386.deb (--unpack): > failed in buffer_write(fd) (8, ret=-1): backend dpkg-deb during > `./lib/modules/ > 2.6.8-2-686/kernel/sound/pci/trident/snd-trident-synth.ko': No space > left on device > > I don't know what's taking up space and what I can delete. I did a > > hydrogen:/# du -hxs * > 2.7Mbin > 8.3Mboot > 0 cdrom > 88K dev > 6.9Metc > 1.0Kinitrd > 0 initrd.img > 79M lib > 12K lost+found > 3.0Kmedia > 6.0Kmnt > 385Mproc > 3.3Mroot > 3.6Msbin > 1.0Ksrv > 0 sys > 13K tmp > 0 vmlinuz That's part of the answer. You need to specify your filesystems too. If you're running a single filesysytem, the above is comprehensie. Looks like you're missing /var and /usr from there. 'df -h' is what you want to show. In my case we'd see: FilesystemSize Used Avail Use% Mounted on /dev/hda2 228M 196M 21M 91% / tmpfs 475M 4.0K 475M 1% /dev/shm /dev/hda1 38M 28M 8.8M 76% /boot /dev/hda9 259M 154M 106M 60% /tmp /dev/hda10 1004M 818M 187M 82% /var /dev/hda113.0G 2.8G 143M 96% /usr /dev/hda12 1004M 493M 512M 50% /usr/local /dev/hda13 12G 11G 742M 94% /home (I like lots of partitions ;-) To track down specific filesystem usage, I like: du -sx * | sort -nr ...which will sort utilization of directories (and files) within the current directory. Going down the subdirectories tends to be pretty fast due to disk caching. A really nice graphical utility for identifying where storage issues exist is 'filelight': http://www.methylblue.com/filelight/ ...which shows usage graphically, allows drilling down to see what specifically is using space. My current partitioning recommendations are here: http://twiki.iwethey.org/Main/NixPartitioning > Now I'm a bit afraid to reboot my machine, for fear its been left in a > damaged state. Should only be the new kernel that's not properly installed. Since its installation didn't complete, you shouldn't have to worry about it. Bootable disks (Knoppix, LNX-BBC, DSL, etc.) will pretty much always get you back into your system even if you've mucked something up badly. Peace. -- Karsten M. Self http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Go through his clothes and look for loose change. - Princess Bride signature.asc Description: Digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Jay Strauss ([EMAIL PROTECTED]): > I dont' know if I have a rouge process. ^ Better red than dead. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Off the bat a few things popped at me... first double-check the size on /proc. That seems a bit high, particularly given your second email that says the partition is not even that large. I reran and got the same: 0 20 2.7Mbin 13M boot 0 cdrom 88K dev 6.9Metc 1.4Ghome 1.0Kinitrd 0 initrd.img 0 initrd.img.old 1.0Kl20 80M lib 12K lost+found 2.0Kmedia 6.0Kmnt du: `proc/3077/task': No such file or directory du: `proc/3077/fd': No such file or directory 385Mproc 390Kroot 3.6Msbin 1.0Ksrv 0 sys 24K tmp 873Musr 83M var 0 vmlinuz 0 vmlinuz.old I dont' know if I have a rouge process. Not even sure how to go about looking for it. I did a ps -ef, and everything (virtually) is regarding X and KDE, I just rebooted the box. If you have a rogue process chewing up disk space, you'll want to solve that first. Second, also check the inodes available with df -i just in case this is a case of inode exhaustion instead of disk space. I'm ok on inodes hydrogen:/# df -i FilesystemInodes IUsed IFree IUse% Mounted on /dev/hda1 72288 11318 60970 16% / tmpfs 48280 3 482771% /dev/shm /dev/hda83541440 19689 35217511% /home /dev/hda7 192768 43 1927251% /tmp /dev/hda5 610432 43762 5666708% /usr /dev/hda6 3665282858 3636701% /var fe:/home 65536008424 65451761% /mnt/fe/home My final thought is to look through /lib and see if you need all the libraries you have installed as it seems to be the lion's share of the partition. I did go thru my /lib directory yesterday and deleted some unused stuff, and that freed up enough space to allow me to install the new kernel thansk Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
On Sun, 26 Jun 2005, Jay Strauss wrote: hydrogen:/# du -hxs * 2.7Mbin 8.3Mboot 0 cdrom 88K dev 6.9Metc 1.0Kinitrd 0 initrd.img 79M lib 12K lost+found 3.0Kmedia 6.0Kmnt 385Mproc 3.3Mroot 3.6Msbin 1.0Ksrv 0 sys 13K tmp 0 vmlinuz On Mon, 27 Jun 2005, Jay Strauss wrote: hydrogen:/# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda1 133M 107M 19M 86% / tmpfs 189M 4.0K 189M 1% /dev/shm /dev/hda8 27G 1.4G 24G 6% /home /dev/hda7 361M 8.1M 334M 3% /tmp /dev/hda5 4.6G 821M 3.6G 19% /usr /dev/hda6 2.8G 113M 2.6G 5% /var fe:/home 50G 16G 32G 34% /mnt/fe/home Off the bat a few things popped at me... first double-check the size on /proc. That seems a bit high, particularly given your second email that says the partition is not even that large. If you have a rogue process chewing up disk space, you'll want to solve that first. Second, also check the inodes available with df -i just in case this is a case of inode exhaustion instead of disk space. My final thought is to look through /lib and see if you need all the libraries you have installed as it seems to be the lion's share of the partition. My lib directory is about half the size of yours, but I tend to be minimalistic with my installations. So those are a few things to look into. And in the process of looking at how my box was set up to compare to yours, I discovered that I messed up my fstab on the rebuild a couple months ago so now I'm off to deal with that. Accidently put "/home" for the "/usr" mount point, so now I have two partitions defined as /home mount point in fstab. That's what I get for installing machines late at night. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
On Mon, Jun 27, 2005 at 07:35:32PM -0500, Jay Strauss wrote: > that worked, I deleted some of the old 2.6.8 libs and my > /root/.mozilla and was able to install the new kernel. ^^ Eep! :) > Now I guess I'm going to have to rearrange things to get more space Yep. I did that with my dad's PC. I'm keeping the 1.1GB HDD as the main system (since I didn't want to reinstall), and shoved "/home" and "/usr" onto a 40GB drive. Plenty of room to install new apps (they'll land in 'usr') and for dad's files (in 'home', of course). One thing I've found handy is: du -s * | sort -n ...it gives you a summary of the contents (in size) of all subfolders in the current folder, with the largest listed at the bottom. (Throw a ".*" along in there too if you're interested in hidden directories. e.g., if you're running this command from a user's homedir) -- -bill! Picn*x14 --- Linux Anniversary Picnic & BBQ! [EMAIL PROTECTED] Sunnyvale Baylands Park, Sunday, August 14th http://newbreedsoftware.com/http://linuxpicnic.org/ to RSVP & volunteer! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
that worked, I deleted some of the old 2.6.8 libs and my /root/.mozilla
and was able to install the new kernel.
Now I guess I'm going to have to rearrange things to get more space
Jay
Rick Moen wrote:
Quoting Jay Strauss ([EMAIL PROTECTED]):
I'm out of space on /. and the install is trying to write to /lib
[...]
Will moving the contents of lib somewhere else, like /usr/mylib and soft
linking /lib->/usr/mylib work as a workaround? Will my machine be able
to boot correctly?
I see no reason why not -- but personally I'd find some other
(long-term) solution.
Certain trees are part of the root filesystem for a very good reason,
and /lib is one of them. The contents are libraries too critical to
system booting, maintenance, and recovery to be included in /usr/lib:
They're the ones you need available even if /usr cannot be mounted at
all.
Things that might more reasonably be moved off the root filesystem
include /boot, /home, /opt, /usr, and /var.
In your shoes I might move /lib off the root filesystem _briefly_ --
just long enough to give me enough free space on the root filesystem to
craft a better long-term solution. (By preference, I would do that from
a bootable maintenance disk such as an LNX-BBC, Tom's Root-Boot, or
Knoppix disk.)
You may also find the following Perl script ("largest20") useful, in
getting you some breathing room: It finds and lists the biggest 20
files in the current directory or any subdirectory -- and can be
re-found as http://linuxmafia.com/pub/linux/utilities-general/largest20:
#!/usr/bin/perl -w
# You can alternatively just do:
# find . -xdev -type f -print0 | xargs -r0 ls -l | sort -rn +4 | head -20
use File::Find;
@ARGV = $ENV{ PWD } unless @ARGV;
find ( sub { $size{ $File::Find::name } = -s if -f; }, @ARGV );
@sorted = sort { $size{ $b } <=> $size{ $a } } keys %size;
splice @sorted, 20 if @sorted > 20;
printf "%10d %s\n", $size{$_}, $_ for @sorted
If you can't find a way to reduce the contents of / down to comfortable
levels, I would strongly urge repartitioning your system -- since
running out of space on / is a serious problem. Use one of the
aforementioned maintenance boot disks, then use one of the methods
detailed in "Copying Directory Trees" on http://linuxmafia.com/kb/Admin
to copy the contents of each filesystem to be re-created over to a
second system on your LAN. Then, umount, use fdisk/cfdisk, mkfs.*, and
copy the contents back.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Steve Wormley ([EMAIL PROTECTED]): > And even if that works, when you reboot( / is mounted by the kernel) > and the system goes to mount /usr it will likely fail because mount(on my > systems at least) is linked to libraries which you moved to /usr and it can > no longer access. > > ldd /bin/mount > libblkid.so.1 => /lib/libblkid.so.1 (0x40021000) > libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) > libc.so.6 => /lib/libc.so.6 (0x4002b000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [...] Well, there ya go. Quite. Some things, you know you really don't want to try them, but you can't remember exactly why. For me, this was one of those. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
> # cd / > # mv /lib /usr/cruciallibs && ln -s /usr/cruciallibs /lib And even if that works, when you reboot( / is mounted by the kernel) and the system goes to mount /usr it will likely fail because mount(on my systems at least) is linked to libraries which you moved to /usr and it can no longer access. ldd /bin/mount libblkid.so.1 => /lib/libblkid.so.1 (0x40021000) libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) libc.so.6 => /lib/libc.so.6 (0x4002b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) Of course, it might not get that far: ldd /sbin/init libc.so.6 => /lib/libc.so.6 (0x40021000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) Or maybe you'd like to try a single user boot(/bin/sh) ldd /bin/sh libncurses.so.5 => /lib/libncurses.so.5 (0x40021000) libdl.so.2 => /lib/libdl.so.2 (0x4006) libc.so.6 => /lib/libc.so.6 (0x40063000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) (Obviously bash) Now, you could probably make an initrd that mounts /usr or some other such scheme, but I'd really recommend not moving /lib off the root drive, you're generally asking for trouble. -Steve Wormley ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Jay Strauss ([EMAIL PROTECTED]): > >>Will moving the contents of lib somewhere else, like /usr/mylib and soft > >>linking /lib->/usr/mylib work as a workaround? Will my machine be able > >>to boot correctly? > > > >I see no reason why not -- but personally I'd find some other > >(long-term) solution. > > Well I can tell you, it sure doesn't work on a live system. I moved > /lib and afterward had no unix commands at my disposal. Had to boot > with knoppix and repair my error Er, I'd assumed that, if at all, you'd have done something all-in-one-step so that the shell lands on a sane system, like this: # cd / # mv /lib /usr/cruciallibs && ln -s /usr/cruciallibs /lib ...and I'd still have kept that maintenance disk handy. ;-> > Sounds like that's what I'll have to do, and hope I don't crush my > system in the process. I realize when I created the system, I didn't > allocate enough space for /, thinking that most of the stuff sat in > /var, /usr/, /home obviously I'll need more For whatever it's worth, the server I'm mailing this from has these (non-swap) partitions: [EMAIL PROTECTED] ~ $ df -H Filesystem Size Used Avail Use% Mounted on /dev/sda5 938M70M 818M 8% / tmpfs 132M 0 132M 0% /dev/shm /dev/sda1 94M 6.1M83M 7% /boot /dev/sdb1 938M 761M 127M 86% /home /dev/sdb5 282M44k 266M 1% /tmp /dev/sdb8 3.0G 643M 2.2G 23% /usr /dev/sda9 5.0G 987M 3.7G 22% /usr/local /dev/sdb7 1.9G 1.1G 700M 61% /var /dev/sda8 938M 102M 786M 12% /var/log [EMAIL PROTECTED] ~ $ Notice that / is pretty darned small, because all the significant non-system-crucial trees are on other filesystems. (For most purposes, dividing the system so finely would be a bit over-maniacal: Some of those are separate in order to use different filesystem types or mount options, or for other special aims.) ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Will moving the contents of lib somewhere else, like /usr/mylib and soft
linking /lib->/usr/mylib work as a workaround? Will my machine be able
to boot correctly?
I see no reason why not -- but personally I'd find some other
(long-term) solution.
Well I can tell you, it sure doesn't work on a live system. I moved
/lib and afterward had no unix commands at my disposal. Had to boot
with knoppix and repair my error
You may also find the following Perl script ("largest20") useful, in
getting you some breathing room: It finds and lists the biggest 20
files in the current directory or any subdirectory -- and can be
re-found as http://linuxmafia.com/pub/linux/utilities-general/largest20:
thanks for the link, I'll try it when I get home
If you can't find a way to reduce the contents of / down to comfortable
levels, I would strongly urge repartitioning your system -- since
running out of space on / is a serious problem. Use one of the
aforementioned maintenance boot disks, then use one of the methods
detailed in "Copying Directory Trees" on http://linuxmafia.com/kb/Admin
to copy the contents of each filesystem to be re-created over to a
second system on your LAN. Then, umount, use fdisk/cfdisk, mkfs.*, and
copy the contents back.
Sounds like that's what I'll have to do, and hope I don't crush my
system in the process. I realize when I created the system, I didn't
allocate enough space for /, thinking that most of the stuff sat in
/var, /usr/, /home obviously I'll need more
Thanks
Jay
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Jay Strauss ([EMAIL PROTECTED]):
> I'm out of space on /. and the install is trying to write to /lib
[...]
> Will moving the contents of lib somewhere else, like /usr/mylib and soft
> linking /lib->/usr/mylib work as a workaround? Will my machine be able
> to boot correctly?
I see no reason why not -- but personally I'd find some other
(long-term) solution.
Certain trees are part of the root filesystem for a very good reason,
and /lib is one of them. The contents are libraries too critical to
system booting, maintenance, and recovery to be included in /usr/lib:
They're the ones you need available even if /usr cannot be mounted at
all.
Things that might more reasonably be moved off the root filesystem
include /boot, /home, /opt, /usr, and /var.
In your shoes I might move /lib off the root filesystem _briefly_ --
just long enough to give me enough free space on the root filesystem to
craft a better long-term solution. (By preference, I would do that from
a bootable maintenance disk such as an LNX-BBC, Tom's Root-Boot, or
Knoppix disk.)
You may also find the following Perl script ("largest20") useful, in
getting you some breathing room: It finds and lists the biggest 20
files in the current directory or any subdirectory -- and can be
re-found as http://linuxmafia.com/pub/linux/utilities-general/largest20:
#!/usr/bin/perl -w
# You can alternatively just do:
# find . -xdev -type f -print0 | xargs -r0 ls -l | sort -rn +4 | head -20
use File::Find;
@ARGV = $ENV{ PWD } unless @ARGV;
find ( sub { $size{ $File::Find::name } = -s if -f; }, @ARGV );
@sorted = sort { $size{ $b } <=> $size{ $a } } keys %size;
splice @sorted, 20 if @sorted > 20;
printf "%10d %s\n", $size{$_}, $_ for @sorted
If you can't find a way to reduce the contents of / down to comfortable
levels, I would strongly urge repartitioning your system -- since
running out of space on / is a serious problem. Use one of the
aforementioned maintenance boot disks, then use one of the methods
detailed in "Copying Directory Trees" on http://linuxmafia.com/kb/Admin
to copy the contents of each filesystem to be re-created over to a
second system on your LAN. Then, umount, use fdisk/cfdisk, mkfs.*, and
copy the contents back.
___
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Thanks Rick, unfortunately that's not the prob. I'm not out of space on var (since var is a different filesystem) hydrogen:/# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda1 133M 107M 19M 86% / tmpfs 189M 4.0K 189M 1% /dev/shm /dev/hda8 27G 1.4G 24G 6% /home /dev/hda7 361M 8.1M 334M 3% /tmp /dev/hda5 4.6G 821M 3.6G 19% /usr /dev/hda6 2.8G 113M 2.6G 5% /var fe:/home 50G 16G 32G 34% /mnt/fe/home I'm out of space on /. and the install is trying to write to /lib dpkg: error processing /var/cache/apt/archives/kernel-image-2.6.8-2-686_2.6.8-16_i386.deb (--unpack): failed in buffer_write(fd) (8, ret=-1): backend dpkg-deb during `./lib/modules/2.6.8-2-686/kernel/drivers/video/console/fbcon.ko': No space left on device Will moving the contents of lib somewhere else, like /usr/mylib and soft linking /lib->/usr/mylib work as a workaround? Will my machine be able to boot correctly? Thanks Jay Rick Moen wrote: I did a hydrogen:/# du -hxs * I suspect that including "x" sabotaged your intent, there, since, if memory serves, it limits the report to subdirectories on just the one filesystem you happen to specify, and omits all others. So, if your current directory at that time -- which I gather must have been the root directory -- was on a filesystem didn't include /var, then the report wouldn't tell you anything about that subtree. If my guess is correct about the package cache, you might just make a point of using one of the apt commands to clean out the cache on occasion. Note that some of the higher-level tools (that call apt-get) will take care of that housekeeping for you. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] I'm out of space on /
Quoting Jay Strauss ([EMAIL PROTECTED]): > dpkg: error processing > /var/cache/apt/archives/kernel-image-2.6.8-2-686_2.6.8-16 > _i386.deb (--unpack): > failed in buffer_write(fd) (8, ret=-1): backend dpkg-deb during > `./lib/modules/ > 2.6.8-2-686/kernel/sound/pci/trident/snd-trident-synth.ko': No space > left on device > > I don't know what's taking up space and what I can delete. More often than not, it's accumulation of packages in /var/cache/apt/archives/ . Try "apt-get autoclean" to sweep out packages no longer useful to keep there, or "apt-get clean" to ruthlessly purge the cache. > I did a > > hydrogen:/# du -hxs * I suspect that including "x" sabotaged your intent, there, since, if memory serves, it limits the report to subdirectories on just the one filesystem you happen to specify, and omits all others. So, if your current directory at that time -- which I gather must have been the root directory -- was on a filesystem didn't include /var, then the report wouldn't tell you anything about that subtree. If my guess is correct about the package cache, you might just make a point of using one of the apt commands to clean out the cache on occasion. Note that some of the higher-level tools (that call apt-get) will take care of that housekeeping for you. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] I'm out of space on /
Hi, I was trying to install kernel-image-2.6.8-2-686, on debian sarge. But I'm getting: dpkg: error processing /var/cache/apt/archives/kernel-image-2.6.8-2-686_2.6.8-16 _i386.deb (--unpack): failed in buffer_write(fd) (8, ret=-1): backend dpkg-deb during `./lib/modules/ 2.6.8-2-686/kernel/sound/pci/trident/snd-trident-synth.ko': No space left on device I don't know what's taking up space and what I can delete. I did a hydrogen:/# du -hxs * 2.7Mbin 8.3Mboot 0 cdrom 88K dev 6.9Metc 1.0Kinitrd 0 initrd.img 79M lib 12K lost+found 3.0Kmedia 6.0Kmnt 385Mproc 3.3Mroot 3.6Msbin 1.0Ksrv 0 sys 13K tmp 0 vmlinuz Now I'm a bit afraid to reboot my machine, for fear its been left in a damaged state. Suggestions please Thanks Jay ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
