0

I formatted an external hard drive (sdc) to ntfs using parted, creating one primary partition (sdc1). Before formatting the device SystemRescueCd was installed on the external hard drive using the command dd in order to be used as a bootable USB. However when listing devices with lsblk -f I am still getting the old FSTYPE (iso9660) and LABEL (sysrcd-5.2.2) for the formatted device (sdc):

NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc        iso9660     sysrcd-5.2.2                     
└─sdc1     ntfs        sysrcd-5.2.2          /run/media/user/sysrcd-5.2.2

As shown in the output of lsblk -f only the FSTYPE of the partition sdc1 is correct, the sdc1 partition LABEL, sdc block device FSTYPE and LABEL are wrong. The nautilus GUI app is also showing the old device label (sysrcd-5.2.2).

After creating a new partition table, parted suggested I reboot the system before formatting the device to ntfs, but I decided to unmount sdc instead of rebooting.

  • Could it be that the kernel is still using the old FSTYPE and LABEL because I haven't rebooted the system? Do I have to reboot the system to get rid of the old FSTYPE and LABEL?
  • As an alternative to rebooting is there a way to rename the FSTYPE and LABEL of a block device manually so that I can change them to the original FSTYPE and LABEL that shipped with the external hard drive?
1

From the output of lsblk -f in the original post I suspected that the signature of the installed SystemRescueCd was still present in the external hard drive. So I ran the command wipefs /dev/sdc and wipefs /dev/sdc1 which printed information about sdc and all partitions on sdc:

[root@fedora user]# wipefs /dev/sdc
DEVICE OFFSET TYPE    UUID                   LABEL
sdc    0x8001 iso9660                        sysrcd-5.2.2
sdc    0x1fe  dos                            
[root@fedora user]# wipefs /dev/sdc1
DEVICE OFFSET TYPE UUID             LABEL
sdc1   0x3    ntfs  
sdc1   0x1fe  dos

The above printout confirmed that the iso9660 partition table created by SystemRescueCd was still present. lsblk was using the TYPE and LABEL of the iso9660 partition table instead of the dos (Master Boot Record) partition table. To get lsblk to display the correct partition table the iso9660 partition table had to be deleted. Note that dd can also be used to wipe out a partition-table signature from a block (disk) device but dd could also wipe out other partition tables.

Because we want to target only a particular partition-table signature for wiping, wipefs was preferred since unlike dd, with wipefs we would not have to recreate the partition table again. The -a option of the command wipefs erases all available signatures on the device but the -t option of the command wipefs when used together with the -a option restricts the erasing of signatures to only a certain type of partition table. Below we wipe the iso9660 partition table. The -f (--force) option is required when erasing a partition-table signature on a block device.

[root@fedora user]# wipefs -a -t iso9660 -f /dev/sdc
/dev/sdc: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31

After erasing the iso9660 partition table we check the partition table again to confirm that the partition table iso9660 was erased:

[root@fedora user]# wipefs /dev/sdc
DEVICE OFFSET TYPE UUID LABEL
sdc    0x1fe  dos       
[root@fedora user]# wipefs /dev/sdc1
DEVICE OFFSET TYPE UUID             LABEL
sdc1   0x3    ntfs 34435675G36Y4776 
sdc1   0x1fe  dos 

But now that the problematic iso9660 partition table has been erased lsblk is now using the UUID of the partition as the mountpoint directory name since the previously used label of the iso9660 partition-table no longer exists:

NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc                            
└─sdc1     ntfs        34435675G36Y4776          /run/media/user/34435675G36Y4776

we can check which volumes (i.e. partitions) have labels in the directory /dev/disk/by-label which lists all the partitions that have a label:

[root@fedora user]# ls -l /dev/disk/by-label
total 0
lrwxrwxrwx. 1 root root 10 Apr 30 19:47 'System\x20Reserved' -> ../../sda1

The ntfs file system on the partition sda1 is the only partition that has a label

To make the directory name of the mountpoint more human readable we change the label for the ntfs file system on the partition sdc1 from nothing (empty string) to a "new label". The commands for changing the label for a file system depend on the file system 12. For an ntfs file system changing the label is done with the command ntfslabel:

ntfslabel /dev/sdc1 "new-label"

Now after changing the label on the ntfs file system lsblk uses the "new-label" as the name of the directory of the mountpoint:

NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc                            
└─sdc1     ntfs        new-label          /run/media/user/new-label

Notice: also that the device sdc no longer has a file system type and label just like all the other block devices (e.g. sda). Only partitions should have a file system type since the file system is on the partition not the device, and label since the column header LABEL is the file system label not the device label.

0

lsblk is probably first inspecting the first sector to see what filesystem type the device contains, and only if nothing is found, will move on to "usual" locations for filesystem superblocks.

As iso9660 is recognizable from data in the first sector, lsblk doesn't look further and extracts the volume label from there as well.

Simply creating a partition table leaves most of the first sector intact, which is why you are seeing this.

You need to first wipe the first sector with e.g. dd if=/dev/zero of=/dev/sdc count=1 and then recreate the partition table. If you recreate it with the same parameters, the NTFS filesystem you created earlier should still be intact.

  • That makes sense, although I clearly remember parted initializing the device sdc with zeros which took quite a while. Shouldn't that wipe the device the same way that dd does? The dd mapage says that the option count copies only N input blocks but I don't know what that means. Why are you using count=1? Is it to make writing zeros faster? – MyWrathAcademia Apr 30 at 14:18
  • The count=1 means stop after copying 1 block (512 bytes) which is the sector size. I suspect parted only zeroed out the newly created partition and not the whole device. – wurtel Apr 30 at 14:44
  • I ran the dd command to wipe only the first sector and recreated the partition table. You're right that the ntfs file system still seems to be intact but lsblk is still showing iso9660 as the FSTYPE and sysrcd-5.2.2 as the LABEL. DO I need to format again to complete the process you suggested? – MyWrathAcademia Apr 30 at 16:04
  • You may have to zero out more than just the first partition. Modern fdisk starts the first partition on sector 2048, older versions started it on sector 63. Use fdisk -l -u /dev/sdc to see what your layout is. I'd then zero out with count=2048 or count=63. However, TBH this is just cosmetic, it shouldn't matter otherwise. – wurtel May 1 at 6:48
  • I solved the problem, see my answer. I'm sure zeroing out more than just the first partition would work but I needed a simpler way that avoids recreating the partition table – MyWrathAcademia May 1 at 18:29
0

Have you tried re-reading the partition table (as root) ?

partprobe /dev/sdc
  • before running a command as root it's a good idea to know exactly what the command will do. Can you add an explanation of what partprobe /dev/sdc does? – MyWrathAcademia Apr 30 at 14:22
  • I ran the command partprobe /dev/sdc, it didn't work – MyWrathAcademia Apr 30 at 14:33
  • 1
    partprobe only instrcuts the kernel to re-read the partition table. lsblk doesn't use the kernel's stored idea, it reads the device directly so this could not have helped. – wurtel May 1 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.