Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #204667 > unrolled thread

Partition information as text file?

Back to article view | Back to linux.debian.user

Contents

  Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-26 15:40 +0100
    Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-26 18:10 +0100
    Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-01-26 20:40 +0100
      Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-26 22:20 +0100
        Re: Partition information as text file? "Alexander V. Makartsev" <avbetev@gmail.com> - 2019-01-26 23:00 +0100
        Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-01-27 03:10 +0100
        Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-27 22:30 +0100
          Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-28 13:50 +0100
            Re: Partition information as text file? Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2019-01-28 16:50 +0100
            Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-28 20:50 +0100
              Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-29 15:40 +0100
                Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-29 16:30 +0100
                  Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-29 16:40 +0100
                  Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-29 17:20 +0100
                    Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-31 15:20 +0100
                      Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-31 16:00 +0100
                        Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-31 20:30 +0100
                          Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-01-31 21:10 +0100
                            Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 15:10 +0100
                              Re: Partition information as text file? "Thomas Schmitt" <scdbackup@gmx.net> - 2019-02-01 15:30 +0100
                                Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 16:10 +0100
                                  Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-01 16:30 +0100
                                    Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:10 +0100
                                    Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-02-01 19:40 +0100
                                      Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-01 22:30 +0100
                                  Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:20 +0100
                                    Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-02-01 18:10 +0100
                                      Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-02 02:10 +0100
                                        Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-02 11:00 +0100
                                          Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-02 16:30 +0100
                                            Re: Partition information as text file? <tomas@tuxteam.de> - 2019-02-02 17:20 +0100
                                Re: Partition information as text file? rhkramer@gmail.com - 2019-02-01 17:00 +0100
                              Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:10 +0100
                              Re: Partition information as text file? Felix Miata <mrmazda@earthlink.net> - 2019-02-01 17:20 +0100
                                Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 17:30 +0100
                              Re: Partition information as text file? Joe <joe@jretrading.com> - 2019-02-01 19:10 +0100
                                Re: Partition information as text file? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-02-01 19:20 +0100
                                  Re: Partition information as text file? Dan Ritter <dsr@randomstring.org> - 2019-02-01 19:30 +0100
                                  Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-02-01 23:10 +0100
                  Re: Partition information as text file? Peter Ehlert <peter@sdi-baja.com> - 2019-01-29 17:40 +0100
                  Re: Partition information as text file? Jude DaShiell <jdashiel@panix.com> - 2019-01-29 19:00 +0100
              Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-29 15:40 +0100
                Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-29 21:10 +0100
                  Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-30 16:10 +0100
                    Re: Partition information as text file? <tomas@tuxteam.de> - 2019-01-30 17:00 +0100
                      Talking about loop devices (was: Re: Partition information as text file?) David <bouncingcats@gmail.com> - 2019-01-31 02:20 +0100
                        Re: Talking about loop devices (was: Re: Partition information as  text file?) David <bouncingcats@gmail.com> - 2019-01-31 04:50 +0100
                        Re: Talking about loop devices (was: Re: Partition information as  text file?) <tomas@tuxteam.de> - 2019-01-31 10:10 +0100
                        Re: Talking about loop devices Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-31 20:00 +0100
                          Re: Talking about loop devices David <bouncingcats@gmail.com> - 2019-02-01 06:30 +0100
                    Re: Partition information as text file? Joe <joe@jretrading.com> - 2019-01-30 17:10 +0100
                      Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-31 15:30 +0100
                    Re: Partition information as text file? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-30 19:50 +0100
                Re: Partition information as text file? David <bouncingcats@gmail.com> - 2019-01-30 03:10 +0100
                  Re: Partition information as text file? Richard Owlett <rowlett@cloud85.net> - 2019-01-30 16:20 +0100
            Re: Partition information as text file? David Wright <deblis@lionunicorn.co.uk> - 2019-01-29 19:30 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#204806

On Tue, 29 Jan 2019, Richard Owlett wrote:

