Peculiar disk partitioning hangs partition editors

opensuse v12.3 I tried yast/system/partitioner and gparted. Both hang forever when detecting the partitioning of a disk drive. The yast partitioner (/usr/lib/YaST2/bin/y2base disk gtk) must be killed; it did not respond to any input. gparted was more polite but just as useless. parted, however, does manage to show the layout. (It takes nearly a minute, though.)

(parted) print                                                             Model: FUJITSU MAW3073NP (scsi) Disk /dev/sdb: 73.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos  Number  Start   End     Size    Type      File system     Flags  1      32.3kB  12.9GB  12.9GB  primary   ext3            boot, type=83  2      12.9GB  73.5GB  60.6GB  extended                  type=05  5      12.9GB  17.1GB  4187MB  logical   linux-swap(v1)  type=82  6      17.1GB  73.5GB  56.5GB  logical   ext3            type=83

I am presuming that the “extended” partition, 2, is the problem here. How do I fix it?

Hi !

From your number of postings it seems quite clear that this is not a fake.

However, your output of parted, that you posted, is weird,
and I don’t know how you managed to get it that way.

Mine looks like

host:~ # 
host:~ # parted
GNU Parted 2.4
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
Model: ATA Hitachi HDS72302 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      1049kB  106MB   105MB   primary   ntfs            type=07
 2      106MB   429GB   429GB   extended                  boot, lba, type=0f
 5      107MB   17.3GB  17.2GB  logical   linux-swap(v1)  type=82
 6      17.3GB  51.6GB  34.4GB  logical   ext3            type=83
 7      51.6GB  86.0GB  34.4GB  logical   ext3            type=83
 8      86.0GB  258GB   172GB   logical   ext3            type=83
 9      258GB   429GB   172GB   logical   ext3            type=83
 3      429GB   704GB   275GB   primary   ntfs            type=07
 4      704GB   2000GB  1296GB  primary   ntfs            type=07


(parted) quit                                                             
host:~ # 
host:~ #

Please run parted again,
but then say ‘print all’,
and post the output again here.

From what you write, on the other hand, it is possible
that you may have a hardware problem.

Please open a terminal.
Say “su” to become root, and enter password.

Then, in order to see more about the health of your
devices (you have more than 1),
enter

smartctl -a /dev/sda

and after that

smartctl -a /dev/sdb

and post the output of both here.

Good luck
Mike

On 2013-12-01 23:06, jimoe666 wrote:
>
> opensuse v12.3 I tried yast/system/partitioner and gparted. Both hang
> forever when detecting the partitioning of a disk drive. The yast
> partitioner (/usr/lib/YaST2/bin/y2base disk gtk) must be killed; it did
> not respond to any input. gparted was more polite but just as useless.
> parted, however, does manage to show the layout. (It takes nearly a
> minute, though.)
> Code:
> --------------------
> (parted) print Model: FUJITSU MAW3073NP (scsi) Disk /dev/sdb: 73.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 12.9GB 12.9GB primary ext3 boot, type=83 2 12.9GB 73.5GB 60.6GB extended type=05 5 12.9GB 17.1GB 4187MB logical linux-swap(v1) type=82 6 17.1GB 73.5GB 56.5GB logical ext3 type=83
> --------------------
> I am presuming that the “extended” partition, 2, is the problem here.
> How do I fix it?

I can not make head or tails of that text. Is it wrapped?


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I took the liberty to break the lines of parted’s output into a more readable table:

(parted) print                                                             
Model: FUJITSU MAW3073NP (scsi) Disk 
/dev/sdb: 73.5GB 
Sector size (logical/physical): 512B/512B 
Partition Table: msdos  

Number  Start   End     Size    Type      File system     Flags  
1      32.3kB  12.9GB  12.9GB  primary   ext3            boot, type=83  
2      12.9GB  73.5GB  60.6GB  extended                  type=05  
5      12.9GB  17.1GB  4187MB  logical   linux-swap(v1)  type=82  
6      17.1GB  73.5GB  56.5GB  logical   ext3            type=83

Except for the offsets, the table looks ok to me. According to the online parted manual (GNU parted - Parted User’s Manual - GNU Project - Free Software Foundation (FSF)) that is covering parted v3.1 (openSUSE 12,3 and 13.1 has parted v2.4), parted is true to unit usage. That means 32.3kB = 32300 bytes. That means your starting partition doesn’t even align with 512 bytes.

