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

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

how to test disk for bad sector

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 05:10 +0200
    Re: how to test disk for bad sector Patrick Bartek <nemommxiv@gmail.com> - 2020-08-29 05:40 +0200
      Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 07:50 +0200
        Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-29 10:20 +0200
          Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 12:00 +0200
            Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-30 00:10 +0200
              Re: how to test disk for bad sector David Wright <deblis@lionunicorn.co.uk> - 2020-09-08 06:30 +0200
                Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-09-09 16:40 +0200
        Re: how to test disk for bad sector Patrick Bartek <nemommxiv@gmail.com> - 2020-08-29 19:10 +0200
          Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 22:20 +0200
        Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-30 00:00 +0200
          Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-30 01:10 +0200
            Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-30 01:40 +0200
              Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-30 02:10 +0200
                Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-30 02:40 +0200
                Re: how to test disk for bad sector Andy Smith <andy@strugglers.net> - 2020-08-30 16:10 +0200
                  Re: how to test disk for bad sector Charles Curley <charlescurley@charlescurley.com> - 2020-08-30 16:30 +0200
                    Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-31 00:10 +0200
                      Re: how to test disk for bad sector Charles Curley <charlescurley@charlescurley.com> - 2020-08-31 04:10 +0200
                        Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-31 05:00 +0200
                      Re: how to test disk for bad sector Patrick Bartek <nemommxiv@gmail.com> - 2020-08-31 18:30 +0200
                        Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-31 23:50 +0200
                          Re: how to test disk for bad sector Patrick Bartek <nemommxiv@gmail.com> - 2020-09-01 04:20 +0200
                            Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-09-01 05:40 +0200
                          passwords + bad memory - Was (Re: how to test disk for bad sector) Mike McClain <mike.junk.46@att.net> - 2020-09-02 01:10 +0200
                            Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) Ben Caradoc-Davies <ben@transient.nz> - 2020-09-02 01:40 +0200
                              Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) <tomas@tuxteam.de> - 2020-09-02 09:40 +0200
                                Re: passwords + bad memory - Was (Re: how to test disk for bad sector) rhkramer@gmail.com - 2020-09-02 15:30 +0200
                                  Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) <tomas@tuxteam.de> - 2020-09-02 15:40 +0200
                                    Re: passwords + bad memory - Was (Re: how to test disk for bad sector) John Hasler <jhasler@newsguy.com> - 2020-09-02 18:40 +0200
                                      Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) Brian <ad44@cityscape.co.uk> - 2020-09-02 22:00 +0200
                                        Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) <tomas@tuxteam.de> - 2020-09-02 22:10 +0200
                                        Re: passwords + bad memory - Was (Re: how to test disk for bad sector) John Hasler <jhasler@newsguy.com> - 2020-09-03 01:40 +0200
                                          Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) Brian <ad44@cityscape.co.uk> - 2020-09-03 12:40 +0200
                            Re: passwords + bad memory - Was (Re: how to test disk for bad sector) rhkramer@gmail.com - 2020-09-02 01:50 +0200
                              Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) Tom Dial <tddial@comcast.net> - 2020-09-02 09:00 +0200
                              Re: passwords + bad memory - Was (Re: how to test disk for bad  sector) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-02 11:20 +0200
                                Re: passwords + bad memory - Was (Re: how to test disk for bad sector) rhkramer@gmail.com - 2020-09-02 15:30 +0200
        Re: how to test disk for bad sector Michael Stone <mstone@debian.org> - 2020-08-31 20:40 +0200
    Re: how to test disk for bad sector David <bouncingcats@gmail.com> - 2020-08-29 05:50 +0200
      Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 06:50 +0200
    Re: how to test disk for bad sector "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-08-29 10:20 +0200
      Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 13:20 +0200
        Re: how to test disk for bad sector Kenneth Parker <sea7kenp@gmail.com> - 2020-08-29 13:50 +0200
        Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-29 14:30 +0200
          Re: how to test disk for bad sector Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-29 18:50 +0200
            Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-30 00:20 +0200
              Re: how to test disk for bad sector Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-30 02:40 +0200
                Re: how to test disk for bad sector Gene Heskett <gheskett@shentel.net> - 2020-08-30 03:10 +0200
                  Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-30 04:10 +0200
                    Re: how to test disk for bad sector Gene Heskett <gheskett@shentel.net> - 2020-08-30 05:10 +0200
                  Re: how to test disk for bad sector <tomas@tuxteam.de> - 2020-08-30 09:30 +0200
                  Re: how to test disk for bad sector Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-30 21:00 +0200
                    Re: how to test disk for bad sector Long Wind <longwind2@yahoo.com> - 2020-08-31 00:00 +0200
                  Re: how to test disk for bad sector Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-02 11:30 +0200
                Re: how to test disk for bad sector Keith Bainbridge <keithrbaugroups@gmail.com> - 2020-08-30 06:00 +0200
      Re: how to test disk for bad sector Marco Möller <talby@debianlists.mobilxpress.net> - 2020-08-29 15:00 +0200

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