> Date: Tue, 29 Jan 2019 10:22:42
> From: Richard Owlett <rowlett@cloud85.net>
> To: debian-user@lists.debian.org
> Subject: Re: Partition information as text file?
> Resent-Date: Tue, 29 Jan 2019 15:23:04 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
>
> On 01/29/2019 08:37 AM, tomas@tuxteam.de wrote:
> > On Tue, Jan 29, 2019 at 08:30:13AM -0600, Richard Owlett wrote:
> >
> >> I assume "fsck.dos" is a typo as
> >> [https://dyn.manpages.debian.org/jump?suite=stretch&binarypkg=dosfstools&section=8&language=en&q=fsck.dos]
> >>      yields
> >> "Sorry, the manpage ?fsck.dos? was not found!"
> >
> > You have the manpages on your box, hopefully. Try "man -k fsck", and you'll
> > get:
> > [snip sample output]
>
> I avoid using "man" as I find the HTML of online pages friendlier. Also in the
> past I was reading man pages more frequently to chose whether or not to
> install a particular package than to explore what an installed package could
> do for me.
>
> I didn't know of the "-k" option. I haven't come across an equivalent function
> online. I may not use "man" to read, but "man -k" should be very useful for
> deciding which online pages I wish to read.
>
> >
> > So I'd try fsck.fat or similar (/if/ it has to be fat, that is)
> >
> >> Thanks for trying.
> >
> > That's how we advance, after all :)
> >
> >> What bugs me is Gparted [though it does not output text]  reports
> >> used/unused space on each partition/file system.
> >
> > I can't grok this one: shouldn't gparted report on it? Or you don't
> > expect the free space to be there?
>
> Gparted displays the desired data in the GUI, but I see no way to get that
> information as a text stream. I need a text file for my application.
>
> Thanks
>
clipit may be able to snag this information for you then dump it to a
text file for you.  Not as elegant as a script though.

>
>
>
>

--

[toc] | [prev] | [next] | [standalone]

#204798

On 01/28/2019 01:43 PM, Pascal Hambourg wrote:
> Le 28/01/2019 à 13:48, Richard Owlett a écrit :
>>>
>>> So it looks as if   df --output -x tmpfs -x devtmpfs   gives you all
>>> you want (and more) with the exception of LABELs.
>>
>> No. The man pages states it only looks at mounted partitions due to 
>> "...nonportable intimate knowledge of file system structures]. As I 
>> only have FAT and ext partitions, what I want should be doable if not 
>> already done.
> 
> The total and used/free space in ext and FAT filesystems can be computed 
> from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n.
> 

Murphy's Law has won this round, all my disks have "msdos Partition 
table".  I get the following error message:
> root@fromdell:/home/richard# tune2fs -l /dev/sda
> tune2fs 1.43.4 (31-Jan-2017)
> tune2fs: Bad magic number in super-block while trying to open /dev/sda
> Found a dos partition table in /dev/sda

Additionally, all my machines have legacy BIOS.

I assume "fsck.dos" is a typo as
[https://dyn.manpages.debian.org/jump?suite=stretch&binarypkg=dosfstools&section=8&language=en&q=fsck.dos]
     yields
"Sorry, the manpage “fsck.dos” was not found!"

Thanks for trying.

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

[toc] | [prev] | [next] | [standalone]

#204808

Le 29/01/2019 à 15:30, Richard Owlett a écrit :
> On 01/28/2019 01:43 PM, Pascal Hambourg wrote:
>>
>> The total and used/free space in ext and FAT filesystems can be 
>> computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n.
> 
> all my disks have "msdos Partition table".

Irrelevant.

>  I get the following error message:
>> root@fromdell:/home/richard# tune2fs -l /dev/sda
>> tune2fs 1.43.4 (31-Jan-2017)
>> tune2fs: Bad magic number in super-block while trying to open /dev/sda
>> Found a dos partition table in /dev/sda

You must specify the partition containing the filesystem, not the whole 
disk.

> Additionally, all my machines have legacy BIOS.

Irrelevant.

> I assume "fsck.dos" is a typo as

Yes, my mistake. I meant fsck.fat or fsck.msdos.

[toc] | [prev] | [next] | [standalone]

#204822

On 01/29/2019 02:08 PM, Pascal Hambourg wrote:
> Le 29/01/2019 à 15:30, Richard Owlett a écrit :
>> On 01/28/2019 01:43 PM, Pascal Hambourg wrote:
>>>
>>> The total and used/free space in ext and FAT filesystems can be 
>>> computed from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n.
>>
>> all my disks have "msdos Partition table".
> 
> Irrelevant.

Debian thought it relevant enough to mention in a warning(error?) 
message. There I thought it reasonable that it was true of _all_ my disks.

> 
>>   I get the following error message:
>>> root@fromdell:/home/richard# tune2fs -l /dev/sda
>>> tune2fs 1.43.4 (31-Jan-2017)
>>> tune2fs: Bad magic number in super-block while trying to open /dev/sda
>>> Found a dos partition table in /dev/sda
> 
> You must specify the partition containing the filesystem, not the whole 
> disk.

The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each give 
"device" as a possible parameter. Only the last two balk at it.

[toc] | [prev] | [next] | [standalone]

#204825

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 30, 2019 at 09:07:37AM -0600, Richard Owlett wrote:

[...]

> The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each
> give "device" as a possible parameter. Only the last two balk at it.

This is as if you said that a fillet knife and a nutcracker both
specify "food" as a possible parameter. But expect the cook to
kick you out of the kitchen if you try to crack a nut with the
fillet knife (although you might succeed at it).

As a toolsguy this should be familiar to you.

The last two expect a "device" (which is just a kind of file, you
can do all of that with a bog standard file, everything which can
be seen as a long series of blocks is fair game) _containing_ an
ext2 file system (actually they most probably look first at the
header to check this).

 - (block) device file: (e.g. /dev/sdb)
   a contraption of your operating system making a storage
   device available as a file of sorts, to ease the lives
   of many utilities

 - partition: a part of a block device. Usually (you don't
   _have_ to), a storage device is subdivided into several
   partitions. This subdivision is documented in the
   partition table (which can be the oldskool DOS partition
   table with the well-known limitations of 4 viz. 3+4
   partitions or a more modern GPT or some others living
   out there). Usually this partition table is written as
   a data structure somewhere at the start of the storage
   device (and thus at the first block(s) of the device
   file).

   A partition is usually made available as a device file
   too (e.g. /dev/sdb1)

   A plain regular file can be made available as a device
   via the loopback driver (this is useful for virtual
   machines, but also for experiments -- e.g. I work on
   a file "image" for my Raspi which I can mount and
   look into with my laptop. When I'm happy I just dump
   it to an SD card.

 - file system: the whole machinery needed to organize your
   data whithin a huge unstructured pool of blocks. There
   are many constraints on a file system, like efficient
   space usage, quick allocation of new files, contiguous
   allocation of space (whenever possible) for a file (this
   is most important for mechanical drives), etc.

   There are many different file systems, in response to
   many different requirements and historical roots.

   You typically "put" a file system on a device file (the
   storage behind that is the "backend"), be it a device,
   a partition, a logical volume or a loopback on a
   regular file: the file system code doesn't care, as
   long as it sees a long, boring array of blocks, all
   alike.

Clearer now?

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#204846 — Talking about loop devices (was: Re: Partition information as text file?)

On Thu, 31 Jan 2019 at 02:52, <tomas@tuxteam.de> wrote:
>
> [...]
>
>    A plain regular file can be made available as a device
>    via the loopback driver

I have a small addition to this excellent message.

There is very widespread mixup of the terms "loopback"
and "loop" in the context of block devices.

I've written about this in the past here. I will do my best to be
correct, and give evidence, although
1) I wish I had more evidence
2) I can't remember when I first became aware of this
3) I have very little knowledge of kernel development ...