If the offsets displayed are accurate, you have terribly aligned partitions. Your harddisk will suffer performance due to that, but I am unsure what the impact is in the day-to-day use.

You can use parted to check the alignment for you:
Syntax:

parted <device>
print
align-check {min|opt} <partition number>

An example from my test computer: openSUSE 13.1 in a VMWare VM (you should use /dev/sdb):

mytest:/ # parted /dev/sda
GNU Parted 2.4
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 16.1GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  773MB   772MB   primary  linux-swap(v1)  type=82
 2      773MB   14.0GB  13.2GB  primary  ext4            boot, type=83
 3      14.0GB  16.1GB  2147MB  primary  ext4            type=83

(parted) align-check min 1                                                
1 aligned
(parted) align-check opt 1                                             
1 aligned
(parted) quit                                                             
mytest:/ #

If parted results in anything but “<n> aligned”, you should try to re-align your partitions or you should delete all partitions and recreate them. Recreation will take care of partition alignment too.

Before doing anything like that, you should back up your disk. There are several partition alignment tools out there, but your options may be limited since you only could make parted read your partition table, and it doesn’t look like parted is able to align partitions.


One last thought: How did the partitions end up like that? Are the disk’s platters slipping (or did it take a drop from some height?), or were they really created like that? Did you use to use it for a non-standard setup - or, since it is an old but really fast disk normally used in servers - did you inherit it second hand from a RAID-array or something that could have contributed to the unusual partition alignment?

You should ask yourself that and decide whether the disk is starting its decline or not, and whether it is worth struggling with. Yes, it is a fast disk, but it is also starting to get of age, so if it has been used continously since it was new, you may be better off with another disk.

dayfinger

To answer the question “How did that partitioning happen?” I have to say, “Not a clue.” I believe the system was created with either opensuse v9 or v10, and upgraded successfully from there to v11.x and finally to v12.3. I let the installer do the work; I only indicated the size and mount points.

Carlos: Can’t help you. The “scrambled” part was inside CODE elements. Why you cannot see it and others can is another mystery.

Regarding alignment:

(parted) print
Model: FUJITSU MAW3073NP (scsi)
Disk /dev/sdb: 73.5GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system     Flags
 1      32.3kB  12.9GB  12.9GB  primary   ext3            boot, type=83
 2      12.9GB  73.5GB  60.6GB  extended                  type=05
 5      12.9GB  17.1GB  4187MB  logical   linux-swap(v1)  type=82
 6      17.1GB  73.5GB  56.5GB  logical   ext3            type=83

(parted) align-check min 1
1 aligned
(parted) align-check opt 1                                             
1 not aligned
(parted) align-check min 2
2 aligned
(parted) align-check opt 2
2 not aligned
(parted)

>If parted results in anything but “<n> aligned”,
>you should try to re-align your partitions
>
How do I re-align a partition?
Does re-alignment destroy the data in the partition?

> or you should delete all partitions and recreate them.
>
Only as a last resort. Way last.

This is of course of only secondary importance yo your problem, but CODE tags alone is not enough. You must copy/paste from your terminal emulator directly in between the tags. I do not know if you did that. When you e.g. first posted, then saw you forgot the CODE tags and edited the post, the lay-out is already gone. Just an idea on how it could go wrong.

On 2013-12-02 07:06, jimoe666 wrote:

> Carlos: Can’t help you. The “scrambled” part was inside CODE elements.
> Why you cannot see it and others can is another mystery.

No, nobody can. But “dayfinger” took the effort to decipher and repost.

>> or you should delete all partitions and recreate them.
>>
> Only as a last resort. Way last.

Well… I think that is what you must do.

Although I would first verify the disk with smartctl, the long test.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I can’t read it either. It shows up as one very long line. I’m not sure how that happens, but I occasionally see other posts with the same problem.

Alignment requirements have changed over the years. At one time, we used to align to cylinders, even though the disk geometry presented was virtual. These days we align to megabyte (2^20) boundaries, or something similar.

Your partition alignment probably reflects the history of the disk and changing alignment standards.

I very much doubt the “doesn’t even align with 512 bytes” comment - that probably ignores rounding in the presented numbers.

If it were me, I would probably just continue using the disk as is. But, given that it is an older disk, prepare for the day when it fails.

