1 Topic by Al_Jardine (edited by Al_Jardine 2012-12-18 06:39:57)

  • Al_Jardine
  • New member
  • Offline
  • Registered: 2012-12-16
  • Posts: 3

Topic: [SOLVED] gparted 0.12.1 - unable to read contents of file systems!

I normally use gparted from a live CD, but I occasionnally launch it to take a quick look at the setup of my partitions while I'm logged in to one of my "live" systems.

I have just upgraded this particular one from debian squeeze to wheezy and I'm seeing something rather odd.

All the partitions (save the mounted partitions that display the padlock icon instead..) are marked with the little triangle and the exclamation mark on an orange background.

When I select such partitions trying to find out what the problem is under Partition -> Information, gparted gives me this explanation:

Unable to read the contents of this file system!
Because of this some operations may be unavailable.

The cause might be a missing software package.
The following list of software packages is required for ntfs
file system support: ntfsprogs / ntfs-3g

or 

The cause might be a missing software package.
The following list of software packages is required for ext3
file system support: e2fsprogs

and so on...

Now the problem is that:

  • All such software packages are duly installed and show no errors in the apt/dpkg packaging system

  • gparted on the other active systems that are installed on this computer (such as ubuntu, kubuntu, Mint) or on a couple of live CD's I have tried has no problem whatsoever

  • the upgraded system is otherwise running smoothly and there are no errors relative to file systems under /var/log/

  • odder still, I can't seem to find any reports of anyone else experiencing such symptoms

This looks more like a problem with a corrupt library setup, but before I send in a bug report to debian, I was wondering if this might be a known gparted 0.12.1 problem that I keep missing.

Or otherwise... perhaps someone could take a guess at what might be happening and suggest what I could do next to try and narrow it down a bit.

Thanks,

Al

*** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ***

   The problem is caused by invoking gparted like so: "sudo gparted". Someone on a debian forum had run into this problem at some point and found out that you could work around it by invoking gparted via a "/bin/su -c gparted" instead.

   Since using the su command instead of sudo requires knowledge of the superuser password, I played with sudo a little further and discovered that "sudo -i gparted" also works while it only asks you for your userid's password.

   Per man sudo the "-i flag" simulates an initial login shell; I have no idea why this is necessary to enable gparted to read partitions' metadata successfully and since I am not familiar with the code I will not hazard a guess.

   In any case I'm sure glad this was not caused by corruption in libraries or the packaging system..!

*** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ** [SOLVED] ** UPDATE ***

2 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: [SOLVED] gparted 0.12.1 - unable to read contents of file systems!

The error message is related to GParted failing to determine the usage of the NTFS file system.

GParted uses the following command to determine usage of the NTFS file system:

ntfsresize --info --force --no-progress-bar /path-to-partition

Where:  /path-to-partition is something like /dev/sda1

Would you be able to provide the output from this above command from your GNU/Linux distribution that is exhibiting the problem?

3 Reply by Al_Jardine

  • Al_Jardine
  • New member
  • Offline
  • Registered: 2012-12-16
  • Posts: 3

Re: [SOLVED] gparted 0.12.1 - unable to read contents of file systems!

gedakc wrote:

The error message is related to GParted failing to determine the usage of the NTFS file system.

GParted uses the following command to determine usage of the NTFS file system:

ntfsresize --info --force --no-progress-bar /path-to-partition

Where:  /path-to-partition is something like /dev/sda1

Would you be able to provide the output from this above command from your GNU/Linux distribution that is exhibiting the problem?

Here's the output for a couple of NTFS partitions:

[14:41:47][root@*****:~]# ntfsresize --info --force --no-progress-bar /dev/sda3
ntfsresize v2012.1.15AR.5 (libntfs-3g)
Device name        : /dev/sda3
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 25166172672 bytes (25167 MB)
Current device size: 25166176256 bytes (25167 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use       : 7326 MB (29.1%)
Collecting resizing constraints ...
You might resize at 7325298688 bytes or 7326 MB (freeing 17841 MB).
Please make a test run using both the -n and -s options before real resizing!
[14:47:05][root@*****:~]# ntfsresize --info --force --no-progress-bar /dev/sda1
ntfsresize v2012.1.15AR.5 (libntfs-3g)
Device name        : /dev/sda1
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 1825567232 bytes (1826 MB)
Current device size: 1825570816 bytes (1826 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use       : 848 MB (46.4%)
Collecting resizing constraints ...
You might resize at 847208448 bytes or 848 MB (freeing 978 MB).
Please make a test run using both the -n and -s options before real resizing!

And here's an e2fsprogs equivalent:

[14:41:05][root@*****:~]# tune2fs -l /dev/sdb5
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   LENNY
Last mounted on:          <not available>
Filesystem UUID:          ac80646e-439c-4231-a89f-aad18c3c316a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              732960
Block count:              2929838
Reserved block count:     146491
Free blocks:              1335986
Free inodes:              514543
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      715
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8144
Inode blocks per group:   509
Filesystem created:       Sun Dec 19 15:33:22 2010
Last mount time:          Sat Dec 15 04:08:02 2012
Last write time:          Sat Dec 15 06:39:11 2012
Mount count:              54
Maximum mount count:      29
Last checked:             Thu Mar 29 20:09:16 2012
Check interval:           15552000 (6 months)
Next check after:         Tue Sep 25 20:09:16 2012
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      bbda561b-bc03-4355-8e2f-d61a65138350
Journal backup:           inode blocks

Thanks.

4 Reply by gedakc

  • gedakc
  • Developer
  • Offline
  • Registered: 2007-11-30
  • Posts: 4,592

Re: [SOLVED] gparted 0.12.1 - unable to read contents of file systems!

Hmm... everything looks normal in the output you provided.

Before you report a bug to Debian, you might try booting the same Debian Live version of the OS and checking to see if the problem shows up there.  If not then it is likely something unique to your partitcular install, and might indeed be a corrupted library.

5 Reply by Al_Jardine

  • Al_Jardine
  • New member
  • Offline
  • Registered: 2012-12-16
  • Posts: 3

Re: [SOLVED] gparted 0.12.1 - unable to read contents of file systems!

gedakc wrote:

Hmm... everything looks normal in the output you provided.

Before you report a bug to Debian, you might try booting the same Debian Live version of the OS and checking to see if the problem shows up there.  If not then it is likely something unique to your partitcular install, and might indeed be a corrupted library.

Yes, that would help.

I think I have narrowed it down enough now to go talk to the debian packagers.

Thanks..!