A *loop* device is a *filesystem* technique to make a file
accessible as a block device.

Whereas a *loopback* device is a virtual *network* interface.

The word "loopback" does not appear in 'man mount'.

https://en.wikipedia.org/wiki/Loop_device says:
"Sometimes, the loop device is erroneously referred to as loopback device,
but this term is reserved for a networking device in operating systems."

Unfortunately I cannot remember where this first came to my
attention, so I can't provide a better authoritative reference.
There must be one in existence out there somewhere, because
I'm certain I didn't invent this myself, so I must have read about
it somewhere.

And I vaguely recall reading that some attempts were made to correct
this in the kernel source. Today I tried to find some evidence of that ...

For example, back in 2005 (linux 2.6.12) says:
https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

----- begin quote -----
7 block Loopback devices
0 = /dev/loop0 First loopback device
1 = /dev/loop1 Second loopback device
...
The loopback devices are used to mount filesystems not
associated with block devices. The binding to the
loopback devices is handled by mount(8) or losetup(8).
----- end quote -----

"loopback" is everywhere there!

Compare with today's version:
https://github.com/torvalds/linux/blob/v4.19/Documentation/admin-guide/devices.txt#L191

----- begin quote -----
7 block Loopback devices
0 = /dev/loop0 First loop device
1 = /dev/loop1 Second loop device
...
The loop devices are used to mount filesystems not
associated with block devices. The binding to the
loop devices is handled by mount(8) or losetup(8).
----- end quote -----

So all but one instance has changed from "loopback" to
"loop" ... maybe someone did a case-sensitive search/replace? :)

