0

I can't format a bunch of internal disks that I have bought in second hand from a datacenter. The disks were formatted in NTFS, this is 3 2TB seagate constellation ES +2 1TB seagate constellation ES + 1 WDC RE3 1TB. I have done a new partition table (try with gpt and dos) for each of them with fdisk and create a new partition. But each time I try to format to ext4 for example it gives me an error like :

/dev/sdg1 is apparently in use by the system; will not make a filesystem here!

or an unknown error with gparted but if I format in ntfs it's okay. can't be normal right? What should I do? I'm a bit without a clue here. Configuration: ubuntu:16.04.1

Edit: To show you the whole process: 

@docker:~$ sudo sfdisk -l /dev/sdh
Disque /dev/sdh : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0abdc00e
@docker:~$ sudo fdisk /dev/sdh

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Commande (m pour l'aide) : o
Created a new DOS disklabel with disk identifier 0x18c440ee.

Commande (m pour l'aide) : n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Numéro de partition (1-4, 1 par défaut) : 
Premier secteur (2048-3907029167, 2048 par défaut) : 
Last sector, +sectors or +size{K,M,G,T,P} (2048-3907029167, 3907029167 par défaut) : 

Created a new partition 1 of type 'Linux' and of size 1,8 TiB.

Commande (m pour l'aide) : w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

@docker:~$ sudo mkfs.ext4 /dev/sdh1
mke2fs 1.42.13 (17-May-2015)
/dev/sdh1 est apparemment utilisé par le système ; ne fera pas un système de fichiers ici !
@docker:~$ sudo umount /dev/sdh1
umount: /dev/sdh1: not mounted
vigilian@docker:~$ sudo sfdisk §l /dev/sdh
sfdisk: failed to parse partition number: '/dev/sdh'
vigilian@docker:~$ sudo sfdisk -l /dev/sdh                                                         
Disque /dev/sdh : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x18c440ee

Périphérique Amorçage Start        Fin   Secteurs  Size Id Type
/dev/sdh1              2048 3907029167 3907027120  1,8T 83 Linux
vigilian
  • 402
  • 2
  • 4
  • 11
  • Please, show the result of commands `mount` and `sfdisk -l -us` after error has occurred. – Mikhail Khirgiy Sep 12 '16 at 18:03
  • sfdisk -l -us sfdisk: unsupported unit 's' I don't know what does sfdisk normally and what's the purpose – vigilian Sep 12 '16 at 23:30
  • why mount? to mount which partition? do you mean mount -a ? – vigilian Sep 12 '16 at 23:31
  • @vigilian `mount` without arguments lists mounted fs – aaaaa says reinstate Monica Sep 13 '16 at 00:35
  • Then `sfdisk -l /dev/sdg`. – Mikhail Khirgiy Sep 13 '16 at 03:45
  • `@docker:~$ sudo sfdisk -l /dev/sdg [sudo] Mot de passe de : Disque /dev/sdg : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs Unités : sectors of 1 * 512 = 512 octets Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xe6268d10 Périphérique Amorçage Start Fin Secteurs Size Id Type /dev/sdg1 2048 1953525167 1953523120 931,5G 83 Linux` I will try the other disks and will print the informations if it fails – vigilian Sep 13 '16 at 11:09
  • Try command `dd if=/dev/zero of=/dev/sdh bs=8M count=8` then reinsert HDD or reboot the system. – Mikhail Khirgiy Sep 13 '16 at 15:24
  • `@docker:/media/nfsmedia/syno$ sudo dd if=/dev/zero of=/dev/sdh bs=8M count=8 8+0 enregistrements lus 8+0 enregistrements écrits 67108864 bytes (67 MB, 64 MiB) copied, 0,0224429 s, 3,0 GB/s` – vigilian Sep 13 '16 at 19:55
  • @MikhailKhirgiy Okey I just reboot, it seems to have worked. So I don't know if it was the effect of low level format + reboot or your command + the reboot or the whole package but it worked. Can you explain it to me, please? – vigilian Sep 13 '16 at 20:14
  • @MikhailKhirgiy I don't know if it's the same than that (just look on google) : [help](http://unix.stackexchange.com/questions/275243/what-is-this-dd-if-dev-zero-of-dev-sda-do) ... but does the low-level format does the same? why wasn't it working if it does? because I should have done a reboot of the system after it? or maybe the low-level does only data and not partition table? And also is it a bug of certain disks to have problems to rewrite on their partition table? or is it consistent with all the disks in the world, it's just the the properties of the materials used to make them? – vigilian Sep 13 '16 at 20:18
  • @MikhailKhirgiy you should put it as an answer, in that way I could validate the answer. – vigilian Sep 13 '16 at 20:22
  • No, there isn't any answer. Ubuntu use old information about your drives or use these drives not via mount. When you destroyed several first sectors, may be cleared some raid identification information or something else. We now don't know what it was happened. – Mikhail Khirgiy Sep 13 '16 at 20:42
  • Okey so it is unclear but you think it's more a behaviour of ubuntu than anything else, if I understand you correctly at least. Should I report this bug on ubuntu launchpad or something like that? Anyway thanks for the answer @MikhailKhirgiy – vigilian Sep 13 '16 at 20:44
  • I don't think that it is a bug. If you have other "unformatted" disk. We can try to find cause of this. – Mikhail Khirgiy Sep 13 '16 at 20:59
  • Yeah I have some more. What do you think about the protocol to debug it? Because I really don't have any clue how to debug it. Since I've tried with fdisk and gparted, it seems that it isn't related to the tools, or they all use the same libraries to do the partition table...? – vigilian Sep 13 '16 at 21:19
  • Please show results of two commands `dmesg | grep -iP "(raid)|(sdh)"` and `cat /proc/mdstat`. Change `sdh` to the name of tested HDD drive. – Mikhail Khirgiy Sep 14 '16 at 18:19
  • And this command `dmraid -r` – Mikhail Khirgiy Sep 14 '16 at 18:32
  • I have one HDD left that I Haven't touch about configuration but presenting the same problem than the others. first command : doesn't give anything. but the cat /proc/mdstat give `@docker:/$ cat /proc/mdstat md125 : inactive sdn[0] 976224256 blocks super external:/md126/0 md126 : inactive sdn[0](S) 538328 blocks super external:ddf` Plus of course my configurations – vigilian Sep 17 '16 at 11:26
  • I had to install dmraid. `@docker:/$ sudo dmraid -r no raid disks` – vigilian Sep 17 '16 at 11:29
  • @MikhailKhirgiy so you think it's because it was already in raid in the datacenter? – vigilian Oct 03 '16 at 18:06
  • @vigilian Yes, i think these disks were in software raid. RAID tool write special information to each disk, witch allow the Linux kernel to recognize RAID disks and to try create RAID array. – Mikhail Khirgiy Oct 04 '16 at 04:35

2 Answers2

0

Before you change partitions or something else u must umount the disk

This command should work for you: umount /dev/sdg*

After that try again to create the Partition

When this doesnt work, then pls comment and dont click that - 1 Button instantly

Resurrection
  • 14
  • 2
  • the disks weren't mount anyway and I've even done power cycle them because of the frozen status for hdparm (since I thought that ll fromat them will change something). I think I have just succeeded with one of the disk to finaly format the filesystem. Is it possible that the disks were incompatible with gpt ? or that because of the firmware (theirs were SN02 for the samsung) they would have problems with linux or gpt? – vigilian Sep 13 '16 at 11:07
  • the only clue I have for the moment it's possible incompatibility with gpt or maybe the bios of my motherboard of a bad interaction with it or a bug with ubuntu. But anyway the only clue is that the combination of a low level format like here: [link](http://askubuntu.com/questions/253096/low-level-format-of-hard-drive) + then change of partition table and file system seems to do something. I have launch the low level format with another disk to see. – vigilian Sep 13 '16 at 11:49
  • the low level format doesn't change a thing about how the hdd reacts. Ihave try the command of mikhail. Will see what happens when I reboot the system – vigilian Sep 13 '16 at 19:57
0

So thanks to @MikhailKhirgiy seems that none of the tools gparted or fdisk actually erase the old partition table of the datacenter. Reason unclear but solution is to erase the first lines of bytes of the disk with : sudo dd if=/dev/zero of=/dev/sdh bs=8M count=8

thanks to him.

vigilian
  • 402
  • 2
  • 4
  • 11