On 2013-12-02 16:16, nrickert wrote:
> If it were me, I would probably just continue using the disk as is.
> But, given that it is an older disk, prepare for the day when it fails.

But he can not if partition tools refuse to. Maybe it is not the
alignment, it is a disk read error.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

That’s why I said “if” and recommended to do the alignment-check. That will tell you.


@jimoe666 and others:

Actually, it didn’t occur to me when I was typing in my previous answer here, but the rounding error is demonstrated in my dump from my test computer. My first partition is listed to start at 1049kB, which isn’t any factor of 512B, yet it is properly aligned as is demonstrated in the example (I also know I aligned the first partition to 1MiB).
That fact renders parted’s print partition output only to be approximately correct, and nothing to base any technical decision upon. Also, - and this is speculation - parted’s unit usage may have changed between version 2.4 and 3.1, and the latter version is the basis for my reasoning (as I said). I don’t know. v3.1 is listed to use kiB just as well as kB. When 1024kiB is accurate (which spells out to 1048.576kB BTW), why use a rounded and inaccurate 1049kB in its place? That could mean v2.4 doesn’t use kiB/MiB/GiB at all, but it still is true to the use of kB/MB/GB. The output, however, isn’t really useful.

Nonetheless, parted’s alignment-check will tell you - as it does in this case:
The minimum alignment is in place (512B I presume, and it confirms the inaccuracy of parted’s print partition output). The optimal alignment isn’t in place. What parted think is optimal alignment, I don’t know. I am not familiar enough yet with Linux disk handling to tell, but it normally has to do with caching and prefetching data optimally. Getting that right, will improve your disk performance. As a “qualified guess” I would, however, expect 1MiB to hit the optimal value for you as well (=the optimal value being something that will multiply by itself or an even factor into 1MiB), as most partitioning tools these days use that as a default alignment value.

Now, what remains is to find out why it is so slow - at least when reading partition tables. How is the speed of the disk in normal use, BTW?


Some more speculation - and something to try (based on my own experience):
It may even be that the magnetic layer on the platters are weak, and starts to loose its “signal”. Historically, static info on magnetic disks used to fade out after a while. In the early days, after 2 years of data storage without (re)writing, it wasn’t uncommon to loose data. I’ve “repaired” several harddisks over the years by rewriting its contents. There even was a SW-tool, SpinRite, that automated these things while at the same time being able to pick up info that normally couldn’t be read - which in fact made it a SW-harddisk-technician in its own right. I had even more success using that tool. Then harddisk controllers changed and rendered SpinRite useless. It was back to data rewriting only. Harddisks improved also, so data refreshing is less necessary these days, but it is no doubt still useful for a disk of the right state.
The other partition-reading utilities may have timed out while waiting for proper results to arrive, and parted may have just that tad longer timeout to be able to read it.

I recommend that you execute the disk-test suggested by ratzi.

If it turn out ok, the next thing would be to try rewriting the partition table (=refresh the magnetic media where the partition table is physically written). If that proves to remedy your problem (rewriting the partition table alone doesn’t take much time, and it doesn’t need much space elsewhere, either), then it may be an idea to refresh the whole disk as you may have other spots on the platters that are very rarely used. Those spots would gain from a magnetic refresh too.

You can use “dd” for that, but I am not fluent enough with that tool yet to dare to recommend any syntax for it now. Maybe someone could suggest a current tool that does it automatically, while being aimed at the end user (I doubt I am the only one that have had this experience). Using “dd” would be a two-step process, where the first part would be to read the data FROM the disk (and store it elsewhere), and the second part would be to write these data back in the original spots.


If you decide that partition re-alignment is of interest, you should be prepared for such a tool to be data destructive, but I really don’t know if they are. You should search for “partition re-alignment” on the internet, and pick the tool that fits you the most. I have never used any of those, as I would normally simply flush the disk completely and rebuild it from the ground up - including new partition tables - using original installation media as much as I can, and filling in with data restore where original install is insufficient. Such a process also counts for rewriting the parts of the disk that are rarely written to, and render the data-rewriting principle superfluous. In fact, I’ve done that often enough the later years, that I haven’t been using the data rewrite principle since disks were <<2GiB in size, and I never rewrote/updated that utility.

