Re: partition reporting full, but not

2024-02-21 Thread David Wright
On Tue 20 Feb 2024 at 17:14:41 (+), debian-u...@howorth.org.uk wrote:
> Felix Miata  wrote:
> > Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> > 
> > > I just removed 3 snapshots from my daily driver with no change in
> > > used space reported by df  
> > 
> > df doesn't know how to calculate freespace on btrfs. You need to be
> > typing
> > 
> > btrfs filesystem df
> 
> df [options] 
>Show a terse summary information about allocation of block
>group types of a given mount point. The original purpose of
>this command was a debugging helper. The output needs to be
>further interpreted and is not suitable for quick overview.
> 
> 
> FWIW my root filesystem is btrfs and I use the normal df command all the
> time without a problem. I've never used btrfs filesystem df

Would it matter if you're not running your filesystem close to full?

Cheers,
David.



Re: partition reporting full, but not

2024-02-21 Thread David Wright
On Mon 19 Feb 2024 at 10:26:05 (+1100), Keith Bainbridge wrote:
> On 18/2/24 14:49, Keith Bainbridge wrote:
> > On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:
> > > Keith Bainbridge wrote:
> > > > Yes the / partitions are btrfs
> > > 
> > > So the apparently missing space is perhaps taken up by btrfs snapshots.
> > > 
> > 
> > Seems to be the prime suspect.   If that's the case, btrfs is NOT
> > hard- linking the snapshots as timeshift claims it does. The only
> > way to check is install on ext4 and compare. I have saves enough
> > free space to do this.
> > 
> > My effort to date is to move my home to /mnt/data and sim-link it
> > into / home. df is now showing 2.3GB free on /.  df showed /home
> > as 2.2GB yesterday.  At least there is a little space to play
> > with; and give me time to consider. A fresh install may be worth
> > checking in snapshots are as big as this all makes them look.
> > 
> > a few brief answer to other comments will follow
> 
> 
> So later yesterday afternoon I created a new snapshot with no obvious
> change is free space.

That would seem reasonable, as there's not much more to do than note
which files the snapshot contains.

> I then update/upgrade.   The initial attempt told me
> 63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
> Need to get 337 MB of archives.
> After this operation, 473 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
> 
> But the 3 kernel related packages failed to install a couple of times.
> When I finally figured I should check space, there was none.   I
> rolled back to prior to the upgrade, but still no free space.
> 
> I said sometime in this thread that timeshift (and BiT) use hard links
> to create progressive copies of the system. The more I think about how
> hard links reportedly work, I reckon it can't be simply hard links.

Reading a tiny bit of the BTRFS docs, I would suggest that you're not
taking Block Groups into account. If BTRFS allocates data chunks in
blocks of 1GB, then it's conceivable that an upgrade involving 473MB
of data, plus the consequential increase in the size of the snapshot,
could all reside in a very recently created Block Group.

Put another way, df would see no change in Used and Available (as no
new Block Group allocation), whereas I would expect   btrfs filesystem df
to report a change here (because it knows what's within its Block
Groups):

> Data, single: total=32.80GiB, used=31.94GiB
> Tue 20Feb2024@20:57:45

Cheers,
David.



Re: partition reporting full, but not

2024-02-20 Thread tomas
On Wed, Feb 21, 2024 at 12:21:05PM +1100, Keith Bainbridge wrote:
> 
> On 21/2/24 10:47, Felix Miata wrote:
> > I didn't think so, which begs the question why OP Keith is using it. :p
> > -- 
> 
> I read somewhere about 2 years ago,  that it automagically de-duped data
> when it detected I was copying the same file to different directories [...]

I think the Wikipedia [1] is a good ref, at least at the level we are
discussing. 

Deduplication is mentioned there requiring userspace tools, so it seems
you'll have to run a process (as a daemon, from cron, whatever) to achieve
that.

It also mentions "reflinks", which is a kind of COW file copy (not to be
confused with a hardlink, which all civilised file systems have).

Cheers
[1] https://en.wikipedia.org/wiki/Btrfs#List_of_features
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-20 Thread Keith Bainbridge



On 21/2/24 10:47, Felix Miata wrote:

I didn't think so, which begs the question why OP Keith is using it. :p
--


I read somewhere about 2 years ago,  that it automagically de-duped data 
when it detected I was copying the same file to different directories. 
It's not deliberate, but I have often found copies of my files amongst 
files I have backed up for my wife (where I have put copies of my 
important stuff occasionally.And more common if I rsync a usb to a 
new destination - the usb I use at a volunteer job with portable apps on 
a foreign PC.   I found what I think was that article the other week; 
and it now talks about a manual process to de-dupe the data. I don't 
believe I could have skipped the most important paragraph in the 
article. I prefer rdfind -makehardlinks.Writing to btrfs feels 
quicker than ext4


But why use btrfs on a system partition. I like to try new stuff. Like I 
get a nagging thought of trying arch linux regularly. I resist 
mostly..   I should use sid as my daily driver, but I'm not good at 
asking for help; and I get the feeling that some people here would want 
to tell me something like 'I made my bed, lay in it.'



 So I make do with using developer versions of firefox & thunderbird 
and beta libreOffice (24.02 I think) They are on a separate partition 
from my system.


--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-20 Thread Felix Miata
Keith Bainbridge composed on 2024-02-21 11:57 (UTC+1100):
 
> Felix Miata wrote:

>> A current thread from elsewhere that should be helpful:
>> > really-the-solution/172576>
 
>>  btrfs filesystem usage /
>>  snapper list
>>  btrfs qgroup show /
 
> Thanks for the prompt, Felix
 
>>> sudo btrfs filesystem usage /
> [sudo] password for root:
> Overall:
>  Device size:   70.00GiB   = remember I expanded this 
> partition 
> yesterday 

How? Did you resize the filesystem too?

-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-20 Thread Keith Bainbridge



On 21/2/24 11:38, Felix Miata wrote:

A current thread from elsewhere that should be helpful:



btrfs filesystem usage /
snapper list
btrfs qgroup show /


Thanks for the prompt, Felix

  >> sudo btrfs filesystem usage /
[sudo] password for root:
Overall:
Device size:		  70.00GiB   = remember I expanded this partition 
yesterday

Device allocated: 35.82GiB
Device unallocated:   34.18GiB
Device missing:  0.00B
Device slack:0.00B
Used: 34.30GiB
Free (estimated): 34.90GiB  (min: 17.81GiB)
Free (statfs, df):34.90GiB
Data ratio:   1.00
Metadata ratio:   2.00
Global reserve:   71.69MiB  (used: 0.00B)
Multiple profiles:  no

Data,single: Size:32.80GiB, Used:32.09GiB (97.82%)
   /dev/sda3  32.80GiB

Metadata,DUP: Size:1.50GiB, Used:1.11GiB (73.77%)
   /dev/sda3   3.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/sda3  16.00MiB

Unallocated:
   /dev/sda3  34.18GiB
keith@dell0 $

 Wed 21Feb2024@11:44:26
 :~

At least I can make sense from some of these output numbers

  >> sudo btrfs qgroup show /
ERROR: can't list qgroups: quotas not enabled
keith@dell0 $

 Wed 21Feb2024@11:47:13
 :~

installed snapper and
   >> sudo snapper list
The config 'root' does not exist. Likely snapper is not configured.
See 'man snapper' for further instructions.
keith@dell0 $

More to learn about, I see


--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-20 Thread Felix Miata
to...@tuxteam.de composed on 2024-02-20 09:38 (UTC+0100):

> On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:

>> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

>>> I just removed 3 snapshots from my daily driver with no change in used 
>>> space reported by df

>> df doesn't know how to calculate freespace on btrfs. You need to be typing

>>  btrfs filesystem df

>> if you have not aliased df to btrfs filesystem df.

> Still, Keith seems to have a real shortage of file system free space,
> otherwise Debian upgrades wouldn't fail.

> I don't know much about btrfs, but what would be really helpful (if
> you do, and it seems so) would be for you to fill us in on how to
> asses the space used up by old snapshots (what seems to be the main
> suspect currently).

A current thread from elsewhere that should be helpful:


btrfs filesystem usage /
snapper list
btrfs qgroup show /

Was requested by a btrfs expert.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-20 Thread Felix Miata
Greg Wooledge composed on 2024-02-20 14:56 (UTC-0500):

> On Tue, Feb 20, 2024 at 02:47:26PM -0500, Felix Miata wrote:

>> Surely somewhere on debian.org such things must be addressed if Bookworm's 
>> default
>> has also been changed to btrfs.

> That has not happened.  The default file system is still ext4.

I didn't think so, which begs the question why OP Keith is using it. :p
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-20 Thread Greg Wooledge
On Tue, Feb 20, 2024 at 02:47:26PM -0500, Felix Miata wrote:
> Surely somewhere on debian.org such things must be addressed if Bookworm's 
> default
> has also been changed to btrfs.

That has not happened.  The default file system is still ext4.



Re: partition reporting full, but not

2024-02-20 Thread Felix Miata
to...@tuxteam.de composed on 2024-02-20 09:38 (UTC+0100):

> On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:

>> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

>> > I just removed 3 snapshots from my daily driver with no change in used 
>> > space reported by df

>> df doesn't know how to calculate freespace on btrfs. You need to be typing

>>  btrfs filesystem df

>> if you have not aliased df to btrfs filesystem df.

> Still, Keith seems to have a real shortage of file system free space,
> otherwise Debian upgrades wouldn't fail.

> I don't know much about btrfs, but what would be really helpful (if
> you do, and it seems so) would be for you to fill us in on how to
> asses the space used up by old snapshots (what seems to be the main
> suspect currently).

My hands-on experience with btrfs is limited to one laptop my brother gave me 
with
openSUSE installed that I only boot 2-3 times per year. My mentioning of the 
btrfs
command in this thread is based upon years of frequenting openSUSE and Fedora
mailing lists and forums. openSUSE made btrfs its default filesystem somewhere
around 7-8 years ago. I think Fedora made btrfs default more recently. Google &
DDG should be able to provide much better help than I on how to interpret btrfs
command output. So should supp...@lists.opensuse.org and
https://forums.opensuse.org/c/english/install-boot-login/18 and the comparable
Fedora forums. My own Gnu/Linux installations, other than Knoppix, have always
been on extX.

I suggest Keith's 36G / partition size must be a marginal for btrfs use. IIRC, 
40G
may be the officially suggested minimum size for an openSUSE btrfs / filesystem
where /home/ is on a separate (xfs) filesystem. Keith has /home/ within /.

Surely somewhere on debian.org such things must be addressed if Bookworm's 
default
has also been changed to btrfs.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-20 Thread debian-user
Felix Miata  wrote:
> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> 
> > I just removed 3 snapshots from my daily driver with no change in
> > used space reported by df  
> 
> df doesn't know how to calculate freespace on btrfs. You need to be
> typing
> 
>   btrfs filesystem df

df [options] 
   Show a terse summary information about allocation of block
   group types of a given mount point. The original purpose of
   this command was a debugging helper. The output needs to be
   further interpreted and is not suitable for quick overview.


FWIW my root filesystem is btrfs and I use the normal df command all the
time without a problem. I've never used btrfs filesystem df



Re: partition reporting full, but not

2024-02-20 Thread Thomas Schmitt
Hi,

> when cfdisk reports:
> Device  Start   End  Sectors   Size  Type
> /dev/sda2   1785522176  1786245119 722944  353M  EFI System
> /dev/sda3   1786245120  1933045759  146800640  70G   EFI System
> I don't understand the 'EFI System' note /dev/sda3 is /

The partition type does not necessarily match the type of filesystem
which is currently in that partition. It's just a field in the
partition table which must have some value.


Have a nice day :)

Thomas



Re: partition reporting full, but not

2024-02-20 Thread tomas
On Tue, Feb 20, 2024 at 09:21:15PM +1100, Keith Bainbridge wrote:
> 
> On 20/2/24 19:38, to...@tuxteam.de wrote:

[...]

> Tomas, the upgrade failure was earlier than these notes. It has now worked

I see.

> Sorry, but I don't know how to assess the snapshot space usage.

Nor do I -- my question was rather directed at Felix, who seems to
be the only one in this thread with some btrfs experience.

Perhaps it'd be wise to include "btrfs" in the Subject to attract
the attention of btrfs buffs?

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-20 Thread Keith Bainbridge



On 20/2/24 19:38, to...@tuxteam.de wrote:

On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:

Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):


I just removed 3 snapshots from my daily driver with no change in used
space reported by df


df doesn't know how to calculate freespace on btrfs. You need to be typing

btrfs filesystem df

if you have not aliased df to btrfs filesystem df.


Still, Keith seems to have a real shortage of file system free space,
otherwise Debian upgrades wouldn't fail.

I don't know much about btrfs, but what would be really helpful (if
you do, and it seems so) would be for you to fill us in on how to
asses the space used up by old snapshots (what seems to be the main
suspect currently).

Cheers


Tomas, the upgrade failure was earlier than these notes. It has now worked

Sorry, but I don't know how to assess the snapshot space usage.

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-20 Thread Keith Bainbridge



On 20/2/24 18:42, Felix Miata wrote:

btrfs filesystem df


OK, so please interpret:

  >> btrfs filesystem df -h /
Data, single: total=32.80GiB, used=31.94GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.50GiB, used=1.10GiB
GlobalReserve, single: total=71.69MiB, used=0.00B
keith@dell0 $

 Tue 20Feb2024@20:57:45
 :~

  >> btrfs filesystem df -h /mnt/data/
Data, single: total=530.02GiB, used=329.55GiB
System, DUP: total=8.00MiB, used=112.00KiB
Metadata, DUP: total=5.00GiB, used=1.10GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
keith@dell0 $

