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}"
/
On 5/1/23 11:14, Bret Busby wrote:
On 5/1/23 06:51, Bonno Bloksma wrote:
Hi,
On my "new" Bullseye machines the root volume starts to fill up.
Have you tried running also
apt autoclean
and
apt purge
?
I updated and cleaned my daily driver recently:
2023-04-29 11:54:03 root@taz ~
# apt-ge
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#
>
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 would my home folder be full, when
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 do you call "scan home"?
> Why wo
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
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
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 |head -36
E.g. "
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 |head -36
E.g. "B
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.
(or "moun
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
On Tue, Aug 09, 2005 at 09:11:54PM -0500, 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?
>
That doesn't seem to make sense. If you want to know how much is used
up you need to at least be able t
On Sat, Aug 11, 2001 at 10:07:01PM -0500, [EMAIL PROTECTED] wrote:
> I'm wondering about techniques for system optimization. "df" reports that
> I am at 53% usage, which seems really high to me, even given that I
> recently partitioned the HD in two so that I could have FreeBSD running on
> my mach
On Sat, 11 Aug 2001 [EMAIL PROTECTED] wrote:
>
> Hi,
>
> Sort of a vague-y question here ... I'm getting back down into my system
> after being, uh, -laid off- on Wednesday, so I have time to play.
>
> I'm wondering about techniques for system optimization. "df" reports that
> I am at 53% usage
Christian van Enckevort wrote:
> Maybe lsof can help you. It gives a list of open files. There is a debian
> package for lsof. Unfortunately it is kernel dependent. The slink version
> only works for 2.0.35.
That is not true. The slink version for example also works on a 2.0.36
kernel. However, yo
Hi Chris,
Maybe lsof can help you. It gives a list of open files. There is a debian
package for lsof. Unfortunately it is kernel dependent. The slink version
only works for 2.0.35.
Greetings,
Christian van Enckevort
I just discovered an additional problem with my new des-solnet_1.03-4
package - on two of my systems, the "lwatchd" daemon (which I wrote)
died last night, but the desclient-x86-linux client kept running,
which is sort of good. I'm not sure why.
So keep this in mind before you upgrade -- if l
> If anyone is running the des-solnet daemon from non-us, be aware that you
> should stop and restart it daily or you might find your disk space being
> eaten up.
>
> The problem is that it rolls the logs without stopping the program. The
> program continues writing to the rolled logfile UNTIL t
69 matches
Mail list logo
