Hi David,
Skipping to quote most of the mail you wrote, I read it a few more times. :-)
[]
> In the listing above, you have removed versions 7 through 16, and then purged
> 7, as quoted above. The remaining 8 through 16 contain no modules, and the
> evidence is shown in your listing
> above
On 5/2/23, Greg Wooledge wrote:
> On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
>> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
>> > man apt
>>
>> Which doesn't say what 'apt purge' does without a package name. It says
>> 'Performs the requested action on one or more packages specif
On Mon 08 May 2023 at 08:27:52 (+), Bonno Bloksma wrote:
> > "apt autoremove" will remove (not purge) packages
> []
> Thanks for the better explanation, that is what I understood as well.
I doubt that.
> > One imagines that if you simply purged all of the kernel packages that had
> > be
Hi,
As we have seen some modules directories are larger than others. I was just
cleaning up some old stuff and this is what I noticed.
---
xxx:/usr/lib/modules# du * -sh
4.7M5.10.0-16-amd64
309M5.10.0-18-amd64
309M5.10.0-19-amd64
309M5.10.0-20-amd64
30
Hi Greg,
>> Just created a snapshot of my servers and then did:
>> apt autoremove
>> apt purge
>> apt clean
>> and I still have a working system so it will not just get rid of all
>> installed packages. :-) But... I still also have all those folders in
>> /usr/lib/modules
> It seems like you're
On Fri 05 May 2023 at 14:35:08 (+), Bonno Bloksma wrote:
> As I was trying to find out what would work and if I was doing something
> wrong getting rid of old kernels
>
> After upgrading a new kernel for a week I will do apt autoremove to get rid
> of the old kernel(s).
And this will pr
On Fri, May 05, 2023 at 02:35:08PM +, Bonno Bloksma wrote:
> Just created a snapshot of my servers and then did:
> apt autoremove
> apt purge
> apt clean
> and I still have a working system so it will not just get rid of all
> installed packages. :-)
> But... I still also have all those folder
On 03 May 2023 18:22, Curt wrote:
You really don't have to tread dangerous waters (or rather wade into
them, unless your Jesus) because you can simulate without root privileges.
curty@einstein:~$ apt -s purge
NOTE: This is only a simulation!
Quick nitpicking.
Even if "-s" is easily remembered
Hi,
>> I expect that, by context, running
>> apt purge
>> without the restriction specifying particular package, will apply apt
>> purge to all installed packages, according to what purge does, in
>> relation to packages.
>
> But as "apt purge " remove this package and remove configuration for
On Wed, May 03, 2023 at 04:22:55PM -, Curt wrote:
[...]
> You really don't have to tread dangerous waters (or rather wade into
> them, unless your Jesus) because you can simulate without root privileges.
Yes, +1 for -s :-)
> curty@einstein:~$ apt -s purge
> NOTE: This is only a simulation!
Le 3 mai 2023 Curt a écrit :
> You really don't have to tread dangerous waters (or rather wade into
> them, unless your Jesus) because you can simulate without root privileges.
>
> curty@einstein:~$ apt -s purge
> NOTE: This is only a simulation!
Nice parameter, thanks !
On 2023-05-02, Greg Wooledge wrote:
>
> unicorn:~$ apt purge
> E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13:
> Permission denied)
> E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend),
> are you root?
>
> Rats! No luck here. Either "apt purge" is not
On Tue 02 May 2023 at 13:03:48 (-0400), songbird wrote:
> David Wright wrote:
> ...
> > It seems a bluff was called. Anyway, I got
> > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> > as it seems bookworm's libfreetype6 was upgraded overnight.
>
> that was the only upgrade i
On Tue, 02 May 2023 18:10:01 +0200 David Wright
wrote:
> On Tue 02 May 2023 at 11:39:09 (-0400), The Wanderer wrote:
>
>> It's a pointless thing to discuss, in any case, since I have been
>> unable to think of essentially any reason why anyone would ever want
>> to do any such thing.
>
> It mak
David Wright wrote:
...
> It seems a bluff was called. Anyway, I got
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> as it seems bookworm's libfreetype6 was upgraded overnight.
that was the only upgrade i saw this morning for my
testing partition.
> And I'm not brave; the
On Tue 02 May 2023 at 11:39:09 (-0400), The Wanderer wrote:
> It's a pointless thing to discuss, in any case, since I have been unable
> to think of essentially any reason why anyone would ever want to do any
> such thing.
It makes me think of that gruesome cartoon where a meat mincer's
handle is
Bret Busby wrote:
> On 2/5/23 20:23, Michel Verdier wrote:
> > Le 2 mai 2023 Bret Busby a écrit :
> >
> >> I expect that, by context, running
> >> apt purge
> >> without the restriction specifying particular package, will apply
> >> apt purge
> >> to all installed packages, according to what pu
On 2023-05-02 at 10:28, Bret Busby wrote:
> On 2/5/23 20:23, Michel Verdier wrote:
>
>> Le 2 mai 2023 Bret Busby a écrit :
>>
>>> I expect that, by context, running
>>> apt purge
>>> without the restriction specifying particular package, will apply
>>> apt purge
>>> to all installed packages, acc
On Tue, 2023-05-02 at 22:28 +0800, Bret Busby wrote:
> I think that, to remove all installed packages, a system administrator,
> from the superuser level, needs to run something like
> rm -r /
Or
apt remove '*'
Man page for apt says it accepts regex and globs for package
specifiers. Other too
On Tue 02 May 2023 at 22:28:11 (+0800), Bret Busby wrote:
> On 2/5/23 20:23, Michel Verdier wrote:
> > Le 2 mai 2023 Bret Busby a écrit :
> >
> > > I expect that, by context, running
> > > apt purge
> > > without the restriction specifying particular package, will apply
> > > apt purge
> > > to al
On Tue 02 May 2023 at 08:09:57 (-0400), Greg Wooledge wrote:
> On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
> > On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> > > man apt
> >
> > Which doesn't say what 'apt purge' does without a package name. It says
> > 'Performs the requested ac
Le 2 mai 2023 Bret Busby a écrit :
> and, so, where a particular package is specified as an argument to the
> command, all obsolete configuration files associated with the package, will be
> removed, and, where no package is specified as an argument to the command, all
> obsolete configuration fi
On 2/5/23 20:23, Michel Verdier wrote:
Le 2 mai 2023 Bret Busby a écrit :
I expect that, by context, running
apt purge
without the restriction specifying particular package, will apply
apt purge
to all installed packages, according to what purge does, in relation to
packages.
But as "apt purg
On 2/5/23 18:18, Bret Busby wrote:
On 2/5/23 17:18, Tixy wrote:
On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
On 2/5/23 16:58, Bret Busby wrote:
On 2/5/23 11:42, David Wright wrote:
Have you tried running also
apt autoclean
I thought that just cleared /var/cache/apt/archives/.
Le 2 mai 2023 Bret Busby a écrit :
> I expect that, by context, running
> apt purge
> without the restriction specifying particular package, will apply
> apt purge
> to all installed packages, according to what purge does, in relation to
> packages.
But as "apt purge " remove this package and rem
On Tue, May 02, 2023 at 10:18:10AM +0100, Tixy wrote:
> On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> > man apt
>
> Which doesn't say what 'apt purge' does without a package name. It says
> 'Performs the requested action on one or more packages specified via
> regex(7), glob(7) or exact m
On 2/5/23 18:20, Bret Busby wrote:
On 2/5/23 18:18, Bret Busby wrote:
On 2/5/23 17:18, Tixy wrote:
On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
On 2/5/23 16:58, Bret Busby wrote:
On 2/5/23 11:42, David Wright wrote:
Have you tried running also
apt autoclean
I thought that jus
On 2/5/23 17:18, Tixy wrote:
On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
On 2/5/23 16:58, Bret Busby wrote:
On 2/5/23 11:42, David Wright wrote:
Have you tried running also
apt autoclean
I thought that just cleared /var/cache/apt/archives/.
and
apt purge
I've never tried t
On Tue, 2023-05-02 at 17:03 +0800, Bret Busby wrote:
> On 2/5/23 16:58, Bret Busby wrote:
> > On 2/5/23 11:42, David Wright wrote:
>
>
>
> > >
> > > > > > Have you tried running also
> > > > > > apt autoclean
> > >
> > > I thought that just cleared /var/cache/apt/archives/.
> > >
> > > > > >
On 2/5/23 16:58, Bret Busby wrote:
On 2/5/23 11:42, David Wright wrote:
Have you tried running also
apt autoclean
I thought that just cleared /var/cache/apt/archives/.
and
apt purge
I've never tried that without a package name. What does it do?
RTFM ?
man apt
...
..
Bret Busb
On 2/5/23 11:42, David Wright wrote:
On Mon 01 May 2023 at 23:24:56 (-0400), Timothy M Butterworth wrote:
On Mon, May 1, 2023 at 10:45 PM Rick Thomas wrote:
On Mon, May 1, 2023, at 11:14 AM, Bret Busby wrote:
On 2/5/23 02:06, David Christensen wrote:
On 5/1/23 06:51, Bonno Bloksma wrote:
Th
On Mon 01 May 2023 at 23:24:56 (-0400), Timothy M Butterworth wrote:
> On Mon, May 1, 2023 at 10:45 PM Rick Thomas wrote:
> > On Mon, May 1, 2023, at 11:14 AM, Bret Busby wrote:
> > > On 2/5/23 02:06, David Christensen wrote:
> > >> On 5/1/23 06:51, Bonno Bloksma wrote:
> > >>> The cause seems to
On Mon, May 1, 2023 at 10:45 PM Rick Thomas wrote:
> On Mon, May 1, 2023, at 11:14 AM, Bret Busby wrote:
> > On 2/5/23 02:06, David Christensen wrote:
> >> On 5/1/23 06:51, Bonno Bloksma wrote:
> >>> Hi,
> >>>
> >>> On my "new" Bullseye machines the root volume starts to fill up. The
> >>> cause
On Mon, May 1, 2023, at 11:14 AM, Bret Busby wrote:
> On 2/5/23 02:06, David Christensen wrote:
>> On 5/1/23 06:51, Bonno Bloksma wrote:
>>> Hi,
>>>
>>> On my "new" Bullseye machines the root volume starts to fill up. The
>>> cause seems to be the /usr/lib folder.
>>> On my older Buster (10.13) ma
On Mon, 1 May 2023 12:10:08 -0600
Charles Curley wrote:
Hello Charles,
>Ah. I don't recall that I've ever tried that. Maybe one should
>experiment on a throw-away VM. :-)
Go ahead: What's life without a little jeopardy? :-)
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
On Mon, 01 May 2023 14:09:56 -0400
Stefan Monnier wrote:
Hello Stefan,
>The main downside is usually that you won't be able to access
Or reboot, into a working system, if it's the *only* kernel. But
hey... :-)
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/
3 root@taz ~
# journalctl --disk-usage
Archived and active journals take up 400.0M in the file system.
2023-05-01 12:25:46 root@taz ~
# journalctl --vacuum-size=100M
2023-05-01 12:28:05 root@taz ~
# journalctl --disk-usage
Archived and active journals take up 104.0M in the file system.
2023-05-0
On Mon 01 May 2023 at 11:06:25 (-0600), Charles Curley wrote:
> On Mon, 1 May 2023 13:51:06 + > Bonno Bloksma wrote:
>
> > Guessing on what I see these are libraries for older kernel versions.
> > I usually clean up older kernel versions by using # apt autoremove"
> > All 3 servers have 1 olde
On 2/5/23 02:06, David Christensen wrote:
On 5/1/23 06:51, Bonno Bloksma wrote:
Hi,
On my "new" Bullseye machines the root volume starts to fill up. The
cause seems to be the /usr/lib folder.
On my older Buster (10.13) machine the total /usr directory is 701M,
the /usr/lib folder is 260M
In
On Mon, 1 May 2023 18:52:09 +0100
Brad Rogers wrote:
> If memory serves, should one try to do that, warnings are issued.
>
> Not quite HAL in "2001, A Space Odyssey", but near enough. :-)
Ah. I don't recall that I've ever tried that. Maybe one should
experiment on a throw-away VM. :-)
Daisy,
>>to not purge the two most recent kernel packages, and especially not
>>the kernel you are currently running on.
> If memory serves, should one try to do that, warnings are issued.
> Not quite HAL in "2001, A Space Odyssey", but near enough. :-)
Also, purging the current kernel is not nearly as
On 5/1/23 06:51, Bonno Bloksma wrote:
Hi,
On my "new" Bullseye machines the root volume starts to fill up. The cause
seems to be the /usr/lib folder.
On my older Buster (10.13) machine the total /usr directory is 701M, the
/usr/lib folder is 260M
In my /usr/lib folder on Buster is NO /usr/lib/
On Mon, 1 May 2023 11:06:25 -0600
Charles Curley wrote:
Hello Charles,
>to not purge the two most recent kernel packages, and especially not
>the kernel you are currently running on.
If memory serves, should one try to do that, warnings are issued.
Not quite HAL in "2001, A Space Odyssey", but
On Mon, 1 May 2023 13:51:06 +
Bonno Bloksma wrote:
> Guessing on what I see these are libraries for older kernel versions.
> I usually clean up older kernel versions by using # apt autoremove"
> All 3 servers have 1 older kernel version installed according to apt
> autoremove.
Autoremove rem
On Mon 01 May 2023 at 13:51:06 (+), Bonno Bloksma wrote:
Hmm, that took a long time to get posted.
> On my "new" Bullseye machines the root volume starts to fill up. The cause
> seems to be the /usr/lib folder.
> On my older Buster (10.13) machine the total /usr directory is 701M, the
> /us
On Mon, 2023-05-01 at 13:51 +, Bonno Bloksma wrote:
[...]
> On my Bullseye machines the /usr/lib folder is 2+GB on the machines that have
> been operating for a while and 1+G on a machine that has been operating for a
> shorter while.
>
> The cause seems to be the folder /usr/lib/modules#
>
Hi,
On my "new" Bullseye machines the root volume starts to fill up. The cause
seems to be the /usr/lib folder.
On my older Buster (10.13) machine the total /usr directory is 701M, the
/usr/lib folder is 260M
In my /usr/lib folder on Buster is NO /usr/lib/modules folder
On my Bullseye machines
On Sun, 2015-10-04 at 18:07 +0530, Himanshu Shekhar wrote:
> Whenever I want to open any file directly from search, or places, or
> and
> disk after mounting, it directs to Disk Usage Analyser, which I want
> to be
> Nautilus instead.
> Is there any method to fix this?
Sounds
>
> Am 04.10.2015 um 15:37 schrieb Himanshu Shekhar:
>
>> Whenever I want to open any file directly from search, or places, or and
>> disk after mounting, it directs to Disk Usage Analyser, which I want to be
>> Nautilus instead.
>> Is there any method to fix this?
>>
&g
. Some details will help.
Am 04.10.2015 um 15:37 schrieb Himanshu Shekhar:
Whenever I want to open any file directly from search, or places, or
and disk after mounting, it directs to Disk Usage Analyser, which I
want to be Nautilus instead.
Is there any method to fix this?
--
Himanshu Shekhar
IIIT-Allahabad
IRM2015006
Whenever I want to open any file directly from search, or places, or and
disk after mounting, it directs to Disk Usage Analyser, which I want to be
Nautilus instead.
Is there any method to fix this?
--
Himanshu Shekhar
IIIT-Allahabad
IRM2015006
Frederic Marchal wrote:
> > Have a look at agedu:
> > http://www.chiark.greenend.org.uk/~sgtatham/agedu/
> > It computes disk usage like du.
> >
> > The produced HTML report can be viewed interactively like ncdu.
That is pretty cool! I was previously unawa
filesystem.
> >
> > If I could start again, I'd put LVM on the array and use multiple LVs
> > to allow du to work at lower levels, but that's not really practical
> > at this stage.
> >
> > Any tips?
>
> Have a look at agedu:
>
> http://w
> can trigger on any writes to a particular filesystem.
>
> If I could start again, I'd put LVM on the array and use multiple LVs
> to allow du to work at lower levels, but that's not really practical
> at this stage.
>
> Any tips?
Have a look at agedu:
http://
On 04/03/15 09:30, Don Armstrong wrote:
On Tue, 03 Mar 2015, Jacek Politowski wrote:
On Tue, Mar 03, 2015 at 08:29:53PM +1300, Richard Hector wrote:
I can run du, but that takes ages, and has a performance impact.
With "idle" I/O scheduler class (set with ionice) does it still have
a big per
On Tue, 03 Mar 2015, Jacek Politowski wrote:
> On Tue, Mar 03, 2015 at 08:29:53PM +1300, Richard Hector wrote:
>
> >I can run du, but that takes ages, and has a performance impact.
>
> With "idle" I/O scheduler class (set with ionice) does it still have
> a big performance impact?
This is basica
On Tue, 03 Mar 2015 09:55:46 +, Darac Marjal wrote:
> On Tue, Mar 03, 2015 at 10:09:41AM +0200, Johann Spies wrote:
>>
>>
>> I can run du, but that takes ages, and has a performance impact.
>> df only gives the total for the filesystem, of course.
>>
>>Try ncdu. It al
ful? Even without limits
set, but used just to track disk usage by individual users?
--
Jacek Politowski
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/15 23:17, Richard Hector wrote:
> On 03/03/15 22:55, Darac Marjal wrote:
>> On Tue, Mar 03, 2015 at 10:09:41AM +0200, Johann Spies wrote:
>>>
>>>
>>> I can run du, but that takes ages, and has a performance
>>> impact. df only gives the tota
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/15 22:55, Darac Marjal wrote:
> On Tue, Mar 03, 2015 at 10:09:41AM +0200, Johann Spies wrote:
>>
>>
>> I can run du, but that takes ages, and has a performance impact.
>> df only gives the total for the filesystem, of course.
>>
>> Try ncdu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/15 23:01, Alex Mestiashvili wrote:
> On 03/03/2015 09:22 AM, Richard Hector wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>> In this case, however, we know there's lots of space used, and
>> it's supposed to be - what we don'
On Tue, Mar 03, 2015 at 08:29:53PM +1300, Richard Hector wrote:
>I can run du, but that takes ages, and has a performance impact.
With "idle" I/O scheduler class (set with ionice) does it still have
a big performance impact?
--
Jacek Politowski
--
To UNSUBSCRIBE, email to debian-user-requ..
On 03/03/2015 09:22 AM, Richard Hector wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In this case, however, we know there's lots of space used, and it's
supposed to be - what we don't know is where in the tree that usage is
changing. That requires running du multiple times, and if done t
On Tue, Mar 03, 2015 at 10:09:41AM +0200, Johann Spies wrote:
>
>
> I can run du, but that takes ages, and has a performance impact. df
> only gives the total for the filesystem, of course.
>
>Try ncdu. It also takes some time to finish calculating, but the output
>is easi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/15 21:09, Johann Spies wrote:
>
>
>
> I can run du, but that takes ages, and has a performance impact.
> df only gives the total for the filesystem, of course.
>
>
> Try ncdu. It also takes some time to finish calculating, but the
> outp
> I can run du, but that takes ages, and has a performance impact. df
> only gives the total for the filesystem, of course.
>
>
Try ncdu. It also takes some time to finish calculating, but the output is
easier to handle and you can drill down to lower directories without losing
the other data.
Re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I have an issue with a (client's) large (13T) filesystem, that fills
up every now and then and nobody's quite sure what's doing it.
I can run du, but that takes ages, and has a performance impact. df
only gives the total for the filesystem, o
On Wed, 2014-06-25 at 12:42 -0600, ChadDavis wrote:
> I have a single partition mounted at '/'. When I run the disk usage
> utility, it shows That I have 66 GB remaining. Which is correct. But when
> I "scan home" it shows my home folder as 100% full.
>
> Why
On Wed, 2014-06-25 at 20:55 +0200, B wrote:
[...]
> And if your $HOME is really 100% full, that means you can't
> succeed making: touch ZZZ.ZZZ in it (as the right user).
Is that true? Using touch on a non-existent filename creates a file of
zero length, which I would assume for a lot of file
On Wed, 25 Jun 2014 12:42:53 -0600
ChadDavis wrote:
> I have a single partition mounted at '/'. When I run the disk
> usage utility, it shows That I have 66 GB remaining. Which is
> correct. But when I "scan home" it shows my home folder as 100%
> full.
What
I have a single partition mounted at '/'. When I run the disk usage
utility, it shows That I have 66 GB remaining. Which is correct. But when
I "scan home" it shows my home folder as 100% full.
Why would my home folder be full, when my there is just one huge partition
Dear users, I'm facing a curious problem with our local homedir server
and the clients (it's about exporting and importing NFS shares). The
server (running kernel 2.6.18) exports a filesystem and the clients
(running kernel 2.6.27) import it.
So, the problem is that commands sh
Jason Dunsmore wrote at 2009-05-04 08:26 -0600:
> Zhengquan Zhang writes:
> > I was doing du -ka . | sort -nr once in a while to do disk usage
> > analysis.
> >
> > I was wondering if anybody here are using a package that can do detailed
> > disk usage anal
--
Zhengquan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Le Monday 04 May 2009 16:07:27 Zhengquan Zhang, vous avez écrit :
> Dear debian community,
>
> I was doing du -ka . | sort -nr once in a while to do disk usage
> analysis.
>
> I was wondering if anybody here are using a package that can do detailed
> disk usage analysis. and
Zhengquan Zhang writes:
> Dear debian community,
>
> I was doing du -ka . | sort -nr once in a while to do disk usage
> analysis.
>
> I was wondering if anybody here are using a package that can do detailed
> disk usage analysis. and the program can email a detailed report t
on job:
@hourly /path/to/df.pl
I expect this help.
Claudio.
On Mon, May 4, 2009 at 11:07 AM, Zhengquan Zhang
wrote:
> Dear debian community,
>
> I was doing du -ka . | sort -nr once in a while to do disk usage
> analysis.
>
> I was wondering if anybody here are using
On Mon, May 4, 2009 at 4:07 PM, Zhengquan Zhang
wrote:
> Dear debian community,
>
> I was doing du -ka . | sort -nr once in a while to do disk usage
> analysis.
>
> I was wondering if anybody here are using a package that can do detailed
> disk usage analysis. and the program
Dear debian community,
I was doing du -ka . | sort -nr once in a while to do disk usage
analysis.
I was wondering if anybody here are using a package that can do detailed
disk usage analysis. and the program can email a detailed report to me?
Thanks for any pointers,
--
Zhengquan
--
To
Hi,
I guess minor problem of mixing 1000 base and 1024 base units has been
pointed but the difference is not about 3%. But 9.7GB vs 17GB used.
I tried it myself :-)
In my case, "du -hs /" is about 28G while "df -h" is about 18G for / and 11GB
on /mnt.
In your case "du..." is about 10G while
On Mon, Sep 03, 2007 at 02:07:01PM -0400, Daniel D Jones wrote:
> [EMAIL PROTECTED]:/# du --max-depth=1 -h
> 1.7G./var
> 32K ./tmp
> 4.0K./selinux
> 16K ./lost+found
> 16M ./boot
> 852K./home
> 0 ./sys
> 4.0K./initrd
> 22M ./etc
> 81M ./lib
> 515M./proc
On Mon, 3 Sep 2007, Jeff D wrote:
On Mon, 3 Sep 2007, Daniel D Jones wrote:
[EMAIL PROTECTED]:/# du --max-depth=1 -h
1.7G./var
32K ./tmp
4.0K./selinux
16K ./lost+found
16M ./boot
852K./home
0 ./sys
4.0K./initrd
22M ./etc
81M ./lib
515M./proc
6.3G
On Mon, 3 Sep 2007, Daniel D Jones wrote:
[EMAIL PROTECTED]:/# du --max-depth=1 -h
1.7G./var
32K ./tmp
4.0K./selinux
16K ./lost+found
16M ./boot
852K./home
0 ./sys
4.0K./initrd
22M ./etc
81M ./lib
515M./proc
6.3G./root
3.3M./sbin
3.7M./bi
Daniel D Jones wrote:
> [EMAIL PROTECTED]:/# du --max-depth=1 -h
> 1.7G./var
> 32K ./tmp
> 4.0K./selinux
> 16K ./lost+found
> 16M ./boot
> 852K./home
> 0 ./sys
> 4.0K./initrd
> 22M ./etc
> 81M ./lib
> 515M./proc
> 6.3G./root
> 3.3M./sbin
> 3.7M
[EMAIL PROTECTED]:/# du --max-depth=1 -h
1.7G./var
32K ./tmp
4.0K./selinux
16K ./lost+found
16M ./boot
852K./home
0 ./sys
4.0K./initrd
22M ./etc
81M ./lib
515M./proc
6.3G./root
3.3M./sbin
3.7M./bin
8.0K./media
8.0K./mnt
208K./dev
On 08.09.06 20:18, Christian Christmann wrote:
> on my Debian system the RAID discs are partitioned like that:
>
> /dev/md1 9.2G 8.2G 593M 94% /
> tmpfs 252M 16K 252M 1% /dev/shm
> /dev/md3 37G 33G 2.5G 94% /usr
> /dev/md0 92M
Christian Christmann([EMAIL PROTECTED]) is reported to have said:
> Hi,
>
> on my Debian system the RAID discs are partitioned like that:
>
> /dev/md1 9.2G 8.2G 593M 94% /
> tmpfs 252M 16K 252M 1% /dev/shm
> /dev/md3 37G 33G 2.5G 94% /usr
> /
Try du -x /
--
Andrew J Perrin - andrew_perrin (at) unc.edu - http://perrin.socsci.unc.edu
Assistant Professor of Sociology; Book Review Editor, _Social Forces_
University of North Carolina - CB#3210, Chapel Hill, NC 27599-3210
Hi,
on my Debian system the RAID discs are partitioned like that:
/dev/md1 9.2G 8.2G 593M 94% /
tmpfs 252M 16K 252M 1% /dev/shm
/dev/md3 37G 33G 2.5G 94% /usr
/dev/md0 92M 31M 57M 36% /boot
...
How can I determine where th
Miquel van Smoorenburg wrote:
On Thu, 2005-07-21 at 14:04 -0400, Daniel B. wrote:
...
... the reason I'm using PIO mode
in the first place is because I get massive file system corruption
when I use DMA mode with IDE controllers on my motherboard (Asus
A7M266-D; AMD 762(?) chipset).
...
I d
Hi Guys, I am planning to monitor debian server memory,cpu and disk usage.Currently we are monitoring other network resources using cacti.Now i am planning to monitor debian server through SNMP.Is there any othere easy solution to monitor memory,cpu and disk usage with graphs. If i to
Marty Landman wrote:
Worked like a charm, gotta read up on init - looks handy. Since df
looked good before running fsck wonder if something I did recently
messed up the display and just stopping my running processes fixed it?
Yeah that is kinda weird. My best guess is that since the kernel tr
At 12:18 PM 12/29/2005, Chris Howie wrote:
Try running fsck on the drive. It usually goes something like this:
# init 1
lots of crap while apps shut down
Including ssh. :) Console almost at arm's length though.
# mount / -o remount,ro
Went well; for the heck of it I did a df right afte
Marty:
Try running fsck on the drive. It usually goes something like this:
# init 1
lots of crap while apps shut down
# mount / -o remount,ro
if this fails at all, kill any processes that have files open for write
on / then try again. DO NOT run fsck if / is mounted read-write!
# fsck /de
Newbie here. Have Woody running on a P166 w/ 48MB ram and 4GB hd. Major
apps running ok - htdig, apache, samba. But when I look at disk usage get this:
UNCLELEO:/home/marty# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1-566353887454 1
I don't know if this is even possible but can I find out the disk
usage of a partition with a unknown or damaged filesystem?
Wouldn't it be possible to extract this quite simple using dumpe2fs?
It seems you can get some usefull numbers from the output of
$ dumpe2fs |hea
I don't know if this is even possible but can I find out the disk
usage of a partition with a unknown or damaged filesystem?
Wouldn't it be possible to extract this quite simple using dumpe2fs?
It seems you can get some usefull numbers from the output of
$ dumpe2fs |hea
Chris Palmer wrote:
If the filesystem is intact, you can also examine other fields (e.g.
s_blocks_count, s_free_blocks_count, s_log_block_size, et c.) to figure
out how much space is used.
Hopefully the original poster won't have to perform filesystem surgery.
:)
Nope! No reconstruction h
On 08/09/2005 09:11:54 PM, Colin Ingram wrote:
I don't know if this is even possible but can I find out the disk
usage of a partition with a unknown or damaged filesystem?
file -s /dev/fooa
will often tell you what sort of filesystem it is
and then you can try to mount or repair it
Roberto C. Sanchez writes:
> That doesn't seem to make sense. If you want to know how much is used
> up you need to at least be able to tell how many blocks are allocated
> or occupied by files. That implies that the filesystem must be known
> and readable.
True, but sometimes wrecked filesyste
1 - 100 of 139 matches
Mail list logo