when cfdisk reports:
 DeviceStartEnd 
Sectors   Size Type
>>  /dev/sda1 2048 1667678207 
1667676160 795.2G Linux filesystem
Free space   1667678208 1785522175 
117843968  56.2G
/dev/sda21785522176 1786245119 
   722944   353M EFI System
/dev/sda31786245120 1933045759 
14680064070G EFI System
/dev/sda41933045760 1953523711 
 20477952   9.8G Linux swap


To clarify
/dev/sda1 is /mnt/dataand I don't understand the 'EFI System' note
/dev/sda3 is /

Perhaps the explanation why the reports from btrfs filesystem df make no 
sense will come when I get into my assignment?


--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-20 Thread tomas
On Tue, Feb 20, 2024 at 02:42:18AM -0500, Felix Miata wrote:
> Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):
> 
> > I just removed 3 snapshots from my daily driver with no change in used 
> > space reported by df
> 
> df doesn't know how to calculate freespace on btrfs. You need to be typing
> 
>   btrfs filesystem df
> 
> if you have not aliased df to btrfs filesystem df.

Still, Keith seems to have a real shortage of file system free space,
otherwise Debian upgrades wouldn't fail.

I don't know much about btrfs, but what would be really helpful (if
you do, and it seems so) would be for you to fill us in on how to
asses the space used up by old snapshots (what seems to be the main
suspect currently).

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-19 Thread Keith Bainbridge



On 20/2/24 18:11, Keith Bainbridge wrote:


On 19/2/24 14:20, Keith Bainbridge wrote:


On 19/2/24 10:26, Keith Bainbridge wrote:


On 18/2/24 14:49, Keith Bainbridge wrote:


On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:

Keith Bainbridge  wrote:

Yes the / partitions are btrfs


So the apparently missing space is perhaps taken up by btrfs 
snapshots.




Seems to be the prime suspect.   If that's the case, btrfs is NOT 
hard- linking the snapshots as timeshift claims it does. The only 
way to check is install on ext4 and compare. I have saves enough 
free space to do this.


My effort to date is to move my home to /mnt/data and sim-link it 
into / home. df is now showing 2.3GB free on /.  df showed /home as 
2.2GB yesterday.  At least there is a little space to play with; and 
give me time to consider. A fresh install may be worth checking in 
snapshots are as big as this all makes them look.


a few brief answer to other comments will follow



So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


I then update/upgrade.   The initial attempt told me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.
After this operation, 473 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But the 3 kernel related packages failed to install a couple of 
times. When I finally figured I should check space, there was none.   
I rolled back to prior to the upgrade, but still no free space.


I said sometime in this thread that timeshift (and BiT) use hard 
links to create progressive copies of the system. The more I think 
about how hard links reportedly work, I reckon it can't be simply 
hard links.


So I'm starting a new thread on that topic.




So I'm back to see some more helpful hints. Thanks folk

I am convinced that the missing space is used by btrfs snapshot 
process. But WHY is the used space reporting on my daily driver LESS 
than that on the spare machine  29G vs 35G? The original install was 
the same .iso   Ah well


I could add some of the spare space the the / partition, but how much? 
Play safe and use the lot, making it 60G compared to 63G on my daily 
driver. (And create some free space off the data partition before it's 
too late.)


Just as well I have time on my hands

Again, thanks to all for your suggestions



I am sure I saw a response to comment of mine, where I was misunderstood 
in the numbers I quoted for used space on my daily driver - 29G; and the 
space used by the problem machine - 35G.  There was a suggestion that I 
had not updated it as often as daily driver.    I had kept problem box 
as up to date as daily until a few days ago when it refused to update 
due to lack of space. This is when I discovered I had a problem. It is 
switched off at present, pending my deciding whether to expand / 
partition or re-install on the free space on ext4.   I will delete a few 
snapshots before I proceed, just to see what happens - I'll do that 
shortly, in fact, now I can see that it may have a bigger affect than I 
figured.


Now a minor amendment to my last note, where deleting snapshots has haad 
no bearing on used space.  Before I started, df reported 28G used, 
compared to 29G used yesterday. Remember my home is sym-linked from 
another partition. du is reporting /home is 3M which is the original / 
home/keith and re-named to keep it handy IN CASE I need it some day - 
like when I did some major surgery on that data partition the other 
week.  I'm trying to say that nothing I've done overnight has changed 
used space.  There were no packages to upgrade today.


df is now reporting 27G used on /   confirming btrfs seems to take time 
to reflect changes in snapshots.


Back later.




Back. On booting up problem machine I was greeted with warnings in disk 
space low on /. I generally don't log into desktop on this machine. 
Deleted 4 snapshots. df immediately reported used space 33G (down from 
35G) and free space 2.9G, up from ~200M at login.  I don't think I've 
EVER seen used space and free space equal size before.


I rebooted just to see if anything changed. 10 mins later df is still 
reporting

Size  Used Avail Use% Mounted on
36G   33G  2.9G  92% /


apt update/upgrade gave me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.


which I reckon is what I got yesterday after I moved my home to my data 
partition and


Quoted from 19Feb at 10:26  (UTC 18Feb at 23:26):
I then update/upgrade.   The initial attempt told me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.
After this operation, 473 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But the 3 kernel related packages failed to install a couple of times. 
When I finally figured I should check space, there was none.   I rolled 
back to prior to the upgrade, but still no free space.


And earlier:My 

Re: partition reporting full, but not

2024-02-19 Thread Felix Miata
Keith Bainbridge composed on 2024-02-20 17:45 (UTC+1100):

> I just removed 3 snapshots from my daily driver with no change in used 
> space reported by df

df doesn't know how to calculate freespace on btrfs. You need to be typing

btrfs filesystem df

if you have not aliased df to btrfs filesystem df.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-19 Thread Keith Bainbridge



On 19/2/24 14:20, Keith Bainbridge wrote:


On 19/2/24 10:26, Keith Bainbridge wrote:


On 18/2/24 14:49, Keith Bainbridge wrote:


On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:

Keith Bainbridge  wrote:

Yes the / partitions are btrfs


So the apparently missing space is perhaps taken up by btrfs snapshots.



Seems to be the prime suspect.   If that's the case, btrfs is NOT 
hard- linking the snapshots as timeshift claims it does. The only way 
to check is install on ext4 and compare. I have saves enough free 
space to do this.


My effort to date is to move my home to /mnt/data and sim-link it 
into / home. df is now showing 2.3GB free on /.  df showed /home as 
2.2GB yesterday.  At least there is a little space to play with; and 
give me time to consider. A fresh install may be worth checking in 
snapshots are as big as this all makes them look.


a few brief answer to other comments will follow



So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


I then update/upgrade.   The initial attempt told me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.
After this operation, 473 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But the 3 kernel related packages failed to install a couple of times. 
When I finally figured I should check space, there was none.   I 
rolled back to prior to the upgrade, but still no free space.


I said sometime in this thread that timeshift (and BiT) use hard links 
to create progressive copies of the system. The more I think about how 
hard links reportedly work, I reckon it can't be simply hard links.


So I'm starting a new thread on that topic.




So I'm back to see some more helpful hints. Thanks folk

I am convinced that the missing space is used by btrfs snapshot process. 
But WHY is the used space reporting on my daily driver LESS than that on 
the spare machine  29G vs 35G? The original install was the same .iso 
  Ah well


I could add some of the spare space the the / partition, but how much? 
Play safe and use the lot, making it 60G compared to 63G on my daily 
driver. (And create some free space off the data partition before it's 
too late.)


Just as well I have time on my hands

Again, thanks to all for your suggestions



I am sure I saw a response to comment of mine, where I was misunderstood 
in the numbers I quoted for used space on my daily driver - 29G; and the 
space used by the problem machine - 35G.  There was a suggestion that I 
had not updated it as often as daily driver.I had kept problem box 
as up to date as daily until a few days ago when it refused to update 
due to lack of space. This is when I discovered I had a problem. It is 
switched off at present, pending my deciding whether to expand / 
partition or re-install on the free space on ext4.   I will delete a few 
snapshots before I proceed, just to see what happens - I'll do that 
shortly, in fact, now I can see that it may have a bigger affect than I 
figured.


Now a minor amendment to my last note, where deleting snapshots has haad 
no bearing on used space.  Before I started, df reported 28G used, 
compared to 29G used yesterday. Remember my home is sym-linked from 
another partition. du is reporting /home is 3M which is the original 
/home/keith and re-named to keep it handy IN CASE I need it some day - 
like when I did some major surgery on that data partition the other 
week.  I'm trying to say that nothing I've done overnight has changed 
used space.  There were no packages to upgrade today.


df is now reporting 27G used on /   confirming btrfs seems to take time 
to reflect changes in snapshots.


Back later.

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-19 Thread Keith Bainbridge



On 19/2/24 13:00, Max Nikulin wrote:

On 19/02/2024 06:26, Keith Bainbridge wrote:


So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


Effect of snapshots is delayed. When you remove a file that does not 
belong to any snapshot, some disk space is reclaimed. However to restore 
a file (even a removed later) from a snapshot, it must be stored 
anywhere. That is why snapshots consume disk space.


Try to remove unnecessary snapshots. I have no idea if btrfs requires 
additional maintenance.




I just removed 3 snapshots from my daily driver with no change in used 
space reported by df


Mindful of the fact that somebody considers it may take time to reflect 
changes within the snapshots, I'll check again tomorrow morning



--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-19 Thread debian-user
David Christensen  wrote:
> On 2/18/24 19:20, Keith Bainbridge wrote:
> > I am convinced that the missing space is used by btrfs snapshot
> > process.  
> 
> 
> Perhaps.  But, are you re-balancing your btrfs file systems regularly?
> 
> https://manpages.debian.org/bookworm/btrfs-progs/btrfs-balance.8.en.html

But does balancing a btrfs system actually recover any space? I think
not. It's eternally moving the deckchairs on the Titanic. (though with
a more useful purpose)

I'd recommend installing snapper if you haven't already.
https://wiki.archlinux.org/title/Snapper is helpful for using it.

 



Re: partition reporting full, but not

2024-02-19 Thread DdB
Am 19.02.2024 um 04:20 schrieb Keith Bainbridge:
> I am convinced that the missing space is used by btrfs snapshot process.

First off: I am not a btrfs user (and will never be, i might add).
I am using zfs since many years, and - although i read an awful lot of
documentation beforehand, and played around with it quite a bit, i had
to learn a couple of lessons "the hard way".

To me, what i am inferring from your mails, are a couple of conceptual
misundestandings of what a COW-filesystem is, and how to best make use
of it. Especially the time-machine using snapshots and hardlinks seems
very kinky to me.

I am using zfs somewhat in a similar way, but it took me some years to
set it up in a good way. Apart from a warning and the usual RTFM, i do
not have much to offer. Except maybe for this: Snapshots hold space,
they are not like hardlinks. (although one can snapshot hardlinks ;-) )

Once, some older filesystem state is snapshotted, its space is taken
until the snapshot gets destroyed/removed. This can lead to situations,
where a device is full, but in order to free some space, deleting files
will NOT help, because in order to do so, a change in the directory
needs to be made, but there may not be the room to create a copy of it
in the first place.
And deleting files from a snapshot is not feasable (at least not in zfs).

To my eyes, your handling of the system looks somewhat risky and not
well planned. You may go on this way, as long as you consider the whole
thing as being part of a longish learning session. But do not trust
important data being safe this way!

just my 2 cents



Re: partition reporting full, but not

2024-02-18 Thread David Christensen

On 2/18/24 19:20, Keith Bainbridge wrote:

I am convinced that the missing space is used by btrfs snapshot process.



Perhaps.  But, are you re-balancing your btrfs file systems regularly?

https://manpages.debian.org/bookworm/btrfs-progs/btrfs-balance.8.en.html


Doing it by hand was not practical for me.  I wrote a Perl script to 
automate the process.  On SSD's, the results were decent.  On USB flash 
drives, not so much.



Searching for a power tool today, I see:

2024-02-18 23:27:43 dpchrist@laalaa ~/stretch-amd64
$ apt-cache search btrfs | grep mainten
btrfsmaintenance - automate btrfs maintenance tasks on mountpoints or 
directories


https://packages.debian.org/bookworm/btrfsmaintenance


I suggest installing and trying the btrfsmaintenance package.


David



Re: partition reporting full, but not

2024-02-18 Thread tomas
On Mon, Feb 19, 2024 at 02:20:20PM +1100, Keith Bainbridge wrote:

[...]

> I am convinced that the missing space is used by btrfs snapshot process. But
> WHY is the used space reporting on my daily driver LESS than that on the
> spare machine  29G vs 35G? The original install was the same .iso  Ah well

Perhaps because you upgrade your daily driver more often? May be
because it has more packages installed?

Another post of yours upthread suggests that your upgrade process roughly
is:

 1. take snapshot
 2. upgrade

Do you remove your snapshots if/after all went well? (note that I
have no idea how snapshots are removed under btrfs and whether they
are somehow visible to "du" -- I guess the second is a "no").

If not, the space is taken by all the files which have been overwritten
in the upgrade process. More "versions", less space.

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-18 Thread Keith Bainbridge



On 19/2/24 10:26, Keith Bainbridge wrote:


On 18/2/24 14:49, Keith Bainbridge wrote:


On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:

Keith Bainbridge  wrote:

Yes the / partitions are btrfs


So the apparently missing space is perhaps taken up by btrfs snapshots.



Seems to be the prime suspect.   If that's the case, btrfs is NOT 
hard- linking the snapshots as timeshift claims it does. The only way 
to check is install on ext4 and compare. I have saves enough free 
space to do this.


