On Mon 12 Aug 2019 at 07:59:03 (+), Long Wind wrote:
>
> for reason i don't know, i see your reply just an hour ago, sorry for delay!
>
> i'm not sure if power key is key on keyboard or button on PC case
If the one on the PC case got stuck, I would expect the machine to
power down. So
On Mon 05 Aug 2019 at 16:33:29 (-), Curt wrote:
> On 2019-08-05, davidson wrote:
> >
> > To me it looks like the log below is telling you that your power key
> > was either being held down or stuck in that position.
> >
> > That is all.
>
> Whatever libinput is trying to say is apparently
On 2019-08-05, davidson wrote:
>
> To me it looks like the log below is telling you that your power key
> was either being held down or stuck in that position.
>
> That is all.
Whatever libinput is trying to say is apparently repeated to the point
where I would consider the repetition itself to
On Mon, 5 Aug 2019, Long Wind wrote:
Thank David!it seems it's bug of X
tail -100 .local/share/xorg/Xorg.1.log
To me it looks like the log below is telling you that your power key
was either being held down or stuck in that position.
That is all.
[ 21261.465] (EE) libinput bug: Key count
On Sun 04 Aug 2019 at 20:56:01 (+), Long Wind wrote:
> the file is more than 3 G, i can't read it with nanoi have 3 G memory, no
> swap
> why don't X print important error msg to terminals?i can't see any of them
>
> is it a bug of X?? my problem isn't solved,
> ls .local/share/xorg/
Le 04/08/2019 à 22:56, Long Wind a écrit :
the file is more than 3 G, i can't read it with nanoi have 3 G memory, no swap
You do not use an *editor* to *read* a file, you use a pager such as
more, less, most...
why don't X print important error msg to terminals?i can't see any of them
On Sun 04 Aug 2019 at 13:06:07 (+0200), Pascal Hambourg wrote:
> Le 04/08/2019 à 12:43, Long Wind a écrit :
> > i think i find out
> > it's in ~/.local it's Xorg.0.log.old
> > it's more than 3.9G
> > it seems keeping growing
> > clearly i don't need it, i delete it
> > it should solve my problem
>
Le 04/08/2019 à 12:43, Long Wind a écrit :
i think i find out
it's in ~/.local it's Xorg.0.log.old
it's more than 3.9G
it seems keeping growing
clearly i don't need it, i delete it
it should solve my problem
What about Xorg.0.log ?
If these files keep growing up to such a size, then it means
i think i find outit's in ~/.local it's Xorg.0.log.oldit's more than 3.9Git
seems keeping growingclearly i don't need it, i delete it
it should solve my problem
Thanks to all that reply!
On Sunday, August 4, 2019, 6:26:11 PM GMT+8, to...@tuxteam.de
wrote:
On Sun, Aug 04, 2019 at
On Sun, Aug 04, 2019 at 09:37:12AM +, Long Wind wrote:
> thank! i enter "du -sh /home", it's 5.8G. it's unbelievable
You mean: it is more than you expected? If so, you can try
du -sh /home/*
to see which subdirectory holds the biggest chunk, and slowly
work your way down the directory
On 04/08/2019 11.58, Andrei POPESCU wrote:
> On Du, 04 aug 19, 11:46:31, Étienne Mollier wrote:
>> This space is most likely taken up by file system metadata, such
>> as inode tables, or journaling space. 0.5 G looks a lot like 5%
>> of a 10 G partition, which is the default setting for Ext4
>>
On Du, 04 aug 19, 11:46:31, Étienne Mollier wrote:
>
> This space is most likely taken up by file system metadata, such
> as inode tables, or journaling space. 0.5 G looks a lot like 5%
> of a 10 G partition, which is the default setting for Ext4
> metadata as provided in Debian Installer.
The
Hi,
Long Wind wrote:
> /dev/sda2 9.8G 9.3G 0 100% /
I place my bet on the highest rated answer in
https://unix.stackexchange.com/questions/7950/reserved-space-for-root-on-a-filesystem-why
mattdm wrote there:
"Ext3 is pretty good at avoiding filesystem fragmentation, but once
On Du, 04 aug 19, 08:32:00, Long Wind wrote:
> i have stretch at sda2, which has 9.8Gfree space is far more than 1 Gbut some
> program i'm unware of take all space
> how to find out and solve? Thanks!
To find out what files are taking up the space
Command line:
du -hx --maxdepth=1 | sort
Long Wind, on 2019-08-04:
> i enter "df -h"
> Filesystem Size Used Avail Use% Mounted on
> [...]
> /dev/sda2 9.8G 9.3G 0 100% /
> ..
>
> 0.5 G seems missing
This space is most likely taken up by file system metadata, such
as inode tables, or journaling space. 0.5 G looks a
tomás, on 2019-08-04:
> On Sun, Aug 04, 2019 at 08:32:00AM +, Long Wind wrote:
> > i have stretch at sda2, which has 9.8G
> > free space is far more than 1 G
> > but some program i'm unware of take all space
> >
> > how to find out and solve? Thanks!
>
> Your request is too general for a
On Sun, Aug 04, 2019 at 08:32:00AM +, Long Wind wrote:
> i have stretch at sda2, which has 9.8Gfree space is far more than 1 Gbut some
> program i'm unware of take all space
> how to find out and solve? Thanks!
Your request is too general for a meaningful answer.
First off, space on a file
On Sat, Jul 10, 1999 at 01:53:51PM -0500, Alexander Kushnirenko wrote:
==
How does it look like:
kushnir cd ~
kushnir du -sk .
151081 .
kushnir du -sk * | sort -nr | head
11447 charm
I think that using `-a'
On Sat, 10 Jul 1999, Alexander Kushnirenko wrote:
Hi, how are you?
I got a strange problem. I was running gimp processing quite big image, at
some point I got impatient and killed the program. To manipulate with image
GIMP has quite big buffers allocated on hard drive and now all that
On Fri, Jul 09, 1999 at 02:31:56AM +, kpanic wrote:
Hi,
You are absoultely right, file was ~/.gimp/gimpswap.455
Thank you
Sasha.
hi alexander,
I got a strange problem. I was running gimp processing quite big image, at
some point I got impatient and killed the program. To
Hi,
I got a strange problem. I was running gimp processing quite big image, at
some point I got impatient and killed the program. To manipulate with image
GIMP has quite big buffers allocated on hard drive and now all that space is
gone. Effectively du reports that my home area occupies 150
On Sat, Jul 10, 1999 at 01:53:51PM -0500, Alexander Kushnirenko wrote:
Hi,
I got a strange problem. I was running gimp processing quite big image, at
some point I got impatient and killed the program. To manipulate with image
GIMP has quite big buffers allocated on hard drive and now all
22 matches
Mail list logo