Again: Due to today’s improved disk technology (which I beleive also includes OP’s “old” disk), rewriting the partition table may be speculative. Nevertheless, considering the time it would take, it could prove to be worth-while. If it proves otherwise, it didn’t take much of your time.
Maybe someone in this forum can help you with the right dd-command parametres to carry out that task, if you don’t know how to do it already.

dayfinger

It looked like I expected in the preview. I see now that the line breaks were removed when it was posted.

Yes, I agree with that.

While alignment issues can slow disk I/O, I would expect the slowing to be a fraction of a second so not noticeable as as the kind of timeout described. So either a disk surface problem or a disk electronics problem, requiring rereading of some sectors, is more likely.

The easy way to do that would be to fire up “fdisk”, change the active flag, and write the results. Then fire up “fdisk” again, and change the active flag back to what it was, and write the results.

Since “fdisk” cannot write less than a full sector, due to the structure of disks, it will have to write back the entire MBR to change that one bit.

This is a test, for my own curiosity.


ls /
altsys  croot  home   lost+found  opt   run      shared  tmp  windows
bin     dev    lib    media       proc  sbin     srv     usr
boot    etc    lib64  mnt         root  selinux  sys     var

I’ll either edit this later, or add another comment, to explain.

(add in edit) I was wondering whether previewing a post with a code block could cause it to become corrupted. That did not happen in this case. But now let’s see if editing corrupts.

On 12/02/2013 02:26 PM, nrickert wrote:
>
> jimoe666;2604593 Wrote:
>> It looked like I expected in the preview. I see now that the line breaks
>> were removed when it was posted.
>
> This is a test, for my own curiosity.
>
>
> Code:
> --------------------
>
> ls /
> altsys croot home lost+found opt run shared tmp windows
> bin dev lib media proc sbin srv usr
> boot etc lib64 mnt root selinux sys var
>
> --------------------
>
>
> I’ll either edit this later, or add another comment, to explain.
>
> (add in edit) I was wondering whether previewing a post with a code
> block could cause it to become corrupted. That did not happen in this
> case. But now let’s see if editing corrupts.

By the way, the arguments and discussion of partition alignment in this thread
are moot. In the very first (line-wrapped) posting, parted said “size
(logical/physical): 512B/512B”. As every disk write involves an entire sector,
the disk is automatically aligned on 512B boundaries. One would only need to
worry if the disk had 512 byte logical blocks, but 4096 byte physical blocks.
Then alignment would matter.

To the OP: Please post the output of ‘sudo /sbin/fdisk -l’. That last character
is an ell, not a one. I am surprised that no one asked for it earlier.

On 2013-12-02 21:36, Larry Finger wrote:
> To the OP: Please post the output of ‘sudo /sbin/fdisk -l’. That last
> character is an ell, not a one. I am surprised that no one asked for it
> earlier.

I at least assumed he tried, but that it was one of the applications
that crashed. On a second read, I do not see it mentioned, so yes, I
agree it would be interesting to see.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

The floppy disk controller was enabled on the motherboard. There was no floppy
drive connected. After disabling the hardware, the partition editors functioned
normally.

Apparently there is nothing incorrect with how that one drive is partitioned.

I had created a bug report https://bugzilla.novell.com/show_bug.cgi?id=853201. It is a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=848796 which indicates that reporthttps://bugzilla.novell.com/show_bug.cgi?id=773058 is not fixed.

On 2013-12-03 19:46, jimoe666 wrote:
>
> The floppy disk controller was enabled on the motherboard. There was no
> floppy drive connected. After disabling the hardware, the partition editors
> functioned normally.

Oh my. I completely forgot that one. I did not recognize the symptoms.

> Apparently there is nothing incorrect with how that one drive is
> partitioned.
>
> I had created a bug report
> https://bugzilla.novell.com/show_bug.cgi?id=853201. It is a duplicate of
> 'https://bugzilla.novell.com/show_bug.cgi?id=848796 which indicates that
> report ’
> (https://bugzilla.novell.com/show_bug.cgi?id=848796)https://bugzilla.novell.com/show_bug.cgi?id=773058
> is not fixed.

Listen, why don’t you create a new bugzilla against the release notes?
This is important enough that users are reminded of the issue.

There is going to be an update of the release notes (the translators
have been told to translate a pair of new items), I don’t know if your
report could catch this fast enough to be included now.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)