My effort to date is to move my home to /mnt/data and sim-link it 
into / home. df is now showing 2.3GB free on /.  df showed /home as 
2.2GB yesterday.  At least there is a little space to play with; and 
give me time to consider. A fresh install may be worth checking in 
snapshots are as big as this all makes them look.


a few brief answer to other comments will follow



So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


I then update/upgrade.   The initial attempt told me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.
After this operation, 473 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But the 3 kernel related packages failed to install a couple of times. 
When I finally figured I should check space, there was none.   I rolled 
back to prior to the upgrade, but still no free space.


I said sometime in this thread that timeshift (and BiT) use hard links 
to create progressive copies of the system. The more I think about how 
hard links reportedly work, I reckon it can't be simply hard links.


So I'm starting a new thread on that topic.




So I'm back to see some more helpful hints. Thanks folk

I am convinced that the missing space is used by btrfs snapshot process. 
But WHY is the used space reporting on my daily driver LESS than that on 
the spare machine  29G vs 35G? The original install was the same .iso 
 Ah well


I could add some of the spare space the the / partition, but how much? 
Play safe and use the lot, making it 60G compared to 63G on my daily 
driver. (And create some free space off the data partition before it's 
too late.)


Just as well I have time on my hands

Again, thanks to all for your suggestions

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-18 Thread Keith Bainbridge



On 19/2/24 13:41, Felix Miata wrote:

would be some places to start. Didn't you do your
https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html
reading yet? ?_?



My eyes have glazed over too often, already.  I know I have to get back, 
but that NEED to do it is making it harder.

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-18 Thread Felix Miata
Keith Bainbridge composed on 2024-02-18 14:49 (UTC+1100):

> debian-u...@howorth.org.uk wrote:

>> So the apparently missing space is perhaps taken up by btrfs snapshots.

> Seems to be the prime suspect. 

While snapshotting is obviously a consumer, until you use the right tool for the
job, you won't know anything meaningful about overall space usage on btrfs.

btrfs filesystem df
btrfs filesystem du
btrfs filesysten show

would be some places to start. Didn't you do your
https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html
reading yet? ?_?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-18 Thread Max Nikulin

On 19/02/2024 06:26, Keith Bainbridge wrote:


So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


Effect of snapshots is delayed. When you remove a file that does not 
belong to any snapshot, some disk space is reclaimed. However to restore 
a file (even a removed later) from a snapshot, it must be stored 
anywhere. That is why snapshots consume disk space.


Try to remove unnecessary snapshots. I have no idea if btrfs requires 
additional maintenance.




Re: partition reporting full, but not

2024-02-18 Thread Keith Bainbridge



On 18/2/24 14:49, Keith Bainbridge wrote:


On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:

Keith Bainbridge  wrote:

Yes the / partitions are btrfs


So the apparently missing space is perhaps taken up by btrfs snapshots.



Seems to be the prime suspect.   If that's the case, btrfs is NOT hard- 
linking the snapshots as timeshift claims it does. The only way to check 
is install on ext4 and compare. I have saves enough free space to do this.


My effort to date is to move my home to /mnt/data and sim-link it into / 
home. df is now showing 2.3GB free on /.  df showed /home as 2.2GB 
yesterday.  At least there is a little space to play with; and give me 
time to consider. A fresh install may be worth checking in snapshots are 
as big as this all makes them look.


a few brief answer to other comments will follow



So later yesterday afternoon I created a new snapshot with no obvious 
change is free space.


I then update/upgrade.   The initial attempt told me
63 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 337 MB of archives.
After this operation, 473 MB of additional disk space will be used.
Do you want to continue? [Y/n]

But the 3 kernel related packages failed to install a couple of times. 
When I finally figured I should check space, there was none.   I rolled 
back to prior to the upgrade, but still no free space.


I said sometime in this thread that timeshift (and BiT) use hard links 
to create progressive copies of the system. The more I think about how 
hard links reportedly work, I reckon it can't be simply hard links.


So I'm starting a new thread on that topic.


--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-18 Thread Keith Bainbridge



On 18/2/24 14:08, Max Nikulin wrote:

On 17/02/2024 09:52, Greg Wooledge wrote:

If so, you *could*  have data inside the /home directory
of the root file system, which is hidden by the /home file system that's
mounted over it.  You'd need to unmount /home to check.


A less intrusive way to inspect shadowed directories is bind mounts.

     mkdir /tmp/root
     mount --bind / /tmp/root




Thank you Max

This has proved a real boon
--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-17 Thread David Christensen

Keith Bainbridge composed on 2024-02-17 15:44 (UTC+1100):


Yes the / partitions are btrfs



Several years ago, I installed Debian (9?) using btrfs for root (and 
boot?).  I failed to understand that btrfs required regular maintenance 
and/or I was too lazy to figure it out and do it.  After a few months, 
the systems started running slowly and I seem to recall conflicting 
reports of storage usage.  I STFW, RTFM, etc., and tried doing the 
maintenance by hand.  I quickly came to the conclusion that I needed to 
run `btrfs balance start ...` many, many times.  So, I wrote Perl script 
and let it hammer on the file systems for hours at a time (!).  I was 
able to rescue most of the disks to decent performance, but one was 
especially bad and I was only able to rescue it to marginal performance. 
 I continued running btrfs for a while and running the Perl script 
periodically.  Ultimatedly, I backed up, put in fresh OS disks, and 
installed using ext4.  This was one of my reasons to use FreeBSD and ZFS 
for my SOHO servers.



David



Re: partition reporting full, but not

2024-02-17 Thread Keith Bainbridge



On 18/2/24 09:19, Cindy Sue Causey wrote:


I only know to say this because it just happened a few days ago. Rsync
left some semi-permanent remnants when I was having problems with the
wireless capable hard drive docking station repeatedly cutting out. I
was offloading videos and images from a camera during many of those
times.


Thanks Cindy

Interesting

Though as far as I can recall the only files I have rsync'd onto / are 
4or5 config files, and all in /home/keith which now on another 
partition. And with a gain in free space which virtually matches its 
reported space used, yesterday.



--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-17 Thread Keith Bainbridge



On 18/2/24 07:34, debian-u...@howorth.org.uk wrote:

Keith Bainbridge  wrote:
  

Yes the / partitions are btrfs


So the apparently missing space is perhaps taken up by btrfs snapshots.



Seems to be the prime suspect.   If that's the case, btrfs is NOT 
hard-linking the snapshots as timeshift claims it does. The only way to 
check is install on ext4 and compare. I have saves enough free space to 
do this.


My effort to date is to move my home to /mnt/data and sim-link it into 
/home. df is now showing 2.3GB free on /.  df showed /home as 2.2GB 
yesterday.  At least there is a little space to play with; and give me 
time to consider. A fresh install may be worth checking in snapshots are 
as big as this all makes them look.


a few brief answer to other comments will follow
--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-17 Thread Max Nikulin

On 17/02/2024 09:52, Greg Wooledge wrote:

If so, you *could*  have data inside the /home directory
of the root file system, which is hidden by the /home file system that's
mounted over it.  You'd need to unmount /home to check.


A less intrusive way to inspect shadowed directories is bind mounts.

mkdir /tmp/root
mount --bind / /tmp/root



Re: partition reporting full, but not

2024-02-17 Thread Cindy Sue Causey
On 2/17/24, Greg Wooledge  wrote:
> On Sat, Feb 17, 2024 at 04:00:14PM -0500, Stefan Monnier wrote:
>> > So the apparently missing space is perhaps taken up by btrfs snapshots.
>>
>> Another possibility is a (few) large file(s) that is/are still open for
>> some process(es) but have been `rm` (`unlink`) so they don't have a name
>> any more.
>
> In the original post, they said they rebooted, in order to rule this out.


I only know to say this because it just happened a few days ago. Rsync
left some semi-permanent remnants when I was having problems with the
wireless capable hard drive docking station repeatedly cutting out. I
was offloading videos and images from a camera during many of those
times.

There were 3 to 5 instances of discarded remnant files in several
directories while the problem was ongoing (MANY times over a couple
weeks). The residual files were only visible when in CTRL+H view in
Thunar. Sizes ranged from a few MB to almost a GB. All had to be
manually removed.

PS That hardware problem, which I think I mentioned in another thread,
is semi-solved... and appears to be a possible case of [WIFI] jamming,
of all things. If it starts up again, there will possibly be a new
thread asking about potential tracking packages. Current instant fix?
Tweet very loudly about the issue and its potential source

Cindy :)

NB See Also: Minnesota burglaries via suspected WIFI jamming (e.g. on reddit).
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *



Re: partition reporting full, but not

2024-02-17 Thread Greg Wooledge
On Sat, Feb 17, 2024 at 04:00:14PM -0500, Stefan Monnier wrote:
> > So the apparently missing space is perhaps taken up by btrfs snapshots.
> 
> Another possibility is a (few) large file(s) that is/are still open for
> some process(es) but have been `rm` (`unlink`) so they don't have a name
> any more.

In the original post, they said they rebooted, in order to rule this out.



Re: partition reporting full, but not

2024-02-17 Thread Stefan Monnier
> So the apparently missing space is perhaps taken up by btrfs snapshots.

Another possibility is a (few) large file(s) that is/are still open for
some process(es) but have been `rm` (`unlink`) so they don't have a name
any more.


Stefan



Re: partition reporting full, but not

2024-02-17 Thread debian-user
Keith Bainbridge  wrote:
 
> Yes the / partitions are btrfs

So the apparently missing space is perhaps taken up by btrfs snapshots.



Re: partition reporting full, but not

2024-02-17 Thread songbird
Keith Bainbridge wrote:
...
> No nfs mounts

  any swap partition or swap space?

  but other than that sharing /home with / is likely your
issue and you mention snapshots and backintime and i do
recall that needing plenty of space.

  as for btrfs, i have no clue, i've never touched it.


  songbird



Re: partition reporting full, but not

2024-02-17 Thread Keith Bainbridge



On 17/2/24 17:08, Felix Miata wrote:

Keith Bainbridge composed on 2024-02-17 15:44 (UTC+1100):


Yes the / partitions are btrfs


df was not designed for the task you gave it. You need to use

btrfs filesystem 

commands:
https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html




Seems I have some serious reading to do

Thanks for thelink
--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-16 Thread tomas
On Sat, Feb 17, 2024 at 03:44:49PM +1100, Keith Bainbridge wrote:

[...]

> df -h
> Filesystem  Size  Used Avail Use% Mounted on
> udev7.2G 0  7.2G   0% /dev
> tmpfs   1.5G  1.9M  1.5G   1% /run
> /dev/nvme0n1p2   63G   27G   35G  44% /
> tmpfs   7.3G   84M  7.2G   2% /dev/shm
> tmpfs   5.0M   16K  5.0M   1% /run/lock
> /dev/nvme0n1p2   63G   27G   35G  44% /home

[...]

> Yes the / partitions are btrfs
> > 
> The annoying habit of listing /home at df seems to be part of btrfs standard
> practice which I dislike [...]

Oh, wait! This is btrfs. It seems to be able to put more than one file
system in a partition (so no, it's not "standard practice": you have
two different file systems there, which df duly reports, but they seem
to co-habitate one partition)

This being btrfs... quite possibly the missing space is used up in
one or more snapshots?

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-16 Thread Felix Miata
Keith Bainbridge composed on 2024-02-17 15:44 (UTC+1100):

> Yes the / partitions are btrfs

df was not designed for the task you gave it. You need to use

btrfs filesystem 

commands:
https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: partition reporting full, but not

2024-02-16 Thread tomas
On Fri, Feb 16, 2024 at 09:52:22PM -0500, Greg Wooledge wrote:
> On Sat, Feb 17, 2024 at 01:38:56PM +1100, Keith Bainbridge wrote:
> >   >> sudo df -h /
> > Filesystem  Size  Used Avail Use% Mounted on
> > /dev/sda336G   35G  100M 100% /
> 
> First off: you don't need sudo for this, ever.
> 
> Second: what kind of file system is this?
> 
> > sudo du -hPx --max-depth=1 /
> > 0   /mnt
> > 181M/boot
> > 15M /etc
> > 0   /media
> > 236M/opt
> > 336K/root
> > 0   /srv
> > 4.0K/tmp
> > 8.1G/usr
> > 726M/var
> > 9.2G/
> 
> So I guess the question is "Where's the rest of that 35 G used data?"
> 
> Conspicuously missing from this output is /home.  Is that a separate
> file system?  If so, you *could* have data inside the /home directory
> of the root file system, which is hidden by the /home file system that's
> mounted over it.  You'd need to unmount /home to check.  It's not a
> super probable situation, but it's worth checking.

Absolutely. What I miss, too, is lost+found (not every file system has
that,i though).

> The same applies to any other directory that's got a file system mounted
> on it.

Yes, looking "under" the mounts is a very good idea.

> Or... it could be some bizarre btrfs crap.  If this is a btrfs.

We're all curious :-)

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition reporting full, but not

2024-02-16 Thread Keith Bainbridge



On 17/2/24 13:55, Gremlin wrote:

On 2/16/24 21:38, Keith Bainbridge wrote:

Good afternoon All

I have just rebooted this laptop to ensure it is 'fresh'

/ is reporting full.

Trying to locate where I ran

sudo du -hPx --max-depth=1 /
0    /mnt
181M    /boot
15M    /etc
0    /media
236M    /opt
336K    /root
0    /srv
4.0K    /tmp
8.1G    /usr
726M    /var
9.2G    /
keith@dell0 $

  Sat 17Feb2024@13:33:29
  :~


  But:
   >> sudo df -h /
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda3    36G   35G  100M 100% /
keith@dell0 $

  Sat 17Feb2024@13:33:39
  :~

