[ solved partly ] Hard drive disappears/reappears

[AS]

as

I think you are right, I am going nowhere. I have tried 5 other USB sticks and they do not prevent draklive-installing. The particular one I happened to use use is causing trouble consistently.

A bit more googling also indicates that the USB sticks are know for causing trouble when parted or like is used.

As long as I keep the USB sticks out I should be right. pc1 which started by indicating the hard drive was on the way out has not missed a beat now for 3 days.  Will let it run for few more days and make a decision what to with it.

I'm interested about brand/model of that troublesome USB stick, inserting the USB stick and typing the following commands should provide all info:
dmesg | tail -25
fdisk -l
sfdisk -g

Thanks

AS

[wedgetail]

as

[root@localhost Documents]# dmesg | tail -25
...
...
usb 3-1: new high speed USB device using ehci_hcd and address 3
usb 3-1: New USB device found, idVendor=0930, idProduct=1400
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: TOSHIBA USB DRV
usb 3-1: Manufacturer: TOSHIBA
usb 3-1: SerialNumber: 07AB1B07AC1D7DFC
Initializing USB Mass Storage driver...
scsi2 : usb-storage 3-1:1.0
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver uas
scsi 2:0:0:0: Direct-Access     TOSHIBA  TOSHIBA USB DRV  PMAP PQ: 0 ANSI: 0 CCS
sd 2:0:0:0: Attached scsi generic sg2 type 0
sd 2:0:0:0: [sdb] 7827456 512-byte logical blocks: (4.00 GB/3.73 GiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Attached SCSI removable disk


[root@localhost Documents]# fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xa1dba1db

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    15374204     7687071    b  W95 FAT32
/dev/sda2        15374205   156296384    70461090    5  Extended
/dev/sda5        15374268    48146804    16386268+   b  W95 FAT32
/dev/sda6        48146868    92630789    22241961    b  W95 FAT32
/dev/sda7        92630853   156296384    31832766   83  Linux

Disk /dev/sdb: 4007 MB, 4007657472 bytes
86 heads, 22 sectors/track, 4137 cylinders, total 7827456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xff88a840

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            8064     7827455     3909696    c  W95 FAT32 (LBA)



[root@localhost Documents]# sfdisk -g

/dev/sda: 9729 cylinders, 255 heads, 63 sectors/track
/dev/sdb: 1018 cylinders, 124 heads, 62 sectors/track
[root@localhost Documents]#

Yes that gives good information. Hmmm I have not actually done my math on the CHS perhaps I have missed something here.
Different to grub geometry

Edit note for myself:
Discovered that it is Gparted/parted that is causing the problem with this one USB stick.
For pc1 I tried to install Bonsai and installed the problem Toshiba USB stick, bang down it went.
Will add details here later. The Gparted first discovered earlier when trying to install Zen-mini 2011.07 that also failed with USB stick connected. Zen-mini was not good on pc1 did not pursue this.


Here the exact details from install with the problem USB key connected

Code:

[root@localhost guest]# draklive-install
/media/ user
Backtrace has 11 calls on stack:
  11: /usr/lib/libparted.so.0(ped_assert+0x29) [0xb71e88b9]
  10: /usr/lib/libparted.so.0(+0x41435) [0xb721e435]
  9: /usr/lib/libparted.so.0(+0x422b7) [0xb721f2b7]
  8: /usr/lib/libparted.so.0(+0x436aa) [0xb72206aa]
  7: /usr/lib/libparted.so.0(+0x1028e) [0xb71ed28e]
  6: /usr/lib/libparted.so.0(ped_disk_add_partition+0x271) [0xb71f0bf1]
  5: /usr/lib/libparted.so.0(+0x450e3) [0xb72220e3]
  4: /usr/lib/libparted.so.0(+0x4530e) [0xb722230e]
  3: /usr/lib/libparted.so.0(ped_disk_new+0x79) [0xb71f1a29]
  2: /usr/lib/libDrakX/auto/c/stuff/stuff.so(XS_c__stuff_get_disk_type+0x1ed) [0xb7272fd5]
  1: /usr/lib/perl5/5.10.1/i386-linux-thread-multi/CORE/libperl.so(Perl_pp_entersub+0x56e) [0xb77341ee]
A bug has been detected in GNU Parted.  Refer to the web site of parted http://www.gnu.org/software/parted/parted.html for more information of what could be useful for bug submitting!  Please email a bug report to bug-parted@gnu.org containing at least the version (2.3) and the following message:  Assertion (head_size <= 63) at dos.c:661 in function probe_partition_for_geom() failed.
Aborted
[root@localhost guest]#

[wedgetail]

I am working at extending the life of my pc1, which it now turns out seems rather sluggish pclos kde-mini and a couple of the the other DE LXDE and Openbox.

During the work with the different DE it became clear "oils' ain't oils".  I have a clear problem with one of my 4GB USB keys which for some reason will upset a version of parted ( used in draklive-install i believe)

1.. used in liveCD and installed (not a surprise) KDE and KDE-mini and LXDE-mini  
2.. an older version of GParted (0.6.4-1) live boot CD date handwritten on my burnt CD from ISO, 2010-October-26

The response to the use of parted -l will be "failure" as here (same failure when running draklive-install):

# parted -l
Model: ATA WDC WD800BB-00JH (scsi)
Disk /dev/sda: 80.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  7872MB  7872MB  primary   fat32        boot
 2      7872MB  80.0GB  72.2GB  extended
 5      7872MB  24.7GB  16.8GB  logical   fat32
 6      24.7GB  47.4GB  22.8GB  logical   fat32
 7      47.4GB  57.4GB  10.0GB  logical   ext3
 8      57.4GB  62.8GB  5369MB  logical   ext3


Backtrace has 16 calls on stack:
  16: /usr/lib/libparted.so.0(ped_assert+0x20) [0xb7869350]
  15: /usr/lib/libparted.so.0(+0x3c7d6) [0xb789a7d6]
  14: /usr/lib/libparted.so.0(+0x3d488) [0xb789b488]
  13: /usr/lib/libparted.so.0(+0x3e6b3) [0xb789c6b3]
  12: /usr/lib/libparted.so.0(+0xf48f) [0xb786d48f]
  11: /usr/lib/libparted.so.0(ped_disk_add_partition+0x27f) [0xb78707ef]
  10: /usr/lib/libparted.so.0(+0x40164) [0xb789e164]
  9: /usr/lib/libparted.so.0(+0x403ca) [0xb789e3ca]
  8: /usr/lib/libparted.so.0(ped_disk_new+0x79) [0xb7871579]
  7: parted() [0x804db66]
  6: parted() [0x804ea9c]
  5: parted() [0x8050b87]
  4: parted() [0x8051ceb]
  3: parted(main+0x35) [0x8051ea5]
  2: /lib/libc.so.6(__libc_start_main+0xe6) [0xb769fdb6]
  1: parted() [0x804bf71]
                                                                          

You found a bug in GNU Parted! Here's what you have to do:

Don't panic! The bug has most likely not affected any of your data.
Help us to fix this bug by doing the following:

Check whether the bug has already been fixed by checking
the last version of GNU Parted that you can find at:

   http://ftp.gnu.org/gnu/parted/

Please check this version prior to bug reporting.

If this has not been fixed yet or if you don't know how to check,
please visit the GNU Parted website:

   http://www.gnu.org/software/parted

for further information.

Your report should contain the version of this release (2.3)
along with the error message below, the output of

   parted DEVICE unit co print unit s print

and the following history of commands you entered.
Also include any additional information about your setup you
consider important.

Assertion (head_size <= 63) at dos.c:661 in function probe_partition_for_geom() failed.
Aborted

live-boot GParted3 (0.11.0-7)

When I test with parted -l using downloaded ISO of GParted 3 (0.11.0-7) burnt to CD (md5sum checked ok) (using pc2, but not relevant I believe) then the response on problem USB key is:

..
The two 1TB hard drives data left out
..
..
Model: TOSHIBA TOSHIBA USB DRV (scsi)
Disk /dev/sdc: 4008MB  <--- to distinguish a bit from the "Good Key of 2GB used too)
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      4129kB  4008MB  4004MB  primary  fat32        lba


parted -v

parted (GNU parted) 2.3
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by <http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.

  

The result showing the problem USB key no longer seem to upset parted.  GParted 3 is a live boot linux CD and I let it load in konsole mode and ran in command line mode parted -l etc....

As can be seen the parted version number gives version 2.3 the same as in above, ie version number the same.  That is giving me some trouble to understand.

I have downloaded the source of  parted v 2.4 and 3.4 from here:

http://ftp.gnu.org/gnu/parted/

bottom of page.  Just out of curiosity and I think with and idea of trying to run the file parted but I am out of my depth as it seems to indicate one needs to do some compiling.

Looking in the changelog there was a note about fixing:
 
Assertion (head_size <= 63) at dos.c:661 in function probe_partition_for_geom() failed.

something had been changed, I think it may have been in v 3.0

Anyone experienced enough to have a look and see what is going on?  Is Gparted 3 live boot using parted version 3.0 and the part -v version response not been updated.

The older GParted and the new GParted caries the same parted version 2.3 old one fails on my problem and new one does not

 

Edit: 16 Jan 2012
A note for myself.  I found another 4GB Toshiba drive physically looking the same, but this does not fail the parted -l test.

[wedgetail]

I have update my last post to include the present finding on the darned occasional failure of parted

Presently it is getting above my head but there is a challenge here.   

[AS]

The older GParted and the new GParted caries the same parted version 2.3 old one fails on my problem and new one does not

 

Yes, that the version reported, but what about the packages ? i.e gparted-2.3.-X ?
packages could have been patched, rarely this is reflected on the reported version.   

[wedgetail]

as

That is music to my ears that the version message may not have been updated, so it is very likely the two (ore more)  parted files are different.

The live boot GParted 3 CD has a minimal GUI based Debian front end. I still have not really worked out how it is meant to work, I boot and head directly to run from command line. I feel a bit lost here what to look for  

Not lost for long it seems some inspiration hit, I managed to figure out how to interrogate packages use in GParted live boot.

GParted 3 (0.11.0-7) my latest

Package: parted
Priority: optional
Section: admin
Installed-Size: 288
Maintainer: Parted Maintainer Team <parted-maintainers@lists.alioth.debian.org>
Architecture: i386
Version: 2.3-8.1drbl
Replaces: fsresize, parted1.6
Depends: libblkid1 (>= 2.16), libc6 (>= 2.3), libdevmapper1.02.1 (>= 2:1.02.20), libncurses5 (>= 5.5-5~), libparted0debian1 (>= 2.2-1), libreadline6 (>= 6.0), libuuid1 (>= 2.16)
Suggests: parted-doc
Conflicts: fsresize, parted1.6
Size: 156890
Description: disk partition manipulator

GParted (0.6.4-1) older

Package: parted
Priority: optional
Section: admin
Installed-Size: 280
Maintainer: Parted Maintainer Team <parted-maintainers@lists.alioth.debian.org>
Architecture: i386
Version: 2.3-2
Replaces: fsresize, parted1.6
Depends: libblkid1 (>= 2.16), libc6 (>= 2.3), libdevmapper1.02.1 (>= 2:1.02.20), libncurses5 (>= 5.7+20100313), libparted0debian1 (>= 2.2-1), libreadline6 (>= 6.0), libuuid1 (>= 2.16)
Suggests: parted-doc
Conflicts: fsresize, parted1.6
Size: 154824
Description: The GNU Parted disk partition resizing program

So there is a difference that likely explains why I have different result when running parted -l on one of my USB memory sticks.

[root@localhost gert]# rpm -qa parted
parted-2.3-1pclos2010
[root@localhost gert]#

[wedgetail]

Today I have received the second USB key that I bought at the same time as my Toshiba problem key above.  I can confirm this also fails when exposed to my parted v2.3

This is what I have installed:

[root@localhost gert]# parted -v
parted (GNU parted) 2.3
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by <http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.
[root@localhost gert]#

I am also trying the gparted in testing:

[root@localhost gert]# rpm -qa gparted
gparted-0.11.0-2pclos2012
[root@localhost gert]#

This also will fail, which I believe is because the backend I assume is parted v2.3

Starting gparted from a user konsole asked me for password and switched to root not problem. So I assume this password problem reported in another topic is not at large here.  As I had the 2nd problem USB key plugged in the 'standard error message' rolled out right away.  

Using gparted from menu worked fine (when I do not have either of my problem USB keys installed)

What all this means apart from hanging the install, these 2 USB sticks can not be formatted by KDE-mini or KDE (and others?), not even from a liveCD

[Abraxas]

wedgetail, I can't believe I read all of this thread 
Just picking up on something you said initially, although I bet you don't want to clear all data from whatever drive you are using, after all you've gone through. 

I am not quite sure what to think or expect but since old-polack hardly ever looses a drive I am reluctant to just ditch it without a fight.  So I will also be looking for the "scrub" command he uses sometimes, I think it was dd= something and when I used it last it took 10 or more hours on a small drive but the drive is still running somewhere.

I only have a 40GB HDD to wipe, so didn't take too long, maybe an hour, if that.
I actually have two Comps, each much the same, with 40 GB Hard Drives, and use a 500 GB to store all my bits and pieces, so really the 40 GB HDD's just run the System.

The 'DD code' OP gave me when I got into terrible trouble dual booting PCLinuxOS with WinXP, and decided in a weak moment to try resizing partitions from XP,... and totally screwed up, which was a blessing in disguise as I'm free from MS and their Windows ...

old-polack:

"...If you can get along using a liveCD for a while I'd start by zeroing the drive for a truly fresh start from a like new drive disk.
You can use the dd command from the liveCD to accomplish this.
The command needs to be directed at the correct drive, so I would disconnect any other drives, internal or external, while doing this so as to not endanger any important data.
You should be entering the commands in a terminal as root.

When you think you are ready, boot to the liveCD, log in as root, and open a terminal. First check to be sure the drive in question is the only one the system sees.

[root@localhost ~]# fdisk -l  <Enter>

You should see only the 40 GB drive. Next the dd zero command;

[root@localhost ~]# dd if=/dev/zero of=/dev/sda bs=4096   <Enter>

This will wipe the drive completely of all previous data including the partition table, rendering it to empty like new status, so be sure any data you wish to save has already been backed up to the external drive. The process will take a while, and will be complete when you are returned to the command prompt."

Just felt maybe this could be of HELP if, or whenever, you want to begin over, which you may not 

Regards

[wedgetail]

Abraxas

thanks I really appreciate you dropping in that piece from old-polack we both owe him a lot. I try in my own  way to repay by chipping in on Forum and help out as I can,  

No I am not going to 'scrub' my drive as it has a lot of stored information that sits in just the right way, it seems that really going over the cables did the trick as it has been running for a long time now, with an added Linux system for security.  Eventually I will get around to try it. Right now I am stuck in too many problems.

[Abraxas]

No worries wedgetail 

I'll re-read this thread in a week or two, it's an interesting situation you have happening.

All the best,

Abraxas.