Searching the kernel source for the word "loopback" here:
https://livegrep.com/search/linux?q=loopback&fold_case=auto&regex=false&context=false
shows that, when referring to block devices, the word
"loopback" only appears in documentation here and there,
never in code.

The actual driver code is here:
https://github.com/torvalds/linux/blob/v4.19/drivers/block/loop.c

$ grep -c -i loopback loop.c
2
$ grep -c -i loop loop.c
343

The concept of "loopback" doesn't seem relevant to
a loop device. It's just a filesystem in a file, isn't it?
I suppose that's a slightly recursive concept,
but it's not circular like a loop. To me, the word "loopback"
suggests that something is going around and coming
back again. I don't see how that is relevant to a loop
device.

Comments welcome. Maybe Ted Ts'o will read this and
enlighten us (me).

[toc] | [prev] | [next] | [standalone]

#204851 — Re: Talking about loop devices (was: Re: Partition information as text file?)

On Thu, 31 Jan 2019 at 12:15, David <bouncingcats@gmail.com> wrote:
>
> So all but one instance has changed from "loopback" to
> "loop" ... maybe someone did a case-sensitive search/replace? :)

Well, I found where that change happened, in 2006:
https://github.com/torvalds/linux/commit/11420211b8123d0e2f71945ad022e8eec28ebfce

But that's not very enlightening, because the file that
the commit message mentions as the reason for the changes
http://www.lanana.org/docs/device-list/devices-2.6+.txt
today says "loopback" there.

So, I dunno :(

[toc] | [prev] | [next] | [standalone]

#204855 — Re: Talking about loop devices (was: Re: Partition information as text file?)

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 31, 2019 at 12:15:58PM +1100, David wrote:
> On Thu, 31 Jan 2019 at 02:52, <tomas@tuxteam.de> wrote:
> >
> > [...]
> >
> >    A plain regular file can be made available as a device
> >    via the loopback driver
> 
> I have a small addition to this excellent message.
> 
> There is very widespread mixup of the terms "loopback"
> and "loop" in the context of block devices.

You are right: what I referred to as "loopback" device is known as
a "loop" device. Thanks for the clarification.

Cheers
-- t

[toc] | [prev] | [next] | [standalone]

#204869 — Re: Talking about loop devices

Le 31/01/2019 à 02:15, David a écrit :
> 
> A *loop* device is a *filesystem* technique to make a file
> accessible as a block device.

I do not think that loop devices have anything to do with filesystems.
The losetup(8) manpage states :

        losetup  is  used to associate loop devices with regular files or
        *block devices* (...)

A use case for a loop device based on another block device is to create 
a partitionable block device when the underlying block device contains a 
raw disk image but is not partitionable (e.g. partition or logical volume).

> ----- begin quote -----
> The loop devices are used to mount filesystems not
> associated with block devices.
> ----- end quote -----

There are other uses. In addition to the use case I mentionned above, a 
loop device can also be used as a swap device when the filesystem does 
not support swap files (e.g. btrfs).

[toc] | [prev] | [next] | [standalone]

#204882 — Re: Talking about loop devices

On Fri, 1 Feb 2019 at 05:50, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
> Le 31/01/2019 à 02:15, David a écrit :
> >
> > A *loop* device is a *filesystem* technique to make a file
> > accessible as a block device.
>
> I do not think that loop devices have anything to do with filesystems.
> The losetup(8) manpage states :
>
>         losetup  is  used to associate loop devices with regular files or
>         *block devices* (...)
>
> A use case for a loop device based on another block device is to create
> a partitionable block device when the underlying block device contains a
> raw disk image but is not partitionable (e.g. partition or logical volume).
>
> > ----- begin quote -----
> > The loop devices are used to mount filesystems not
> > associated with block devices.
> > ----- end quote -----
>
> There are other uses. In addition to the use case I mentionned above, a
> loop device can also be used as a swap device when the filesystem does
> not support swap files (e.g. btrfs).

Thanks for clarifying my imprecise language, and adding extra info.

[toc] | [prev] | [next] | [standalone]

#204826

On Wed, 30 Jan 2019 09:07:37 -0600
Richard Owlett <rowlett@cloud85.net> wrote:


> >   
> >>   I get the following error message:  
> >>> root@fromdell:/home/richard# tune2fs -l /dev/sda
> >>> tune2fs 1.43.4 (31-Jan-2017)
> >>> tune2fs: Bad magic number in super-block while trying to
> >>> open /dev/sda Found a dos partition table in /dev/sda  
> > 
> > You must specify the partition containing the filesystem, not the
> > whole disk.  
> 
> The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each
> give "device" as a possible parameter. Only the last two balk at it.
> 
> 
> 

On *some* devices. Not all devices have partition tables. I've seen a
few USB sticks come formatted without a partition table, which
strangely, *almost* works. Some software can deal with it, some can't.
I first encountered it when using one to move data between OSes, and
it took me a while to figure out what was going on.

I'm sure you've realised by now, your requirement is to extract
information from two different types of object, partitions and
filesystems. That requires two different utilities. Apparently GParted
will make a stab at displaying free space on unmounted filesystems, but
it either does that by temporarily mounting them or it interprets the
metadata of the filesystem itself, with no guarantee that it always gets
it right. An unmounted filesystem is basically, well, gibberish, a
collection of tables and file fragments. It's only when the filesystem
is mounted that the parts of it that we mortals are allowed to see make
sense.

I suspect that to get exactly what you want, you will need to write a
script that uses basic tools, checking for mounted filesystems and then
temporarily mounting as necessary. 

By the way, you haven't mentioned LVM...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#204864

On 01/30/2019 10:04 AM, Joe wrote:
> [snip]
> 
> I suspect that to get exactly what you want, you will need to write a
> script that uses basic tools, checking for mounted filesystems and then
> temporarily mounting as necessary.

Yes ;}
But before this thread I didn't have needed background.