Where do I start locating the conflicting information please?



Do you have any nfs mounts?






No nfs mounts

Thankyou

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-16 Thread Keith Bainbridge



On 17/2/24 13:52, Greg Wooledge wrote:

On Sat, Feb 17, 2024 at 01:38:56PM +1100, Keith Bainbridge wrote:

   >> sudo df -h /
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda336G   35G  100M 100% /


First off: you don't need sudo for this, ever.

Second: what kind of file system is this?


sudo du -hPx --max-depth=1 /
0   /mnt
181M/boot
15M /etc
0   /media
236M/opt
336K/root
0   /srv
4.0K/tmp
8.1G/usr
726M/var
9.2G/


So I guess the question is "Where's the rest of that 35 G used data?"

My wife is often telling me I'm not clear (obtuse). Thank you for 
clarifying the question



Conspicuously missing from this output is /home.  Is that a separate
file system?  If so, you *could* have data inside the /home directory
of the root file system, which is hidden by the /home file system that's
mounted over it.  You'd need to unmount /home to check.  It's not a
super probable situation, but it's worth checking.


I had wondered why /home was missing and concluded that as it's listed if I

df -h /home/
Filesystem  Size  Used Avail Use% 
Mounted on
/dev/sda3 ===same partiton as /   36G   35G  100M 100% /home
keith@dell0 $

Then
>> sudo du -hPx --max-depth=1  /home/
[sudo] password for root:
2.2G/home/keith
2.2G/home/
keith@dell0 $

So, part of the missing 35G, but nothing significant

I checked my daily driver - lenv0, and I have the same situation -

sudo du -hPx --max-depth=1 /
[sudo] password for root:
265M/boot
18M /etc
0   /media
947M/opt
1.5M/root
0   /srv
du: cannot access '/tmp/.mount_Espansr8ZHig': Permission denied
12M /tmp
9.6G/usr
1.8G/var
13G /

  >> sudo du -hPx --max-depth=1 /home/
3.0M/home/ke1th
3.0M/home/
keith@lenv0 $

df -h
Filesystem  Size  Used Avail Use% Mounted on
udev7.2G 0  7.2G   0% /dev
tmpfs   1.5G  1.9M  1.5G   1% /run
/dev/nvme0n1p2   63G   27G   35G  44% /
tmpfs   7.3G   84M  7.2G   2% /dev/shm
tmpfs   5.0M   16K  5.0M   1% /run/lock
/dev/nvme0n1p2   63G   27G   35G  44% /home

In this case /home/keith is a sym link to another partition.

But still 14GB difference between the 2 reporting processes.





The same applies to any other directory that's got a file system mounted
on it.


I have had data written to /mnt/someDisk when the partition was NOT 
mounted. I get that suggestion. Those instances showed up in du though.


Or... it could be some bizarre btrfs crap.  If this is a btrfs.


Yes the / partitions are btrfs


The annoying habit of listing /home at df seems to be part of btrfs 
standard practice which I dislike.   So far the ability to create 
timeshift and BackInTime snapshots in the proverbial blink of an eye are 
VERY good points for btrfs.Seems I need to allow for more more 
'slack' space as well?   du is reporting my timeshift directory as 0, 
and the internal subdir that lists save file as 108K. This tells me that 
btrfs is doing something magic.

Guess I'll be contemplating reinstalling onto ext4 in my sleep tonight.

To answer another question - no NFS

Thanks All

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
+61 (0)447 667 468

UTC + 10:00



Re: partition reporting full, but not

2024-02-16 Thread Gremlin

On 2/16/24 21:38, Keith Bainbridge wrote:

Good afternoon All

I have just rebooted this laptop to ensure it is 'fresh'

/ is reporting full.

Trying to locate where I ran

sudo du -hPx --max-depth=1 /
0    /mnt
181M    /boot
15M    /etc
0    /media
236M    /opt
336K    /root
0    /srv
4.0K    /tmp
8.1G    /usr
726M    /var
9.2G    /
keith@dell0 $

  Sat 17Feb2024@13:33:29
  :~


  But:
   >> sudo df -h /
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda3    36G   35G  100M 100% /
keith@dell0 $

  Sat 17Feb2024@13:33:39
  :~

Where do I start locating the conflicting information please?



Do you have any nfs mounts?





Re: partition reporting full, but not

2024-02-16 Thread Greg Wooledge
On Sat, Feb 17, 2024 at 01:38:56PM +1100, Keith Bainbridge wrote:
>   >> sudo df -h /
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda336G   35G  100M 100% /

First off: you don't need sudo for this, ever.

Second: what kind of file system is this?

> sudo du -hPx --max-depth=1 /
> 0 /mnt
> 181M  /boot
> 15M   /etc
> 0 /media
> 236M  /opt
> 336K  /root
> 0 /srv
> 4.0K  /tmp
> 8.1G  /usr
> 726M  /var
> 9.2G  /

So I guess the question is "Where's the rest of that 35 G used data?"

Conspicuously missing from this output is /home.  Is that a separate
file system?  If so, you *could* have data inside the /home directory
of the root file system, which is hidden by the /home file system that's
mounted over it.  You'd need to unmount /home to check.  It's not a
super probable situation, but it's worth checking.

The same applies to any other directory that's got a file system mounted
on it.

Or... it could be some bizarre btrfs crap.  If this is a btrfs.



Re: partition reporting full, but not

2024-02-16 Thread David Wright
On Sat 17 Feb 2024 at 13:38:56 (+1100), Keith Bainbridge wrote:
> I have just rebooted this laptop to ensure it is 'fresh'
> 
> / is reporting full.
> 
> Trying to locate where I ran
> 
> sudo du -hPx --max-depth=1 /
> 0 /mnt
> 181M  /boot
> 15M   /etc
> 0 /media
> 236M  /opt
> 336K  /root
> 0 /srv
> 4.0K  /tmp
> 8.1G  /usr
> 726M  /var
> 9.2G  /
> keith@dell0 $
> 
>  Sat 17Feb2024@13:33:29
>  :~
> 
> 
>  But:
>   >> sudo df -h /
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/sda336G   35G  100M 100% /
> keith@dell0 $
> 
>  Sat 17Feb2024@13:33:39
>  :~
> 
> Where do I start locating the conflicting information please?

Typically some space is reserved for root, so that you have a little
headroom to extricate yourself from this situation. It looks like it's
the 5% shown below (from an installer screen):

  ┌┤ [!!] Partition disks ├─┐   
  │ │   
  │ You are editing partition #3 of /dev/nvme0n1. This partition is │   
  │ formatted with the Ext4 journaling file system. All data in it WILL │   
  │ BE DESTROYED!   │   
  │ │   
  │ Partition settings: │   
  │ │   
  │  Name:  Umbo-B  │   
  │  Use as:Ext4 journaling file system │   
  │ │   
  │  Format the partition:  yes, format it  │   
  │  Mount point:   /   │   
  │  Mount options: defaults│   
  │  Label: umbo03  │   
  │  Reserved blocks:   5%  │   
  │  Typical usage: standard│   
  │  Bootable flag: off │   
  │ │   
  │  Resize the partition (currently 31.5 GB)   │   
  │  Erase data on this partition   │   
  │  Delete the partition   │   
  │  Done setting up the partition  │   
  │ │   
  ││   
  │ │   
  └─┘   

Cheers,
David.



Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-20 Thread tomas
On Fri, Jan 20, 2023 at 09:19:16AM +, thyme after thyme wrote:
> 
> Charles and tomas, you were both right in your guesses. Thanks a billion
> for the help!

Glad you found it :)

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-20 Thread Cindy Sue Causey
On 1/20/23, Anssi Saari  wrote:
> Jude DaShiell  writes:
>
>> I wonder if blkid might be a bit more informative.
>
> I don't know, I usually run mount without arguments to see what's
> mounted or look in the file /proc/mounts.


A super simple grep, e.g. "mount|grep sdc", works on it, too. I do it
all the time because it filters out the (visual) noise.

Every since I realized that, my chroot dismounts never fail. Prior to
that, I was having to mostly reboot to dislodge a chroot that had some
or another too "busy" to umount mount point that I couldn't ferret
out.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *



Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-20 Thread Anssi Saari
Jude DaShiell  writes:

> I wonder if blkid might be a bit more informative.

I don't know, I usually run mount without arguments to see what's
mounted or look in the file /proc/mounts.



Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-20 Thread thyme after thyme


Charles and tomas, you were both right in your guesses. Thanks a billion
for the help!



Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-19 Thread Jude DaShiell
I wonder if blkid might be a bit more informative.



Jude 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Fri, 20 Jan 2023, to...@tuxteam.de wrote:

> On Thu, Jan 19, 2023 at 11:03:14PM +, thyme after thyme wrote:
> > Hello lovely debianizers,
> >
> > My Debian 10 machine has two physical disks, sda and sdb. The
> > (encrypted) root filesystem is on sdb, meanwhile I?ve used
> > fstab/crypttab to mount an (encrypted) partition on sda to
> > /mnt/data01-hdd, where I?ve stored some stuff:
> >
> > user@hostname:/$ ls -gh /mnt/data01-hdd/
> > total 4.0K
> > drwxr-xr-x 5 1007 4.0K Jan  1 23:02 backups
>
> Perhaps that stuff is just on the directory (using space
> in the partition containing that directory...
>
> > However, when i do
> > user@hostname:/$ sudo umount /mnt/data01-hdd
> >
> > umount complains thus:
> > umount: /mnt/data01-hdd: not mounted.
>
> ...and the partition you think is mounted isn't, after all?
>
> You mount stuff on directories. Those are just plain old directories
> and you can put stuff in them without having anything mounted.
>
> Cheers
>



Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-19 Thread tomas
On Thu, Jan 19, 2023 at 11:03:14PM +, thyme after thyme wrote:
> Hello lovely debianizers,
> 
> My Debian 10 machine has two physical disks, sda and sdb. The
> (encrypted) root filesystem is on sdb, meanwhile I’ve used
> fstab/crypttab to mount an (encrypted) partition on sda to
> /mnt/data01-hdd, where I’ve stored some stuff:
> 
> user@hostname:/$ ls -gh /mnt/data01-hdd/
> total 4.0K
> drwxr-xr-x 5 1007 4.0K Jan  1 23:02 backups

Perhaps that stuff is just on the directory (using space
in the partition containing that directory...

> However, when i do
> user@hostname:/$ sudo umount /mnt/data01-hdd
> 
> umount complains thus:
> umount: /mnt/data01-hdd: not mounted.

...and the partition you think is mounted isn't, after all?

You mount stuff on directories. Those are just plain old directories
and you can put stuff in them without having anything mounted.

Cheers
-- 
t


signature.asc
Description: PGP signature


Re: partition appears to be mounted, but not according to umount or lsblk

2023-01-19 Thread Charles Curley
On Thu, 19 Jan 2023 23:03:14 +
thyme after thyme  wrote:

> However, when i do
> user@hostname:/$ sudo umount /mnt/data01-hdd
> 
> umount complains thus:
> umount: /mnt/data01-hdd: not mounted.

First off, don't tell us what the program did, show us exactly what the
program did by copying and pasting the initial prompt, the command, and
the following prompt. Like so:

root@ideapc:~# umount /media/disk
umount: /media/disk: not mounted.
root@ideapc:~# 


> 
> How can I unmount the partition?

I haven't seen any evidence that the partition has ever been mounted.
When and how do you think it was mounted, and how do you know? Have you
tried mounting it manually?

Your fstab has the following two (unwrapped) lines:

# 1000gb hdd via its LVM, cf. also /etc/crypttab
#/dev/mapper/1Terabyte01--vg-data01/mnt/data01-hdd ext4 default

That sharp (#) at the beginning of the second line means that line is
commented out. So I suspect the volume never was mounted.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/



Re: partition swap pleine à craquer ?

2022-03-02 Thread ajh-valmer
On Wednesday 02 March 2022 15:00:23 hamster wrote:
> Le 02/03/2022 à 14:17, ajh-valmer a écrit :
> > Juste cette observation, à quoi sert cette partition SWAP 
> > éternellement vide ? 
> Elle a 2 fonctions :
> - Sa fonction originale c'est que quand la RAM est pleine, il la déleste 
> dans cette partition. Ca fait que l'ordi se met a etre très lent mais au 
> moins il plante pas.
> - Il y a aussi un usage secondaire qui est que quand tu utilise la 
> fonction "hiberner" il copie le contenu de la RAM dans cette partition 
> puis il s'éteint. Quand tu le réveille, il commence par rapatrier les 
> données dans la RAM et tu retrouve ton travail en cours.
> C'est pour cette fonction secondaire que je fais toujours une partition 
> swap aussi grande que la RAM :
Merci.

On Wednesday 02 March 2022 17:51:56 Pierre Malard wrote:
> Et qu’est-ce que donne un « swap on —show » ? :
Cette commande ne fonctionne pas, c'est swapon : 
NAME  TYPE  SIZE USED PRIO
/dev/sda4 partition 8,1G   0B   -2

> Est-ce qu’il y a une partition swap déclarée dans le /etc/fstab 
> ou est-ce dans un fichier ? 
Oui, dans /etc/fstab

Bonne soirée.



Re: partition swap pleine à craquer ?

2022-03-02 Thread Pierre Malard
Et qu’est-ce que donne un « swap on —show » ?
Est-ce qu’il y a une partition swap déclarée dans le /etc/fstab ou est-ce dans 
un fichier ?

De toutes façons que le swap ne soit pas occupée est plutôt bon signe étant 
donné ce pourquoi elle est faite (décharger la RAM en cas de sur-occupation). 
Si elle était utilisée tu t’en apercevrai de suite et te plaindrai de la 
lenteur de ton poste.

> Le 2 mars 2022 à 11:40, ajh-valmer  a écrit :
> 
> Bonjour,
> 
> Voici ce que me répond la commande "free" :
> Partition d'échange :taille = 8488956   libre = 0 8488956 : ?
> La swap généralement est déclarée occupée = 0,
> à moins que ce soit un décalage des colonnes.
> 
> Merci, bonne journée.
> 

--
Pierre Malard

  « - Il n'y a que trois éléments indispensables à la vie.
Et il n'y a que les scientifiques pour penser que
c'est l'oxygène, l'hydrogène et le carbone...
  - Quoi alors ? L'eau, l'air et le feu ?
  - Non ! Le désir, le désordre et le danger... »
   Manon Briand ; La turbulence des fluides
(film québécois de 2001)
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP


Re: partition swap pleine à craquer ?

2022-03-02 Thread hamster

Le 02/03/2022 à 14:17, ajh-valmer a écrit :

Juste cette observation, à quoi sert cette partition SWAP éternellement vide ?

Elle a 2 fonctions :
- Sa fonction originale c'est que quand la RAM est pleine, il la déleste 
dans cette partition. Ca fait que l'ordi se met a etre très lent mais au 
moins il plante pas.
- Il y a aussi un usage secondaire qui est que quand tu utilise la 
fonction "hiberner" il copie le contenu de la RAM dans cette partition 
puis il s'éteint. Quand tu le réveille, il commence par rapatrier les 
données dans la RAM et tu retrouve ton travail en cours.


C'est pour cette fonction secondaire que je fais toujours une partition 
swap aussi grande que la RAM.




Re: partition swap pleine à craquer ?

2022-03-02 Thread ajh-valmer
On Wednesday 02 March 2022 11:50:12 Bruno Volpi wrote:
> je pense que c'est un décalage de colonnes...

On Wednesday 02 March 2022 12:47:04 didier gaumet wrote:
> didier@hp-notebook14:~$ free
> total   utilisé  libre partagé tamp/cache  
> disponible
> Mem:20362248 338751211732644  430696 5242092  
> 16173144
> Partition d'échange:   23437308   023437308

> on peut directement regarder dans /proc/meminfo pour être sûr:
> didier@hp-notebook14:~$ grep -i swap /proc/meminfo
> SwapCached:0 kB
> SwapTotal:  23437308 kB
> SwapFree:   23437308 kB

Chez moi :
SwapCached:0 kB
SwapTotal:   8488956 kB
SwapFree:8488956 kB

C'était donc bien un décalage de colonnes,
merci beaucoup et désolé du dérangement.

Juste cette observation, à quoi sert cette partition SWAP éternellement vide ?

A. Valmer



Re: partition swap pleine à craquer ?

2022-03-02 Thread didier gaumet
Bonjour,

didier@hp-notebook14:~$ free
   total   utilisé  libre partagé tamp/cache  
disponible
Mem:20362248 338751211732644  430696 5242092  
16173144
Partition d'échange:   23437308   023437308


on peut directement regarder dans /proc/meminfo pour être sûr:

didier@hp-notebook14:~$ grep -i swap /proc/meminfo
SwapCached:0 kB
SwapTotal:  23437308 kB
SwapFree:   23437308 kB





Re: partition swap pleine à craquer ?

2022-03-02 Thread Bruno Volpi

Bonjour ,

je pense que c'est un décalage de col , peux-tu faire un Copy/Coller du 
resultat.


en attendant voici un résultat normale de la commande

  total   utilisé  libre partagé tamp/cache   
disponible

Mem:    65842020 2575988    61498492  179132 1767540    62441152
Partition d'échange: 999420   0  999420

=>  utilisé 0 et libre 999420

Slts


Le 02/03/2022 à 11:40, ajh-valmer a écrit :

Bonjour,

Voici ce que me répond la commande "free" :
Partition d'échange :taille = 8488956   libre = 0 8488956 : ?
La swap généralement est déclarée occupée = 0,
à moins que ce soit un décalage des colonnes.

Merci, bonne journée.





[SOLVED]Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-10 Thread Bernard




Le 09/04/2020 20:11, Greg Wooledge a écrit :

On Thu, Apr 09, 2020 at 08:04:31PM +0200, Bernard wrote:

[ 15541.577] (EE) AIGLX error: dlopen of
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so failed
(/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so: cannot open shared object
file: No such file or directory)


You're missing the libgl1-mesa-dri package (or it's partly installed, or
corrupted...).  In any case, try reinstalling libgl1-mesa-dri.


That did the trick !! After that package reinstalled, a return to user 
mode and


$ startx

did boot to the gnome desktop I'd lost 6 days ago, everything was there 
working all right. I logged out and booted again the usual way: 
everything was fine. I will never know how that driver got damaged.


Thanks a lot to you and to everyone who helped me solving that problem.

Bernard



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Greg Wooledge
On Thu, Apr 09, 2020 at 08:04:31PM +0200, Bernard wrote:
> [ 15541.577] (EE) AIGLX error: dlopen of
> /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so failed
> (/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so: cannot open shared object
> file: No such file or directory)

You're missing the libgl1-mesa-dri package (or it's partly installed, or
corrupted...).  In any case, try reinstalling libgl1-mesa-dri.

> [ 15541.577] (EE) AIGLX: reverting to software rendering
> [ 15541.577] (EE) AIGLX error: dlopen of
> /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed
> (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: cannot open shared object
> file: No such file or directory)

Same package.

> > startx xterm
> 
> That works !  This is the only graphic thing that I have been able to launch
> since the crash

*nod* xterm doesn't need 3d rendering.  Some desktop environments do.

> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce
> GT 710B] [10de:128b] (rev a1)

> [0.168357] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> [  293.533132] r8169 :02:00.0: firmware: direct-loading firmware
> rtl_nic/rtl8168g-2.fw

Looks like your video chipset doesn't require firmware, so that's fine.



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Bernard




Le 09/04/2020 16:44, Greg Wooledge a écrit :

On Thu, Apr 09, 2020 at 04:32:10PM +0200, Bernard wrote:




If you're trying to debug X, start simple.  Install a traditional window
manager, and just name it on the startx command to override the system
defaults.


$ startx

invariably leads to

...
connexion to X server lost


At that point, you look for errors in ~/.xsession-errors or, more usefully,
in the X log file.  Which, for stretch-and-later, on most hardware, will
be in ~/.local/share/xorg/.  Or if for some reason your X server still runs
as root, it might be in the /var/log/ directory.


Here are a few meaningful lines extracted from the Xorg.0.log


Starting line 48/515 :

[ 15541.358] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_33

[ 15541.360] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 15541.361] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 
paused 0
[ 15541.363] (--) PCI:*(0:1:0:0) 10de:128b:1458:36f8 rev 161, Mem @ 
0xee00/16777216, 0xe000/134217728, 0xe800/33554432, I/O @ 
0xe000/128, BIOS @ 0x/131072

[ 15541.363] (II) LoadModule: "glx"
[ 15541.363] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 15541.366] (II) Module glx: vendor="X.Org Foundation"
[ 15541.366]compiled for 1.19.2, module version = 1.0.0
[ 15541.366]ABI class: X.Org Server Extension, version 10.0
[ 15541.366] (==) Matched nouveau as autoconfigured driver 0
[ 15541.366] (==) Matched nv as autoconfigured driver 1
[ 15541.366] (==) Matched nouveau as autoconfigured driver 2
[ 15541.366] (==) Matched nv as autoconfigured driver 3
[ 15541.366] (==) Matched modesetting as autoconfigured driver 4
[ 15541.366] (==) Matched fbdev as autoconfigured driver 5
[ 15541.366] (==) Matched vesa as autoconfigured driver 6
[ 15541.366] (==) Assigned the driver to the xf86ConfigLayout
[ 15541.366] (II) LoadModule: "nouveau"
[ 15541.366] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[ 15541.367] (II) Module nouveau: vendor="X.Org Foundation"
[ 15541.367]compiled for 1.19.3, module version = 1.0.13
[ 15541.367]Module class: X.Org Video Driver
[ 15541.367]ABI class: X.Org Video Driver, version 23.0
[ 15541.367] (II) LoadModule: "nv"
[ 15541.367] (WW) Warning, couldn't open module nv
[ 15541.367] (II) UnloadModule: "nv"
[ 15541.367] (II) Unloading nv

from line 375

[ 15541.577] (EE) AIGLX error: dlopen of 
/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so failed 
(/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so: cannot open shared object 
file: No such file or directory)

[ 15541.577] (EE) AIGLX: reverting to software rendering
[ 15541.577] (EE) AIGLX error: dlopen of 
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed 
(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: cannot open shared object 
file: No such file or directory)

[ 15541.577] (EE) GLX: could not load software renderer
[ 15541.577] (II) GLX: no usable GL providers found for screen 0
[ 15541.580] (II) NOUVEAU(0): NVEnterVT is called.
[ 15541.610] (II) NOUVEAU(0): Setting screen physical size to 508 x 285
[ 15541.610] resize called 1920 1080
[ 15541.629] (II) config/udev: Adding input device Power Button 
(/dev/input/event4)
[ 15541.629] (**) Power Button: Applying InputClass "libinput keyboard 
catchall"

[ 15541.629] (II) LoadModule: "libinput"
[ 15541.629] (II) Loading /usr/lib/xorg/modules/input/libinput_drv.so
[ 15541.630] (II) Module libinput: vendor="X.Org Foundation"
[ 15541.630]compiled for 1.19.0, module version = 0.23.0
[ 15541.630]Module class: X.Org XInput Driver
[ 15541.630]ABI class: X.Org XInput driver, version 24.1
[ 15541.630] (II) Using input driver 'libinput' for 'Power Button'
[ 15541.630] (II) systemd-logind: got fd for /dev/input/event4 13:68 fd 
19 paused 0


The whole text file can be downloaded at

http://bdebreil.free.fr/Xorg.0.log





Start with the basics.  Can X run *at all*?

Make sure xterm is installed, and try

startx xterm



That works !  This is the only graphic thing that I have been able to 
launch since the crash


That should give you the barest possible X session.  If it works, you'll
have a mostly empty screen, but with an xterm in the upper left corner.
You'll be able to move the mouse pointer around, and if the mouse cursor
is inside the xterm window area, you'll be able to type in the terminal.
Do that, and type "exit" or Ctrl-D in the xterm to get out.

If it DOESN'T work, try to figure out why, by reading the X log file.

Also useful would be:

Which video chipset is in use?  lspci -nn


00:00.0 Host bridge [0600]: Intel Corporation Device [8086:590f] (rev 05)
00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller 
(x16) [8086:1901] (rev 05)
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 
xHCI Controller [8086:a12f] (rev 31)
00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-H CSME HECI #1 [8086:a13a] (rev 31)
00:17.0 SATA 

Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Kent West
On Thu, Apr 9, 2020 at 9:32 AM Bernard  wrote:

>
>
> Le 09/04/2020 15:45, Kent West a écrit :
> >
> >
> > On Thu, Apr 9, 2020 at 8:29 AM Bernard  > > wrote:
> >
> >
> >
> > I just realized that in that Debian Stretch system,
> >
> > I HAVE NO /home//.gconf directory !
> >
>
> >
> > It'll rebuild itself when it's needed. The lack of a .gconf directory is
> > probably not causing your problem; rather, your problem is causing the
> > lack of a .gconf directory.
> >
> > What happened when you tried running tasskel and installing a simpler
> > Windowing setup?
>
> # tasksel
>
> a graphical window opens and proposes a choice between Debian Desktop
> environment, GNOME, KDE, xfce, MATE... I alternatively chose most of
> these including Gnome Desktop env, GNOME, KDE, xfce, MATE.
>

During the install, did you get any errors?

What happens if you do:

# sudo aptitude update

and

# sudo aptitude full-upgrade

Errors?



> $ startx
>
> invariably leads to
>
> ...
> connexion to X server lost
>
>

So something is wrong with your X server setup; thus my suggestion to try a
simpler windowing system, and my suggestion to update/upgrade.


==
>
> Another time, I attempted to run
>
> # evolution
>
> unable to init server, connexion refused
> failed to initiate gtk+  could not open display
>
>
This is probably simply because X is not running; X-based apps aren't going
to be able to run if X is not first running.
I see that for startx, you're writing a "$" prompt (normal user, in most
cases - good), but or evolution, you're writing a "#" prompt (superuser
(root), in most cases - not good).

As a test, create an ~/.xinitrc file with the single line

/usr/bin/X11/xterm


If X can start, this should start only an xterm window ("exit" should shut
down X). (Don't forget to delete/modify/restore this file after this test
so your system works normally.)

-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com


Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Greg Wooledge
On Thu, Apr 09, 2020 at 04:32:10PM +0200, Bernard wrote:
> # tasksel
> 
> a graphical window opens and proposes a choice between Debian Desktop
> environment, GNOME, KDE, xfce, MATE... I alternatively chose most of these
> including Gnome Desktop env, GNOME, KDE, xfce, MATE.

So we don't even known which one you're currently trying to use.  That
makes debugging a lot harder, don't you think?

If you're trying to debug X, start simple.  Install a traditional window
manager, and just name it on the startx command to override the system
defaults.

> $ startx
> 
> invariably leads to
> 
> ...
> connexion to X server lost