#226527

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

 Thank David!
but it says PASSED
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Please note the following marginal Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0022   066   045   045    Old_age   Always   In_the_past 34 (Min/Max 29/34)




    On Friday, August 28, 2020, 11:46:07 PM EDT, David <bouncingcats@gmail.com> wrote:  
 
 On Sat, 29 Aug 2020 at 13:00, Long Wind <longwind2@yahoo.com> wrote:

Subject: how to test disk for bad sector

> i believe hard disk has bad sector

# smartctl -t short /dev/<device>
# smartctl -t long /dev/<device>
# smartctl -l selftest /dev/<device>

Documentation:
https://wiki.archlinux.org/index.php/SMART
https://en.wikipedia.org/wiki/S.M.A.R.T.

  

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

#226530

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

On 29.08.2020 07:59, Long Wind wrote:
> installation of linux to sdb1 fails
> i believe hard disk has bad sector
If hard drive has bad sectors or recently encountered them, information
about this should be noted to hard drive's SMART table.
Alternatively, you can use "badblocks" program from "e2fsprogs" package
to scan hard drive for bad blocks.
I'd perform tests on wiped clean hard drive with non-destructive read
test first, followed by write test.
Testing media for bad blocks could be time consuming if hard drive is
multiple terabytes in size.

> i use e2fsck with -c, i.e. read-only test
> it doesn't  report any error
>


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

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

#226534

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

 Thank Alexander! i'll test it with write test.

    On Saturday, August 29, 2020, 4:18:31 AM EDT, Alexander V. Makartsev <avbetev@gmail.com> wrote:  
 
  On 29.08.2020 07:59, Long Wind wrote:
  
 
 installation of linux to sdb1 fails i believe hard disk has bad sector  If hard drive has bad sectors or recently encountered them, information about this should be noted to hard drive's SMART table.
 Alternatively, you can use "badblocks" program from "e2fsprogs" package to scan hard drive for bad blocks.
 I'd perform tests on wiped clean hard drive with non-destructive read test first, followed by write test.
 Testing media for bad blocks could be time consuming if hard drive is multiple terabytes in size.
 
 
  i use e2fsck with -c, i.e. read-only test it doesn't  report any error 
   
 
 
 -- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org⠈⠳⣄⠀⠀⠀⠀    

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

#226535

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

On Sat, Aug 29, 2020, 7:11 AM Long Wind <longwind2@yahoo.com> wrote:

> Thank Alexander! i'll test it with write test.
>
>
>
> On Saturday, August 29, 2020, 4:18:31 AM EDT, Alexander V. Makartsev <
> avbetev@gmail.com> wrote:
>
>
> On 29.08.2020 07:59, Long Wind wrote:
>
> installation of linux to sdb1 fails
> i believe hard disk has bad sector
> If hard drive has bad sectors or recently encountered them, information
> about this should be noted to hard drive's SMART table.
> Alternatively, you can use "badblocks" program from "e2fsprogs" package to
> scan hard drive for bad blocks.
> I'd perform tests on wiped clean hard drive with non-destructive read test
> first, followed by write test.
> Testing media for bad blocks could be time consuming if hard drive is
> multiple terabytes in size.
>
>
> i use e2fsck with -c, i.e. read-only test
> it doesn't  report [useful data]
>
> I encountered a different situation, that *might* apply.  I had, what I
can only describe as,  *SUCH*  a defective USB Stick that, instead of
declaring any errors, many I/O Requests would "Time Out" and then *succeed*
without an Error Message.

This turned into a "Cluster-*$@#", because it wasn't Debian I was
Installing, but Mint 20, whose Email List Support lacked basic
Troubleshooting Skills, on the day that I submitted my "Distress Call".  (A
combination of only Install from a Live DVD with Ubiquity, coupled with an
Irrelevant Python Error Message that comes out, periodically, even in the
best of circumstances didn't help either).

So have you tested the Hardware in question on "Neutral Tasks"?

Thank you!  (And I *still* think Mint should offer an Expert, Text Install
option like Debian!)

Kenneth Parker

>

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

#226537

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

 it pass write test!  i really don't know where installation go wrong. in the past i installed debian 2 times from dvd, both failed.  today fedora installation fails. it's STRANGE. 

it's Seagate 320G, i bought from 2nd-hand dealer, it's cheap. i can afford another disk if i need. it's waste of time to continue diagnose. 
 
below is details of write test by badblocks:

[liveuser@localhost-live ~]$ sudo badblocks -wv /dev/sda1

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Checking for bad blocks in read-write mode
>From block 0 to 14080971
Testing with pattern 0xaa: done                                                
Reading and comparing: done                                                
Testing with pattern 0x55: done                                                
Reading and comparing: done                                                
Testing with pattern 0xff: done                                                
Reading and comparing: done                                                
Testing with pattern 0x00: done                                                
Reading and comparing: done                                                
Pass completed, 0 bad blocks found. (0/0/0 errors)
[liveuser@localhost-live ~]$ 

    On Saturday, August 29, 2020, 7:11:07 AM EDT, Long Wind <longwind2@yahoo.com> wrote:  
 
  Thank Alexander! i'll test it with write test.

    On Saturday, August 29, 2020, 4:18:31 AM EDT, Alexander V. Makartsev <avbetev@gmail.com> wrote:  
 
  On 29.08.2020 07:59, Long Wind wrote:
  
 
 installation of linux to sdb1 fails i believe hard disk has bad sector  If hard drive has bad sectors or recently encountered them, information about this should be noted to hard drive's SMART table.
 Alternatively, you can use "badblocks" program from "e2fsprogs" package to scan hard drive for bad blocks.
 I'd perform tests on wiped clean hard drive with non-destructive read test first, followed by write test.
 Testing media for bad blocks could be time consuming if hard drive is multiple terabytes in size.
 
 
  i use e2fsck with -c, i.e. read-only test it doesn't  report any error 
   
 
 
 -- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org⠈⠳⣄⠀⠀⠀⠀      

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

#226540

On 29.08.20 14:20, Long Wind wrote:
> it pass write test!  i really don't know where installation go wrong.

After the disk itself seems to not cause the problem, at least not 
because of bad blocks, confirm that the data highways on your 
motherboard and any involved data caches are all still operating fine.

(1) Read at highest possible speed from the device from which during 
installation is read from by directing the read data to the device 
"/dev/zero" ("/dev/zero" is a device which is not doing anything with 
received input, all received data is immediately after reception simply 
ignored = forgotten = thrown away):
   sudo dd if=/dev/DeviceReadingFrom of=/dev/zero bs=8M status=progress

(2) Write at highest possible speed a huge amount of data to the disk in 
order to check if the path to the disk also works free of errors under 
high load, and likewise also check that the cache inside the disk still 
performs free of error, by writing data received from the device 
"/dev/zero" (you will destroy all data on the disk, this begins at the 
beginning of the disk and will thus first erase a present partition 
table; the disk will after this test have to be partitioned and 
filesystems have to be newly created; no old data can be expected to be 
recoverable from the disk) (in this case, from the device "/dev/zero" 
there will be received values "0" as long as requested and thus the 
disks becomes overwritten with zeros):
   sudo dd if=/dev/zero of=/dev/WritingToThisDisk bs=8M status=progress
If you do not cancel this process by STRG+C before, then it will end 
with an error message when the disk is full and you can see from the 
last reported status how much data has been written to the disk.

(3) Do the same as above but involving the full data highway from your 
device you are reading from to the device you are writing to:
   sudo dd if=/dev/DeviceReadingFrom of=/dev/WritingToThisDisk bs=8M 
status=progress

If all these tests run through without errors (with test (2) running 
until the disk is full), then I would say that it is safe to assume that 
it is not a hardware problem of disks, disk controllers or motherboard. 
My only left assumptions would then be, that maybe in the BIOS some 
security feature is activated which interferes with the installation 
process, or some other peace of hardware lets the system crash when 
becoming addressed during the installation process, like some 
incompatible graphics board or some other incompatible peripheral 
component.

Good Luck!
Marco

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

#226546

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

 Thank Marco!i have installed debian to other disk of same PC, no problem.anyway i try 2nd command you suggest, see below for result
[liveuser@localhost-live ~]$ sudo dd if=/dev/zero of=/dev/sda1 bs=8M status=progress

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

14386462720 bytes (14 GB, 13 GiB) copied, 151.001 s, 95.3 MB/s 
dd: error writing '/dev/sda1': No space left on device
1719+0 records in
1718+0 records out
14418915840 bytes (14 GB, 13 GiB) copied, 153.319 s, 94.0 MB/s
[liveuser@localhost-live ~]$ 




    On Saturday, August 29, 2020, 12:41:55 PM EDT, Marco Möller <talby@debianlists.mobilxpress.net> wrote:  
 
 On 29.08.20 14:20, Long Wind wrote:
> it pass write test!  i really don't know where installation go wrong.

After the disk itself seems to not cause the problem, at least not 
because of bad blocks, confirm that the data highways on your 
motherboard and any involved data caches are all still operating fine.

(1) Read at highest possible speed from the device from which during 
installation is read from by directing the read data to the device 
"/dev/zero" ("/dev/zero" is a device which is not doing anything with 
received input, all received data is immediately after reception simply 
ignored = forgotten = thrown away):
  sudo dd if=/dev/DeviceReadingFrom of=/dev/zero bs=8M status=progress

(2) Write at highest possible speed a huge amount of data to the disk in 
order to check if the path to the disk also works free of errors under 
high load, and likewise also check that the cache inside the disk still 
performs free of error, by writing data received from the device 
"/dev/zero" (you will destroy all data on the disk, this begins at the 
beginning of the disk and will thus first erase a present partition 
table; the disk will after this test have to be partitioned and 
filesystems have to be newly created; no old data can be expected to be 
recoverable from the disk) (in this case, from the device "/dev/zero" 
there will be received values "0" as long as requested and thus the 
disks becomes overwritten with zeros):
  sudo dd if=/dev/zero of=/dev/WritingToThisDisk bs=8M status=progress
If you do not cancel this process by STRG+C before, then it will end 
with an error message when the disk is full and you can see from the 
last reported status how much data has been written to the disk.

(3) Do the same as above but involving the full data highway from your 
device you are reading from to the device you are writing to:
  sudo dd if=/dev/DeviceReadingFrom of=/dev/WritingToThisDisk bs=8M 
status=progress

If all these tests run through without errors (with test (2) running 
until the disk is full), then I would say that it is safe to assume that 
it is not a hardware problem of disks, disk controllers or motherboard. 
My only left assumptions would then be, that maybe in the BIOS some 
security feature is activated which interferes with the installation 
process, or some other peace of hardware lets the system crash when 
becoming addressed during the installation process, like some 
incompatible graphics board or some other incompatible peripheral 
component.

Good Luck!
Marco

  

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

#226550

On 30.08.20 00:01, Long Wind wrote:
(...)
> [liveuser@localhost-live <mailto:liveuser@localhost-live> ~]$ sudo dd 
> if=/dev/zero of=/dev/sda1 bs=8M status=progress
(...)
> 14386462720 bytes (14 GB, 13 GiB) copied, 151.001 s, 95.3 MB/s
> dd: error writing '/dev/sda1': No space left on device
> 1719+0 records in
> 1718+0 records out
> 14418915840 bytes (14 GB, 13 GiB) copied, 153.319 s, 94.0 MB/s

Unfortunately, this looks bad for your disk, because you said in another 
post that your disk is supposed to provide a storage space of 320 GB. 
But in this test only 14 GB could be written to it and then it is 
claimed to already have been filled completely. So, in context of 
another post of yours, where you say that you could install a system to 
a new disk mounted to that same computer, you found the problem: the 
supposed to be 320 GB hard disk is either broken in a very strange way, 
or it is even a fake disk sold to you as a fraud.

Wishing you good luck with your new disk and new installation!
Marco.

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

#226552

On Saturday 29 August 2020 20:39:29 Marco Möller wrote:

> On 30.08.20 00:01, Long Wind wrote:
> (...)
>
> > [liveuser@localhost-live <mailto:liveuser@localhost-live> ~]$ sudo
> > dd if=/dev/zero of=/dev/sda1 bs=8M status=progress
>
> (...)
>
> > 14386462720 bytes (14 GB, 13 GiB) copied, 151.001 s, 95.3 MB/s
> > dd: error writing '/dev/sda1': No space left on device
> > 1719+0 records in
> > 1718+0 records out
> > 14418915840 bytes (14 GB, 13 GiB) copied, 153.319 s, 94.0 MB/s
>
> Unfortunately, this looks bad for your disk, because you said in
> another post that your disk is supposed to provide a storage space of
> 320 GB. But in this test only 14 GB could be written to it and then it
> is claimed to already have been filled completely. So, in context of
> another post of yours, where you say that you could install a system
> to a new disk mounted to that same computer, you found the problem:
> the supposed to be 320 GB hard disk is either broken in a very strange
> way, or it is even a fake disk sold to you as a fraud.
>
> Wishing you good luck with your new disk and new installation!
> Marco.

Uh, I have to ask. Or maybe I came into the middle of what has become a 
boring thread?

dd is a whole device writer, but his command line is to an existing 
partition? His command line should not have had the 1 according to my 
thinking.  His whole disk might be 320 gigabytes as /dev/sda, but how 
big is sda1?

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 <http://geneslinuxbox.net:6309/gene>

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

#226553

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

   On Saturday, August 29, 2020, 9:04:17 PM EDT, Gene Heskett <gheskett@shentel.net> wrote:  
 
 Uh, I have to ask. Or maybe I came into the middle of what has become a 
boring thread?

dd is a whole device writer, but his command line is to an existing 
partition? His command line should not have had the 1 according to my 
thinking.  His whole disk might be 320 gigabytes as /dev/sda, but how 
big is sda1?

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 <http://geneslinuxbox.net:6309/gene>
You are right. to save time i use sda1, not sda. 
sda1 has about 14GB, sda has 320GB 

i have posted result of badblocks early, it shows
"From block 0 to 14080971"it means how much disk space it is testing?

  

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

#226554

On Saturday 29 August 2020 22:01:03 Long Wind wrote:

>    On Saturday, August 29, 2020, 9:04:17 PM EDT, Gene Heskett
> <gheskett@shentel.net> wrote:
>
>  Uh, I have to ask. Or maybe I came into the middle of what has become
> a boring thread?
>
> dd is a whole device writer, but his command line is to an existing
> partition? His command line should not have had the 1 according to my
> thinking.  His whole disk might be 320 gigabytes as /dev/sda, but how
> big is sda1?
>
> Cheers, Gene Heskett
please, I know english is not your 1st language, but your email agent is 
also broken because it allowed you to post below my sig separator. So I 
am forced to copy/paste in order to include your question, which was:

You are right. to save time i use sda1, not sda. 
sda1 has about 14GB, sda has 320GB 

i have posted result of badblocks early, it shows
"From block 0 to 14080971"it means how much disk space it is testing?

To whiuch my reply is yes, that figure is in 1024 byte blocks, which 
would be about 14 gigabytes that you zeroed out, needlessly I think.

Sig separators are the double dash under the Che below, followed by a 
space and a newline. The definition is:newline dash dash space newline.  

And is usually mucked up horribly by html mail agents.

Refresh me please on the full name of the real file you were writing to 
this disk when you hit the out of space error.

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 <http://geneslinuxbox.net:6309/gene>

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

#226558

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

On Sat, Aug 29, 2020 at 09:03:54PM -0400, Gene Heskett wrote:

[...]

> dd is a whole device writer, but his command line is to an existing 
> partition?

No. 'dd' doesn't care. How/why should it? It can write to whatever is
supposed to be organized as a sequence of blocks. I.e. a block device
(which may sit on top of a "disk device" or a partition, but also a
regular file on your file system.

If there is one thing UNIX got pretty well compared to its siblings
of the time, then it was interface abstraction (it's got still a ton
of quirks, but you've got to look at the others aroud it to really
appreciate).

Cheers
 - t

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

#226574

On 30.08.20 03:03, Gene Heskett wrote:
> On Saturday 29 August 2020 20:39:29 Marco Möller wrote:
> 
>> On 30.08.20 00:01, Long Wind wrote:
>> (...)
>>
>>> [liveuser@localhost-live <mailto:liveuser@localhost-live> ~]$ sudo
>>> dd if=/dev/zero of=/dev/sda1 bs=8M status=progress
>>
>> (...)
>>
>>> 14386462720 bytes (14 GB, 13 GiB) copied, 151.001 s, 95.3 MB/s
>>> dd: error writing '/dev/sda1': No space left on device
>>> 1719+0 records in
>>> 1718+0 records out
>>> 14418915840 bytes (14 GB, 13 GiB) copied, 153.319 s, 94.0 MB/s
>>
>> Unfortunately, this looks bad for your disk, because you said in
>> another post that your disk is supposed to provide a storage space of
>> 320 GB. But in this test only 14 GB could be written to it and then it
>> is claimed to already have been filled completely. So, in context of
>> another post of yours, where you say that you could install a system
>> to a new disk mounted to that same computer, you found the problem:
>> the supposed to be 320 GB hard disk is either broken in a very strange
>> way, or it is even a fake disk sold to you as a fraud.
>>
>> Wishing you good luck with your new disk and new installation!
>> Marco.
> 
> Uh, I have to ask. Or maybe I came into the middle of what has become a
> boring thread?
> 
> dd is a whole device writer, but his command line is to an existing
> partition? His command line should not have had the 1 according to my
> thinking.  His whole disk might be 320 gigabytes as /dev/sda, but how
> big is sda1?
> 
> Cheers, Gene Heskett
> 

You are right, Gene!  I did not notice that it was written to partition 
"/dev/sda1", because I didn't expect this test to only be written to a 
partition instead of test writing to the whole disk. I have not noticed 
this detail in the answer when replying to it, shame on me.
My recommendation was to use the command like this:
   sudo dd if=/dev/zero of=/dev/WritingToThisDisk bs=8M status=progress
Long Wind, the test works only if you overwrite the full disk. So, as 
Gene pointed out, after the test which you did by now it cannot be 
concluded what I concluded in my former answer!

We by now only know that writing to the 14 GB of partition "/dev/sda1" 
worked correctly, but we do not know where on the disk this 14 GB are 
actually located and we also still do not know about the rest of the 
disk and if it continues to work fine also for a bigger data load 
occupying the electronics for longer time.

So, if you are interested to still know about your old drive, although 
you said that you already installed successfully to a new drive, then 
you may want to direct the test all the device and not only a partition 
of it.

Best regards,
Marco.

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

#226575

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

   On Sunday, August 30, 2020, 2:58:51 PM EDT, Marco Möller <talby@debianlists.mobilxpress.net> wrote:  
You are right, Gene!  I did not notice that it was written to partition 
"/dev/sda1", because I didn't expect this test to only be written to a 
partition instead of test writing to the whole disk. I have not noticed 
this detail in the answer when replying to it, shame on me.
My recommendation was to use the command like this:
  sudo dd if=/dev/zero of=/dev/WritingToThisDisk bs=8M status=progress
Long Wind, the test works only if you overwrite the full disk. So, as 
Gene pointed out, after the test which you did by now it cannot be 
concluded what I concluded in my former answer!

We by now only know that writing to the 14 GB of partition "/dev/sda1" 
worked correctly, but we do not know where on the disk this 14 GB are 
actually located and we also still do not know about the rest of the 
disk and if it continues to work fine also for a bigger data load 
occupying the electronics for longer time.

So, if you are interested to still know about your old drive, although 
you said that you already installed successfully to a new drive, then 
you may want to direct the test all the device and not only a partition 
of it.

Best regards,
Marco.
Thank Marco! i can't do test on whole disk because i have useful files in other partitions. smartctl report gives me some confidence in the problem disk. i've installed buster to the problem disk and am using it now to write this mail. i can backup files in problem disk if they r important. below is layout of problem disk reported by fdisk:
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Disk model: ST3320311CS     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x059a302a

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *      1606500  29768444  28161945  13.4G 83 Linux
/dev/sda2        92164905 215047779 122882875  58.6G  7 HPFS/NTFS/exFAT
/dev/sda3       215048192 625137663 410089472 195.6G  7 HPFS/NTFS/exFAT
/dev/sda4        29768445  89305334  59536890  28.4G 83 Linux

Partition table entries are not in disk order.



  

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

#226634

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

On Sb, 29 aug 20, 21:03:54, Gene Heskett wrote:
> 
> Uh, I have to ask. Or maybe I came into the middle of what has become a 
> boring thread?
> 
> dd is a whole device writer, but his command line is to an existing 
> partition? His command line should not have had the 1 according to my 
> thinking.  His whole disk might be 320 gigabytes as /dev/sda, but how 
> big is sda1?

'dd' doesn't care if the destination is a whole block device, a 
partition or a regular file, it will write to whatever you ask it to.

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

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

#226555

On 30/8/20 10:39 am, Marco Möller wrote:
> [liveuser@localhost-live <mailto:liveuser@localhost-live> ~]$ sudo dd 
> if=/dev/zero of=/dev/sda1 bs=8M status=progress


Um..... my reading of the original question is that he Long tried to 
install onto /dev/sdb. Why are we blanking part of /dev/sda?


Would it be better to unplug /dev/sda for the installation process?

-- 
Keith Bainbridge

keithrbaugroups@gmail.com
or ke1thozgroups@gmx.com

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

#226538

On 29.08.20 10:18, Alexander V. Makartsev wrote:
> On 29.08.2020 07:59, Long Wind wrote:
>> installation of linux to sdb1 fails
>> i believe hard disk has bad sector
> If hard drive has bad sectors or recently encountered them, information 
> about this should be noted to hard drive's SMART table.
> Alternatively, you can use "badblocks" program from "e2fsprogs" package 
> to scan hard drive for bad blocks.
> I'd perform tests on wiped clean hard drive with non-destructive read 
> test first, followed by write test.
> Testing media for bad blocks could be time consuming if hard drive is 
> multiple terabytes in size.
> 
>> i use e2fsck with -c, i.e. read-only test
>> it doesn't  report any error
>>
> 

I support this recommendation to use badblocks.
If you first would need to rescue data from the disk, although your 
question sounds like there is no data worth to rescue from the disk 
anymore, then use ddrescue from package gddrescue first.
Then, using badblocks, I recommend to run it in write mode with option 
"-n" for the following reason: if I am correctly informed, then disks 
with S.M.A.R.T have usually a reservoir of memory blocks to which the 
firmware of the disk itself, without the operating system seeing this, 
redirects by the disk itself already detected bad blocks. The statistics 
about these permanent redirection events is found in the S.M.A.R.T. log 
of the disk, which you can access by the smartctl program. But the 
internal mechanism of the disk's S.M.A.R.T. will only detect bad blocks 
upon the intent to write to blocks. Simply intending to read from bad 
blocks will not trigger S.M.A.R.T. to recognize blocks as bad blocks and 
they would thus not become visible in the S.M.A.R.T. report. If you 
later would write to the disk (i.e. during your OS installation you are 
mentioning as the cause to have encountered a problem with your 
hardware) then either S.M.A.R.T. will invisibly protect you by applying 
its internal redirection mechanism to reservoir blocks, or, if no more 
reservoir blocks are available, leave the operating system with the 
problem. This is what might happen in your situation right now. So, the 
operating system now needs to maintain its own list of bad blocks, which 
is thus the list of bad blocks no more cared for by S.M.A.R.T. . Again, 
simply reading from the disk might not be enough to properly detect 
these still present bad blocks. Therefore I recommend to let the 
operating system search for them by running badblocks with option "-n" 
(or "-w", please consult the man pages what better fits your needs) in 
write mode! Actually, I would recommend to repeat such run several 
times, in order to monitor if the amount of bad blocks is at least 
constant or if it is increasing. In the latter case you should replace 
the disk by a new one for sure. In the former case, if badblocks command 
finds already bad blocks which couldn't be cared for by S.M.A.R.T., I 
would also seriously consider to replace the disk for a new one now, if 
the financial situation allows for it. But if a replacement is wished to 
be avoided now for financial reasons, then at least continue to monitor 
the situation very frequently and of course at any time have a proper 
backup of your data on a still good medium. Given the requirement to 
frequently monitor a disk which can not buffer problems for you 
automatically by its S.M.A.R.T., and considering the time effort this 
repeatedly involves, you will have to balance this costs of time and 
missing trust in the present medium against the costs for a new disk.

If the disk comes out to not be the cause for your trouble encountered 
with your system, then you could check if all components on the 
motherboard involved in moving data around are still fine:
- write a heavy amount of data to the disk: with command dd copy a huge 
amount of data from an externally to USB connected drive to the drive 
which you at the moment suspect to trouble; maybe the motherboard fails 
from time to time to still handle such job free of errors; so, the disk 
might be still be fine and could be reused elsewhere, but the data 
highway on your motherboard started to fail; for this check I would not 
simply use if=/dev/zero, but really reading data from another drive, in 
order to ensure that on the motherboard the respective data highway has 
to be used as during your OS installation or during future data copy 
procedures;
- check your RAM with memtest86+, you will have to search for a Life 
pen-drive offering this command in its grub boot menu; I am not 
perfectly sure right now, but would expect the Knoppix Linux 
distribution to offer this;
- check your CPU with stress-ng

Good luck!
Marco

[toc] | [prev] | [standalone]

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

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

csiph-web