> 
> By the way, you haven't mentioned LVM...
> 

I'm working with a conglomeration created before I ever hear of LVM.
I suspect I was on the way to (re)inventing it.

[toc] | [prev] | [next] | [standalone]

#204830

Le 30/01/2019 à 16:07, Richard Owlett a écrit :
> On 01/29/2019 02:08 PM, Pascal Hambourg wrote:
>> Le 29/01/2019 à 15:30, Richard Owlett a écrit :
>>>
>>> all my disks have "msdos Partition table".
>>
>> Irrelevant.
> 
> Debian thought it relevant enough to mention in a warning(error?) 
> message.

Not Debian. Just tune2fs, as a hint suggesting that maybe you specified 
the wrong device.

>>>   I get the following error message:
>>>> root@fromdell:/home/richard# tune2fs -l /dev/sda
>>>> tune2fs 1.43.4 (31-Jan-2017)
>>>> tune2fs: Bad magic number in super-block while trying to open /dev/sda
>>>> Found a dos partition table in /dev/sda
>>
>> You must specify the partition containing the filesystem, not the 
>> whole disk.
> 
> The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each give 
> "device" as a possible parameter. Only the last two balk at it.

"Device" is in the generic sense of Unix block device. Not just a whole 
disk, but also a partition, logical volume, RAID array, encrypted volume...

fdisk, parted and sfdisk manage partition tables and expect a device 
containing a partition table.
tune2fs and dumpe2fs manage ext* filesystems and expect a device 
containing an ext* filesystem.

[toc] | [prev] | [next] | [standalone]

#204815