At that point, you look for errors in ~/.xsession-errors or, more usefully,
in the X log file.  Which, for stretch-and-later, on most hardware, will
be in ~/.local/share/xorg/.  Or if for some reason your X server still runs
as root, it might be in the /var/log/ directory.

> Another time, I attempted to run
> 
> # evolution
> 
> unable to init server, connexion refused
> failed to initiate gtk+  could not open display
> 
> Does that mean that I should re-install the gtk library ?

No, it means you tried to run it outside of an X session.  Obviously
that's not going to work.

Start with the basics.  Can X run *at all*?

Make sure xterm is installed, and try

startx xterm

That should give you the barest possible X session.  If it works, you'll
have a mostly empty screen, but with an xterm in the upper left corner.
You'll be able to move the mouse pointer around, and if the mouse cursor
is inside the xterm window area, you'll be able to type in the terminal.
Do that, and type "exit" or Ctrl-D in the xterm to get out.

If it DOESN'T work, try to figure out why, by reading the X log file.

Also useful would be:

Which video chipset is in use?  lspci -nn

Which firmware files are loaded, and which are missing?
dmesg | grep -i firmware

And, possibly, if you can, the *important* lines from the X log file.
But figuring out which lines are important, out of that gargantuan
log file, is an art form.



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Bernard




Le 09/04/2020 15:45, Kent West a écrit :



On Thu, Apr 9, 2020 at 8:29 AM Bernard mailto:bdebr...@free.fr>> wrote:



I just realized that in that Debian Stretch system,

I HAVE NO /home//.gconf directory !





It'll rebuild itself when it's needed. The lack of a .gconf directory is
probably not causing your problem; rather, your problem is causing the
lack of a .gconf directory.

What happened when you tried running tasskel and installing a simpler
Windowing setup?


# tasksel

a graphical window opens and proposes a choice between Debian Desktop 
environment, GNOME, KDE, xfce, MATE... I alternatively chose most of 
these including Gnome Desktop env, GNOME, KDE, xfce, MATE.


$ startx

invariably leads to

...
connexion to X server lost

==

Another time, I attempted to run

# evolution

unable to init server, connexion refused
failed to initiate gtk+  could not open display

Does that mean that I should re-install the gtk library ?

Bernard



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Kent West
On Thu, Apr 9, 2020 at 8:29 AM Bernard  wrote:

>
>
> I just realized that in that Debian Stretch system,
>
> I HAVE NO /home//.gconf directory !
>
> [ While I have one my laptop using Ubuntu 14.04, also on my old desktop
> running Debian Lenny]
>
> but it didn't rebuild itself so far !
>
> What should I do to get it rebuilt ?
>
> Bernard
>
>
It'll rebuild itself when it's needed. The lack of a .gconf directory is
probably not causing your problem; rather, your problem is causing the lack
of a .gconf directory.

What happened when you tried running tasskel and installing a simpler
Windowing setup?

-- 
Kent


Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Greg Wooledge
On Thu, Apr 09, 2020 at 03:28:43PM +0200, Bernard wrote:
> I just realized that in that Debian Stretch system,
> 
> I HAVE NO /home//.gconf directory !

Uh... yay?

> but it didn't rebuild itself so far !
> 
> What should I do to get it rebuilt ?

Run something that uses it.  Or, if you don't run anything that uses it,
rejoice that you don't need it.

It's not exactly bleeding edge stuff...

unicorn:~$ ls -lart .gconf
total 64
-rw---   1 greg greg 0 Jun 28  2002 %gconf.xml
drwx--   2 greg greg  4096 Mar 12  2011 %gconf-xml-backend.lock/
drwx--   7 greg greg  4096 Apr 22  2015 apps/
drwx--   3 greg greg  4096 Apr 22  2015 desktop/
drwx--   3 greg greg  4096 Apr 22  2015 schemas/
drwx--   6 greg greg  4096 Jan 11  2017 ./
drwxr-xr-x 218 greg greg 40960 Apr  9 08:24 ../
unicorn:~$ ls -lart .gconf/apps/
total 28
-rw--- 1 greg greg0 Jun 28  2002 %gconf.xml
drwx-- 7 greg greg 4096 Apr 22  2015 evolution/
drwx-- 5 greg greg 4096 Apr 22  2015 file-roller/
drwx-- 9 greg greg 4096 Apr 22  2015 galeon/
drwx-- 3 greg greg 4096 Apr 22  2015 panel/
drwx-- 2 greg greg 4096 Apr 22  2015 totem/
drwx-- 7 greg greg 4096 Apr 22  2015 ./
drwx-- 6 greg greg 4096 Jan 11  2017 ../
unicorn:~$ 



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-09 Thread Bernard




Hi Tom, Alexei, Kent and Everyone else,

Le 05/04/2020 03:25, Tom Dial a écrit :




From the various postings it seems somewhat clear that the system, as

such, is not broken. The initial message indicates, I think Felix Miata
noted, that there is a problem with gdm starting (probably) gnome. It
also indicates that the boot completed almost normally (or almost
completed normally).

There is no obvious problem with the disks or partitions.


>

By the indications given, both disks are healthy, or considered so by
the Linux kernel.

The message string does not say directly whether you received a login
widget,

"Oh, no ..."

no login widget, the "Oh, no ..." displayed after about 1 minute.

 That would

indicate that GDM (or the display manager was in use, maybe lightdm)
worked, but gnome could not start.

I have seen a similar problem with gdm/gnome on occasion, but do not
remember the exact problem or its solution. It appeared to have
something to do with corruption in one of the files under
/home//.gconf. I think my answer might have been to throw away
that directory and let it rebuild as it liked.
Tom Dial


I just realized that in that Debian Stretch system,

I HAVE NO /home//.gconf directory !

[ While I have one my laptop using Ubuntu 14.04, also on my old desktop 
running Debian Lenny]


but it didn't rebuild itself so far !

What should I do to get it rebuilt ?

Bernard









Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-04 Thread Tom Dial



On 4/4/20 11:57, Bernard wrote:
> Le 04/04/2020 18:16, Andrei POPESCU a écrit :
>> On Sb, 04 apr 20, 11:00:06, Bernard wrote:
>>> Thanks a lot for this reply
>>>
>>> The output of the proposed tests are shown on the following screen
>>> picture :
>>>
>>> http://bdebreil.free.fr/IMG_0906.jpg
>>>
> ..
>>
>> Please post also the contents of /etc/fstab.
> 
> http://bdebreil.free.fr/IMG_0907.jpg
> 

>From the various postings it seems somewhat clear that the system, as
such, is not broken. The initial message indicates, I think Felix Miata
noted, that there is a problem with gdm starting (probably) gnome. It
also indicates that the boot completed almost normally (or almost
completed normally).

There is no obvious problem with the disks or partitions. It is unusual
to put a file system on an entire raw disk, as with /dev/sdb, but I do
not know of a reason it would not work, or that one should not do it if
the entire disk is to be used for a single file system.

As for /dev/sda: /sda1 is the partition containing everything, including
/boot and / (the root file system which, in this case contains all files
that are not on /dev/sdb, including /home). There is nothing
fundamentally wrong with this either; I find it increasingly hard to
justify to myself my old custom of putting /boot, /, /usr, /var, /tmp,
and /home on separate partitions. As Felix Miata also noted, sda2 is the
"extended" partition, and sda5 is the swap partition, created during
installation.

By the indications given, both disks are healthy, or considered so by
the Linux kernel.

The message string does not say directly whether you received a login
widget, and then the "Oh, no ..." after trying to log in. That would
indicate that GDM (or the display manager was in use, maybe lightdm)
worked, but gnome could not start.

I have seen a similar problem with gdm/gnome on occasion, but do not
remember the exact problem or its solution. It appeared to have
something to do with corruption in one of the files under
/home//.gconf. I think my answer might have been to throw away
that directory and let it rebuild as it liked. There are times when I
have little patience with files for which I have trouble finding
detailed documentation and which were created as side effects of
application or subsystem operation. I haven't burned myself yet, but
hesitated to recommend it for others where I have no skin in the game.

Others (almost everyone here) who know more than I about the innards of
the display manager and gnome may provide useful information, but
worrying about the disk looks to me like missing the mark.


>>
>> It's curious that fdisk shows sdb has no partition at all. Is this
>> expected or does sdb contain your /home?
> 
> There is no mystery about sdb ; I should have mentioned it before. This
> is an additional disk ; my desktop has two hard drives. This extra one
> had no part in the install process, I only used it later on as an
> extension to save files, I mount it manually every time I want to use
> it. I didn't see any point to partition it. I successfully mounted it in
> my recovery boot, and everything seemed to be OK at first sight.
> 
> Regards,
> 
> Bernard

Regards,

Tom Dial



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-04 Thread David Christensen

On 2020-04-04 10:57, Bernard wrote:



Le 04/04/2020 18:16, Andrei POPESCU a écrit :

On Sb, 04 apr 20, 11:00:06, Bernard wrote:

Thanks a lot for this reply

The output of the proposed tests are shown on the following screen 
picture :


http://bdebreil.free.fr/IMG_0906.jpg


..


Please post also the contents of /etc/fstab.


http://bdebreil.free.fr/IMG_0907.jpg



It's curious that fdisk shows sdb has no partition at all. Is this
expected or does sdb contain your /home?


There is no mystery about sdb ; I should have mentioned it before. This 
is an additional disk ; my desktop has two hard drives. This extra one 
had no part in the install process, I only used it later on as an 
extension to save files, I mount it manually every time I want to use 
it. I didn't see any point to partition it. I successfully mounted it in 
my recovery boot, and everything seemed to be OK at first sight.


Regards,

Bernard


To be blunt, if you just want to use video conferencing and not learn 
how video conferencing works (or does not work) on Linux, I would use 
Windows or macOS.



As for the broken Debian computer, I would back up the data, install a 
small SSD, install Debian, wipe the 1 TB drives, create an md mirror, 
create an ext4 file system, restore the data, install Samba, and share 
the data.



It is useful to have a USB flash drive with Debian installed on it, to 
use as tool for working on other computers.



It is useful to maintain a folder in a version control system for each 
host, with an administrator journal (plain text file), system 
configuration files, and anything else useful for setup, configuration, 
and maintenance.  I use Vim and CVS over SSH.



David



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-04 Thread Bernard




Le 04/04/2020 18:16, Andrei POPESCU a écrit :

On Sb, 04 apr 20, 11:00:06, Bernard wrote:

Thanks a lot for this reply

The output of the proposed tests are shown on the following screen picture :

http://bdebreil.free.fr/IMG_0906.jpg


..


Please post also the contents of /etc/fstab.


http://bdebreil.free.fr/IMG_0907.jpg



It's curious that fdisk shows sdb has no partition at all. Is this
expected or does sdb contain your /home?


There is no mystery about sdb ; I should have mentioned it before. This 
is an additional disk ; my desktop has two hard drives. This extra one 
had no part in the install process, I only used it later on as an 
extension to save files, I mount it manually every time I want to use 
it. I didn't see any point to partition it. I successfully mounted it in 
my recovery boot, and everything seemed to be OK at first sight.


Regards,

Bernard



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-04 Thread Andrei POPESCU
On Sb, 04 apr 20, 11:00:06, Bernard wrote:
> Thanks a lot for this reply
> 
> The output of the proposed tests are shown on the following screen picture :
> 
> http://bdebreil.free.fr/IMG_0906.jpg
> 
> As for partition sda2 : I don't remember having created this partition when
> installing Stretch on this then newly bought desktop (2 years ago). Isn'it
> funny that it shows the exact same size as that of the swap partition sda5 ?
> 
> I doubt that I would have willingly created such a small partition... maybe
> the install program created it...

Felix Miata already answered to this much better than I could have done.
 
> Whether it did exist or not in my working system, one thing remains :
> 
> on the rescue mode, I cannot find my /home directory
> 
> Waiting for your advice and recommendations,

Please post also the contents of /etc/fstab.

It's curious that fdisk shows sdb has no partition at all. Is this 
expected or does sdb contain your /home?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: Partition unreadable

2020-04-04 Thread Felix Miata
Bernard composed on 2020-04-04 11:00 (UTC+0200):

> http://bdebreil.free.fr/IMG_0906.jpg

> As for partition sda2 : I don't remember having created this partition 
> when installing Stretch on this then newly bought desktop (2 years ago). 
> Isn'it funny that it shows the exact same size as that of the swap 
> partition sda5 ?

Rather than a filesystem (or LVM) container, which is what your sda1 and sda5 
are,
sda2 is a logical partition container, labeled extended. Creating it as a 
separate
partitioning step is an anachronism which in practical terms serves no purpose 
but
to confuse those uninitiated with legacy/MBR partitioning.

> I doubt that I would have willingly created such a small partition... 
> maybe the install program created it...
The smarter partitioning programs don't "create it", because it is nothing but 
an
envelope within which partitions that can contain filesystems may be created.
These smarter ones do create it, but they do so automatically without making any
mention of it, automatically making them the size required to contain the
partitions within that they contain. It occupies a partition table entry that is
nothing but a definition of the size of the container, plus a pointer to the 
first
partition that it contains. Thus if only one partition is contained, it may
virtually match the size of that which it contains, the difference being the 
size
allocated to the definition itself.

The gap in numbers is because the MBR partition table only has space for 4
entries. That makes 5 the first available number for a logical partition 
contained
by the extended "partition" definition. Logical is the name given defined by the
extended's table entry, plus each in the chain of additional entries at the 
start
of each that is defined beyond that which is labeled #5.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



Re: Partition unreadable [was: Re: Debian Stretch broken !]

2020-04-04 Thread Bernard

Thanks a lot for this reply

The output of the proposed tests are shown on the following screen picture :

http://bdebreil.free.fr/IMG_0906.jpg

As for partition sda2 : I don't remember having created this partition 
when installing Stretch on this then newly bought desktop (2 years ago). 
Isn'it funny that it shows the exact same size as that of the swap 
partition sda5 ?


I doubt that I would have willingly created such a small partition... 
maybe the install program created it...


Whether it did exist or not in my working system, one thing remains :

on the rescue mode, I cannot find my /home directory

Waiting for your advice and recommendations,

Bernard

Please post the output of following commands from the rescue console.
>
> LANG=C lsblk -f
> LANG=C fdisk -l
>

Le 04/04/2020 08:28, Andrei POPESCU a écrit :

On Sb, 04 apr 20, 01:13:35, Bernard wrote:


Next I typed 'journalctl -xb' to view system logs : a dozen of pages which I
will shoot later, one thing I have noticed in it all, printed in red
characters :

EXT4-fs (sda2): unable to read superblock

this repeated three times !


This *could* indicate a serious problem and attempts to fix it *could*
make it worse. It could also be a minor issue that is easily fixed.

Do you have an *empty* spare drive to copy your data to? Ideally you
should use 'dd' to take a complete image of sda and work on that
instead.

 dd if=/dev/sda of=/dev/ bs=1M status=progress

Warning: this will overwrite your data on the spare drive!

For this to work properly the spare drive should be same size (to the
byte!) or bigger than sda.

Before any recovery attempts let's try to find out how your drives are
partitioned.

Please post the output of following commands from the rescue console.

LANG=C lsblk -f
LANG=C fdisk -l

These are read-only commands so should be safe.

Kind regards,
Andrei





Re: "partition name" versus "filesystem label" -- authoritative references?

2019-08-30 Thread Gene Heskett
On Friday 30 August 2019 07:52:45 Jonas Smedegaard wrote:

> Quoting Richard Owlett (2019-08-30 13:42:27)
>
> > I've just encountered GPT, and thus "partition name", for the first
> > time. My web search turned primarily threads titled of form "just
> > encountered GPT ..." ;{ Similarly the articles I found were too
> > focused on "What is a partition?"
> >
> > I'm looking for authoritative articles whose purpose is to examine
> > their purposes, similarities/differences, when each should/shouldn't
> > be used.
>
> As far as I am aware, the best knowledge on GPT is found here:
> https://www.rodsbooks.com/gdisk/
>
>  - Jonas

I've been looking for something like that tut for quite a while, 
bookmarked for future study.

Thank you Jonas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 



Re: "partition name" versus "filesystem label" -- authoritative references?

2019-08-30 Thread Richard Owlett

On 08/30/2019 06:52 AM, Jonas Smedegaard wrote:

Quoting Richard Owlett (2019-08-30 13:42:27)

I've just encountered GPT, and thus "partition name", for the first
time. My web search turned primarily threads titled of form "just
encountered GPT ..." ;{ Similarly the articles I found were too
focused on "What is a partition?"

I'm looking for authoritative articles whose purpose is to examine
their purposes, similarities/differences, when each should/shouldn't
be used.


As far as I am aware, the best knowledge on GPT is found here:
https://www.rodsbooks.com/gdisk/

  - Jonas



*ROFL* I was expecting a link to a 400-500 word essay.
That likely points to a few dozen other answers I'll need.
If not, I'll start on his links from http://www.rodsbooks.com/ 

*THANK YOU*





Re: "partition name" versus "filesystem label" -- authoritative references?

2019-08-30 Thread Jonas Smedegaard
Quoting Richard Owlett (2019-08-30 13:42:27)
> I've just encountered GPT, and thus "partition name", for the first 
> time. My web search turned primarily threads titled of form "just 
> encountered GPT ..." ;{ Similarly the articles I found were too 
> focused on "What is a partition?"
> 
> I'm looking for authoritative articles whose purpose is to examine 
> their purposes, similarities/differences, when each should/shouldn't 
> be used.

As far as I am aware, the best knowledge on GPT is found here: 
https://www.rodsbooks.com/gdisk/

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Re: Partition information as text file?

2019-02-02 Thread tomas
On Sat, Feb 02, 2019 at 09:26:31AM -0600, David Wright wrote:
> On Sat 02 Feb 2019 at 10:58:09 (+0100), to...@tuxteam.de wrote:
> > On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> > > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > > > On 02/01/2019 10:15 AM, David Wright wrote:
> > > > > [snip]
> > > > > 
> > > > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > > > 
> > > > *CAVEAT* LECTOR
> > > > It is more like Tk being a GUI interface for Tcl.
> > > 
> > > Sure, and for several other languages, but I assume you wouldn't want
> > > a GUI interface for your text-producing script even if you write it
> > > in Tcl.
> > 
> > Tcl still makes for a reasonable scripting language. It's just a bit
> > different of most "modern" languages (except perhaps shell), so for
> > Perlies and Pythoners and PHPers it takes some "getting used" to.
> > 
> > But it is pretty powerful.
> 
> Yes, I remember Tkinter's thinness overlying it: it would occasionally
> be necessary to tickle the Tcl to get precisely what you wanted.
> 
> But as for being different, I've found nothing to approach Spitbol
> (a superior implementation of Snobol, which I ran on IBM 370s in the
> '70s and '80s and then on Vaxen into the mid-'90s). Fortunately
> when it fell by the wayside, I found Perl, with its associative
> arrays, and even an implementation of Perl on DOS, which kept me
> going until I started using Python on linux in late '95.

Yes, Snobol and its family was pretty interesting. FWIW, Tcl has
gained associative arrays.

Cheers
-- tomás


signature.asc
Description: Digital signature


Re: Partition information as text file?

2019-02-02 Thread David Wright
On Sat 02 Feb 2019 at 10:58:09 (+0100), to...@tuxteam.de wrote:
> On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> > On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > > On 02/01/2019 10:15 AM, David Wright wrote:
> > > > [snip]
> > > > 
> > > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > > 
> > > *CAVEAT* LECTOR
> > > It is more like Tk being a GUI interface for Tcl.
> > 
> > Sure, and for several other languages, but I assume you wouldn't want
> > a GUI interface for your text-producing script even if you write it
> > in Tcl.
> 
> Tcl still makes for a reasonable scripting language. It's just a bit
> different of most "modern" languages (except perhaps shell), so for
> Perlies and Pythoners and PHPers it takes some "getting used" to.
> 
> But it is pretty powerful.

Yes, I remember Tkinter's thinness overlying it: it would occasionally
be necessary to tickle the Tcl to get precisely what you wanted.

But as for being different, I've found nothing to approach Spitbol
(a superior implementation of Snobol, which I ran on IBM 370s in the
'70s and '80s and then on Vaxen into the mid-'90s). Fortunately
when it fell by the wayside, I found Perl, with its associative
arrays, and even an implementation of Perl on DOS, which kept me
going until I started using Python on linux in late '95.

Cheers,
David.



Re: Partition information as text file?

2019-02-02 Thread tomas
On Fri, Feb 01, 2019 at 07:05:53PM -0600, David Wright wrote:
> On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> > On 02/01/2019 10:15 AM, David Wright wrote:
> > > [snip]
> > > 
> > > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> > 
> > *CAVEAT* LECTOR
> > It is more like Tk being a GUI interface for Tcl.
> 
> Sure, and for several other languages, but I assume you wouldn't want
> a GUI interface for your text-producing script even if you write it
> in Tcl.

Tcl still makes for a reasonable scripting language. It's just a bit
different of most "modern" languages (except perhaps shell), so for
Perlies and Pythoners and PHPers it takes some "getting used" to.

But it is pretty powerful.

Cheers
-- t


signature.asc
Description: Digital signature


Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 11:07:28 (-0600), Richard Owlett wrote:
> On 02/01/2019 10:15 AM, David Wright wrote:
> > [snip]
> > 
> > Interesting. I thought Tcl/Tk was for writing GUIs. ...
> 
> *CAVEAT* LECTOR
> It is more like Tk being a GUI interface for Tcl.

Sure, and for several other languages, but I assume you wouldn't want
a GUI interface for your text-producing script even if you write it
in Tcl.

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 13:10:19 (-0500), Greg Wooledge wrote:
> On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote:
> > On Fri, 1 Feb 2019 07:59:42 -0600 Richard Owlett  
> > wrote:
> > 
> > > ... a major deficiency of the man page format --
> > >   [/begin_rant   almost total lack of examples /end_rant ;]
> > 
> > That's what's expected of man pages. If you want examples, poke around
> > the Net for tutorials, and be prepared to find a wide range of quality.
> 
> I disagree.  Perhaps you've come to expect a lack of examples from the
> man pages published by various GNU projects.  GNU developers prefer their
> own texinfo format instead, so they often write only stub man pages.
> 
> A well-written man page includes an EXAMPLES section, unless the command
> being documented is so trivial that none is required (e.g. true(1)).
> 
> The lack of examples is not a "deficiency of the format".  It is a
> deficiency of that particular page, written by that particular author.

Well, I've just given my opinion elsewhere. But it would be an
interesting challenge to write an example of a man page EXAMPLE
for that particular page, beyond the example that is given there.

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread tomas
On Fri, Feb 01, 2019 at 07:30:31PM +0100, Pascal Hambourg wrote:
> Le 01/02/2019 à 16:23, to...@tuxteam.de a écrit :
> >
> >   tomas@trotzki:~$ file /dev/mapper/trotzki-home
> >   /dev/mapper/trotzki-home: symbolic link to ../dm-4
> >
> >Ah.
> >
> >   tomas@trotzki:~$ file /dev/dm-4
> >   /dev/dm-4: block special (254/4)
> >
> >Not yet what we wanted. But:
> >
> >   tomas@trotzki:~$ sudo file -s /dev/dm-4
> 
> In one single command :
> 
> # file -Lsk /dev/mapper/whatever

Yep, thanks. I just wanted to sketch a path to the idea.

> >Sudo is needed
> 
> No it's not. Read permission on the raw device is needed, by
> whatever way including sudo but not only (su, root session...).

This is of course more correct than my handwaving description :-)
> 


signature.asc
Description: Digital signature


Re: Partition information as text file?

2019-02-01 Thread Pascal Hambourg

Le 01/02/2019 à 16:23, to...@tuxteam.de a écrit :


   tomas@trotzki:~$ file /dev/mapper/trotzki-home
   /dev/mapper/trotzki-home: symbolic link to ../dm-4

Ah.

   tomas@trotzki:~$ file /dev/dm-4
   /dev/dm-4: block special (254/4)

Not yet what we wanted. But:

   tomas@trotzki:~$ sudo file -s /dev/dm-4


In one single command :

# file -Lsk /dev/mapper/whatever


Sudo is needed


No it's not. Read permission on the raw device is needed, by whatever 
way including sudo but not only (su, root session...).




Re: Partition information as text file?

2019-02-01 Thread Dan Ritter
Greg Wooledge wrote: 
> On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote:
> > On Fri, 1 Feb 2019 07:59:42 -0600
> > Richard Owlett  wrote:
> > 
> > > ... a major deficiency of the man page format --
> > >   [/begin_rant   almost total lack of examples /end_rant ;]
> > 
> > That's what's expected of man pages. If you want examples, poke around
> > the Net for tutorials, and be prepared to find a wide range of quality.
> 
> I disagree.  Perhaps you've come to expect a lack of examples from the
> man pages published by various GNU projects.  GNU developers prefer their
> own texinfo format instead, so they often write only stub man pages.
> 
> A well-written man page includes an EXAMPLES section, unless the command
> being documented is so trivial that none is required (e.g. true(1)).

... or the command is so complex that it refers you to other man
pages:

procmailex

perlfaq and perlfaq1-9

-dsr-



Re: Partition information as text file?

2019-02-01 Thread Joe
On Fri, 1 Feb 2019 07:59:42 -0600
Richard Owlett  wrote:


> ... a major deficiency of the man page format --
>   [/begin_rant   almost total lack of examples /end_rant ;]
> 

That's what's expected of man pages. If you want examples, poke around
the Net for tutorials, and be prepared to find a wide range of quality.
A good place is often (though certainly not always) the documents on the
website associated with the application.

-- 
Joe



Re: Partition information as text file?

2019-02-01 Thread Greg Wooledge
On Fri, Feb 01, 2019 at 06:06:18PM +, Joe wrote:
> On Fri, 1 Feb 2019 07:59:42 -0600
> Richard Owlett  wrote:
> 
> > ... a major deficiency of the man page format --
> >   [/begin_rant   almost total lack of examples /end_rant ;]
> 
> That's what's expected of man pages. If you want examples, poke around
> the Net for tutorials, and be prepared to find a wide range of quality.

I disagree.  Perhaps you've come to expect a lack of examples from the
man pages published by various GNU projects.  GNU developers prefer their
own texinfo format instead, so they often write only stub man pages.

A well-written man page includes an EXAMPLES section, unless the command
being documented is so trivial that none is required (e.g. true(1)).

The lack of examples is not a "deficiency of the format".  It is a
deficiency of that particular page, written by that particular author.



Re: Partition information as text file?

2019-02-01 Thread Richard Owlett

On 02/01/2019 10:15 AM, David Wright wrote:

[snip]

Interesting. I thought Tcl/Tk was for writing GUIs. ...


*CAVEAT* LECTOR
It is more like Tk being a GUI interface for Tcl.



Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 11:14:11 (-0500), Felix Miata wrote:
> Richard Owlett composed on 2019-02-01 07:59 (UTC-0600):
> > Thomas Schmitt wrote:
> 
> >> It's what Gparted does and what Richard mentioned as example of the desired
> >> information.
> 
> > I'd make that statement stronger.
> > My starting point was Gparted displays *ALL* the desired information for 
> > *ALL* members of the set [ /dev/sd* ] whether mounted or not.
> 
> > That PROVED that what I wanted was possible.
> 
> > It's "suitability to purpose" was degraded on *2* counts:
> > 1. it does not output the data as a text file.
> > 2. it displays information for only 1 device at a time.
> 
> >> Given that the source code of Gparted is published, we do not
> >> have to speculate how it does this, but rather can riddle over its C++ 
> >> code.
> 
> > Having known working source code for a program that almost meets my 
> > needs/desires remedies a major deficiency of the man page format --
> >   [/begin_rant   almost total lack of examples /end_rant ;]
> 
> Maybe the following would do better
> 
> script
> parted # instead of gparted
> some parted commands
> parted exit
> script exit
> nano typescript
> 
> All assuming you tried dfsee and didn't manage to find options to produce 
> exactly your
> desires in its logs even with some editing.

Um, I think that was last Saturday's solution, complete with EXAMPLE
(all caps in homage to OP), minutes before your DFSee.

Strange, there were no follow-ups then. Let's see if that changes.
There's this mighty tree hanging off your DFSee comment.

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 09:00:06 (-0600), Richard Owlett wrote:
> On 02/01/2019 08:22 AM, Thomas Schmitt wrote:
> > Richard Owlett wrote:
> > > [Gparted] PROVED that what I wanted was possible.
> > 
> > Regrettably it does not retrieve the information by some universal info
> > program or library, but rather has particular info sources for each of
> > the supported filesystems. (There are more filesystems around than i can
> > see in the Gparted source.)
> > 
> > > It's "suitability to purpose" was degraded on *2* counts:
> > > 1. it does not output the data as a text file.
> > 
> > So you need one or more scripts ... Then the script[s] would put out
> > the retrieved numbers in the text format which you desire.
> 
> The need for *ME* to write a script was a BASIC assumption to my
> asking about commands relevant to my task.
> > 
> > > man page format [...] almost total lack of examples [...]
> > 
> > If you refer to Gparted's man page, ...
> 
> I was referring to Linux man pages in general. I've ~10 man pages of
> commands mentioned in this thread -- none with useful examples. For a
> specific command I routinely do a web search with the keywords
> "examples" &/or "tutorial".
> 
> Though I don't refer to myself as a programmer I've written "scripts"
> [using term loosely]:
>   in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
>   in the mid 70's using DEC's TECO {not just an editor ;}
>   later dBASEII and Paradox
>   am now exploring Tcl/Tk

Interesting. I thought Tcl/Tk was for writing GUIs. I toyed with it
briefly in the late 90s before I started using Tkinter (ie Python).

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread Felix Miata
Richard Owlett composed on 2019-02-01 07:59 (UTC-0600):

> Thomas Schmitt wrote:

>> It's what Gparted does and what Richard mentioned as example of the desired
>> information.

> I'd make that statement stronger.
> My starting point was Gparted displays *ALL* the desired information for 
> *ALL* members of the set [ /dev/sd* ] whether mounted or not.

> That PROVED that what I wanted was possible.

> It's "suitability to purpose" was degraded on *2* counts:
> 1. it does not output the data as a text file.
> 2. it displays information for only 1 device at a time.

>> Given that the source code of Gparted is published, we do not
>> have to speculate how it does this, but rather can riddle over its C++ code.

> Having known working source code for a program that almost meets my 
> needs/desires remedies a major deficiency of the man page format --
>   [/begin_rant   almost total lack of examples /end_rant ;]

Maybe the following would do better

script
parted # instead of gparted
some parted commands
parted exit
script exit
nano typescript

All assuming you tried dfsee and didn't manage to find options to produce 
exactly your
desires in its logs even with some editing.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 16:23:04 (+0100), to...@tuxteam.de wrote:

> Not yet what we wanted. But:
> 
>   tomas@trotzki:~$ sudo file -s /dev/dm-4
>   /dev/dm-4: Linux rev 1.0 ext4 filesystem data, 
> UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) 
> (64bit) (large files) (huge files)
> 
> I guess that's not all info you want, but hey. Sudo is needed, because mere
> mortals have no business in reading raw disks, usually; The "needs journal
> recovery" sounds alarming, but remember that the thing is mounted, i.e.
> active, so that's OK too.