On Wed, 30 Jan 2019 at 01:30, Richard Owlett <rowlett@cloud85.net> wrote:
> On 01/28/2019 01:43 PM, Pascal Hambourg wrote:
> >
> > The total and used/free space in ext and FAT filesystems can be computed
> > from the output of tune2fs -l/dumpe2fs -h and fsck.dos -n.
>
> I assume "fsck.dos" is a typo as
> [https://dyn.manpages.debian.org/jump?suite=stretch&binarypkg=dosfstools&section=8&language=en&q=fsck.dos]
>      yields
> "Sorry, the manpage “fsck.dos” was not found!"

In case you are not aware, here's a way to investigate that ...

$ apt-file search fsck.dos

gave no output, so I broadened the net ...

$ apt-file search fsck | grep dos
dosfstools: /sbin/dosfsck
dosfstools: /sbin/fsck.fat
dosfstools: /sbin/fsck.msdos
dosfstools: /sbin/fsck.vfat
dosfstools: /usr/share/doc/dosfstools/ChangeLog.dosfsck
dosfstools: /usr/share/doc/dosfstools/README.dosfsck
dosfstools: /usr/share/man/man8/dosfsck.8.gz
dosfstools: /usr/share/man/man8/fsck.fat.8.gz
dosfstools: /usr/share/man/man8/fsck.msdos.8.gz
dosfstools: /usr/share/man/man8/fsck.vfat.8.gz
manpages-fr-extra: /usr/share/man/fr/man8/dosfsck.8.gz
manpages-fr-extra: /usr/share/man/fr/man8/fsck.msdos.8.gz
manpages-pl: /usr/share/man/pl/man8/dosfsck.8.gz
manpages-pl: /usr/share/man/pl/man8/fsck.msdos.8.gz

Maybe it's a typo mixup of 'dosfsck' and 'fsck.msdos',
which are both symlinks to the same executable ...

$ ls -l /sbin/dosfsck
lrwxrwxrwx 1 root root 8 2017-01-25 10:48 /sbin/dosfsck -> fsck.fat
$ ls -l /sbin/fsck.msdos
lrwxrwxrwx 1 root root 8 2017-01-25 10:48 /sbin/fsck.msdos -> fsck.fat

[toc] | [prev] | [next] | [standalone]

#204824

On 01/29/2019 08:05 PM, David wrote:
> On Wed, 30 Jan 2019 at 01:30, Richard Owlett <rowlett@cloud85.net> wrote:
>> ...
>> [https://dyn.manpages.debian.org/jump?suite=stretch&binarypkg=dosfstools&section=8&language=en&q=fsck.dos]
>>       yields
>> "Sorry, the manpage “fsck.dos” was not found!"
> 
> In case you are not aware, here's a way to investigate that ...
> 
> $ apt-file search fsck.dos
> 
> gave no output, so I broadened the net ...
> 
> $ apt-file search fsck | grep dos ...

I wasn't aware.
Thank you.

[toc] | [prev] | [next] | [standalone]

#204807

On Mon 28 Jan 2019 at 06:48:00 (-0600), Richard Owlett wrote:
> On 01/27/2019 03:26 PM, David Wright wrote:
> > On Sat 26 Jan 2019 at 15:10:55 (-0600), Richard Owlett wrote:
> > > On 01/26/2019 01:32 PM, Felix Miata wrote:
> > > > Richard Owlett composed on 2019-01-26 08:32 (UTC-0600):
> > > > 
> > > > > I am attempting to create a spreadsheet to document the content of
> > > > > multiple disks of multiple machines.
> > > > 
> > > > > Gparted displays the desired information.
> > > > > *HOWEVER* I see no way to capture the information.
> > > > 
> > > > > At the command line using "lsblk -o NAME,FSTYPE,LABEL /dev/sdb" gives
> > > > > most of the desired information.
> > > > 
> > > > > It omits partition size, used space, and unused space.
> > > > 
> > > > > Suggestions?
> > […]
> > > > Sometimes I append output from lsblk or parted -l.
> > > > 
> > > > hdparm and smartctl might also provide some of what you're looking for.
> > > 
> > > I'll attempt to redefine my problem.
> > > 
> > > I have:
> > >    multiple machines
> > > each having
> > >    multiple disks
> > > each having
> > >    multiple partitions.
> > > 
> > > I wish to inventory the above "conglomeration".
> > > 
> > > I wish to to answer the question(s):
> > >    How big is each
> > >    How much is available
> > 
> > It appears that you're really interested in the filesystems'
> > information rather than the partitions', with the exception of the
> > filesystem LABELs, which you have said elsewhere you use as
> > indications of the filesystems' contents.
> 
> That's likely. There are some terminology issues I'll have to follow
> up on so that I'll use terms in ways compatible to others.
> 
> > 
> > So it looks as if   df --output -x tmpfs -x devtmpfs   gives you all
> > you want (and more) with the exception of LABELs.
> 
> No. The man pages states it only looks at mounted partitions due to
> "...nonportable intimate knowledge of file system structures].

Then mount them. As readonly if preferred.

> As I
> only have FAT and ext partitions, what I want should be doable if not
> already done.

Then do it. All the tools are in the thread, if not in this post.

> > It seems sensible
> > to use   lsblk -o NAME,LABEL -l   to get these because AFAICT it
> > automatically handles the business of selecting e2label/dosfslabel/etc
> > as appropriate and gets them all in a heap.
> > 
> > With judicious use of head, tail and sort, it would be fairly simple
> > to get the two listings to correspond well enough for entry into a
> > spreadsheet (I don't know what you meant by 'generic'), making
> > final adjustments (df omits the device and partitions like swap) to
> > line things up.
> 
> I'm going to have to reread this thread. There is something in the
> back of mind hinting at a solution. It will require some scripting to
> pull pieces together, but that was assumed to be likely anyway.

BTW you could read   man man.

Cheers,
David.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.debian.user

csiph-web