I hadn't bothered to say this already, but not replaying the journal
could be one reason that wrong information is returned from unmounted
filesystems, as Pascal mentioned earlier.

That could be another reason to mount them (readonly) and let df
complete the dirty work of finding the information you want (as
I outlined much earlier in this thread).

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread David Wright
On Fri 01 Feb 2019 at 07:59:42 (-0600), Richard Owlett wrote:
> On 01/31/2019 02:03 PM, Thomas Schmitt wrote:
> > Hi,
> > 
> > Richard Owlett wrote:
> > > > > What bugs me is Gparted [though it does not output text]  reports
> > > > > used/unused space on each partition/file system.
> > 
> > i wrote:
> > > > [...] Gparted runs external programs, which a simple
> > > > shell script could do too.
> > 
> > David Wright wrote:
> > > So going back to the OP, is this a sensible approach to choose instead
> > > of letting mount and df figure things out for themselves?
> > 
> > It's what Gparted does and what Richard mentioned as example of the desired
> > information.
> 
> I'd make that statement stronger.
> My starting point was Gparted displays *ALL* the desired information
> for *ALL* members of the set [ /dev/sd* ] whether mounted or not.

I think you mean /dev/sdX*.

> That PROVED that what I wanted was possible.

We don't doubt that the information is obtainable. My concern was
whether you wanted a script to place the required information in
a file by COP,¹ or after the indeterminate amount of time it takes
to digest and regurgitate all that code. Fortunately the amount of
code you need to examine will be reduced by the fact that you
personally have a very limited group of partition types in your
inventory.

> It's "suitability to purpose" was degraded on *2* counts:
> 1. it does not output the data as a text file.
> 2. it displays information for only 1 device at a time.

Yes, the thought of juggling several partition tables simultaneously
had probably not occurred to any sane person.

> > Given that the source code of Gparted is published, we do not
> > have to speculate how it does this, but rather can riddle over its C++ code.
> 
> Having known working source code for a program that almost meets my
> needs/desires remedies a major deficiency of the man page format --
>  [/begin_rant   almost total lack of examples /end_rant ;]

Have you tried pressing F1 in the gparted window itself?

I was under the impression that man pages were an aide-mémoire for CLI
users so that they don't have to commit all the options and arguments
to memory. Its flat-file format doesn't really lend itself to copious
examples, particularly where they would be trying to describe how to
navigate round a widget-filled picture.

But this dead horse has been flogged enough times on this list already.

Perhaps when your script is finished you could share it here. Many of
us are probably running systems with no more than ext & fat filesystems,
and could usefully employ it.

¹ Close of Play seems to be missing from wiki's Cop page, even though
it appears under End_of_day.

Cheers,
David.



Re: Partition information as text file?

2019-02-01 Thread rhkramer
On Friday, February 01, 2019 09:22:10 AM Thomas Schmitt wrote:
> If you refer to Gparted's man page, then the answer is obviously that
> nobody expects hard info from the manual of a clicky-colorful GUI program.
> (I.e. not "RTFM" but "RTSL" = "Read The Source, Luke.")

I hope that's not the case (because I'm an advocate of Linux displacing 
Windows on the desktop -- I don't expect that target audience to have much 
success reading the source).

Also, on the gparted man page (on Wheezy), I see:


More documentation can be found in the application help manual, and online at:
   http://gparted.org


I didn't look at that, but I hope it is a useful resource.



Re: Partition information as text file?

2019-02-01 Thread tomas
On Fri, Feb 01, 2019 at 09:00:06AM -0600, Richard Owlett wrote:
> On 02/01/2019 08:22 AM, Thomas Schmitt wrote:

[...]

> >So you need one or more scripts ... Then the script[s] would put out
> >the retrieved numbers in the text format which you desire.
> 
> The need for *ME* to write a script was a BASIC assumption to my
> asking about commands relevant to my task.

Perhaps the humble command "file" could be an ally in that. It's
not a complete solution, though...

Remember: "file" looks (with some exceptions, see below) into the
contents of a file and tries to find out what it is, by looking
for "magic numbers" (more precisely patterns) stored in a file
(/usr/share/misc/magic).

Here's a small session from my box (with some elisions marked as [...]

  tomas@trotzki:~$ mount
  /dev/sda1 on /boot type ext2 
(rw,relatime,block_validity,barrier,user_xattr,acl)
  /dev/mapper/trotzki-root on / type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
  /dev/mapper/trotzki-usr on /usr type ext4 (rw,relatime,data=ordered)
  /dev/mapper/trotzki-home on /home type ext4 (rw,relatime,data=ordered)
  /dev/mapper/trotzki-var on /var type ext4 (rw,relatime,data=ordered)
  [...]

(Note: my "partitions" are, with exception of /dev/sda1, which is the boot
partition, LVM volumes which are cut out from a physical volume which is
LUKS encrypted: I don't want someone to get at my (and my customer's)
data just because I leave the laptop in the metro).

Now:

  tomas@trotzki:~$ file /dev/mapper/trotzki-home 
  /dev/mapper/trotzki-home: symbolic link to ../dm-4

Ah.

  tomas@trotzki:~$ file /dev/dm-4
  /dev/dm-4: block special (254/4)

Not yet what we wanted. But:

  tomas@trotzki:~$ sudo file -s /dev/dm-4
  /dev/dm-4: Linux rev 1.0 ext4 filesystem data, 
UUID=c5d1ae98-df63-4c04-913d-661b82d38075 (needs journal recovery) (extents) 
(64bit) (large files) (huge files)

I guess that's not all info you want, but hey. Sudo is needed, because mere
mortals have no business in reading raw disks, usually; The "needs journal
recovery" sounds alarming, but remember that the thing is mounted, i.e.
active, so that's OK too.

Perhaps this can be a small building block for you.

I guess you'd like more info about the file system (size, what not).
Those commands (and their outputs!) are most probably file system
specific, as Thomas points out.

Cheers
-- t


signature.asc
Description: Digital signature


Re: Partition information as text file?

2019-02-01 Thread Richard Owlett

On 02/01/2019 08:22 AM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

[Gparted] PROVED that what I wanted was possible.


Regrettably it does not retrieve the information by some universal info
program or library, but rather has particular info sources for each of
the supported filesystems. (There are more filesystems around than i can
see in the Gparted source.)



It's "suitability to purpose" was degraded on *2* counts:
1. it does not output the data as a text file.


So you need one or more scripts ... Then the script[s] would put out
the retrieved numbers in the text format which you desire.


The need for *ME* to write a script was a BASIC assumption to my asking 
about commands relevant to my task.






man page format [...] almost total lack of examples [...]


If you refer to Gparted's man page, ...


I was referring to Linux man pages in general. I've ~10 man pages of 
commands mentioned in this thread -- none with useful examples. For a 
specific command I routinely do a web search with the keywords 
"examples" &/or "tutorial".


Though I don't refer to myself as a programmer I've written "scripts" 
[using term loosely]:

  in the early 60's using CORC/CUPL {Cornell's predecessor to BASIC}
  in the mid 70's using DEC's TECO {not just an editor ;}
  later dBASEII and Paradox
  am now exploring Tcl/Tk






Re: Partition information as text file?

2019-02-01 Thread Thomas Schmitt
Hi,

Richard Owlett wrote:
> [Gparted] PROVED that what I wanted was possible.

Regrettably it does not retrieve the information by some universal info
program or library, but rather has particular info sources for each of
the supported filesystems. (There are more filesystems around than i can
see in the Gparted source.)


> It's "suitability to purpose" was degraded on *2* counts:
> 1. it does not output the data as a text file.

So you need one or more scripts which apply the program runs learned from
Gparted to your partition device files and which then pick the desired
numbers out of the text output from those programs.
Then the script[s] would put out the retrieved numbers in the text format
which you desire.


> man page format [...] almost total lack of examples [...]

If you refer to Gparted's man page, then the answer is obviously that
nobody expects hard info from the manual of a clicky-colorful GUI program.
(I.e. not "RTFM" but "RTSL" = "Read The Source, Luke.")


Have a nice day :)

Thomas



Re: Partition information as text file?

2019-02-01 Thread Richard Owlett

On 01/31/2019 02:03 PM, Thomas Schmitt wrote:

Hi,

Richard Owlett wrote:

What bugs me is Gparted [though it does not output text]  reports
used/unused space on each partition/file system.


i wrote:

[...] Gparted runs external programs, which a simple
shell script could do too.


David Wright wrote:

So going back to the OP, is this a sensible approach to choose instead
of letting mount and df figure things out for themselves?


It's what Gparted does and what Richard mentioned as example of the desired
information.


I'd make that statement stronger.
My starting point was Gparted displays *ALL* the desired information for 
*ALL* members of the set [ /dev/sd* ] whether mounted or not.


That PROVED that what I wanted was possible.

It's "suitability to purpose" was degraded on *2* counts:
1. it does not output the data as a text file.
2. it displays information for only 1 device at a time.


Given that the source code of Gparted is published, we do not
have to speculate how it does this, but rather can riddle over its C++ code.


Having known working source code for a program that almost meets my 
needs/desires remedies a major deficiency of the man page format --

 [/begin_rant   almost total lack of examples /end_rant ;]



(The ext2 specific code distinguishes between mounted and not mounted
  partitions. The FAT related code seems not to do.)


Have a nice day :)

Thomas








  1   2   3   4   5   6   7   8   9   10   >