Why is lsblk showing the old FSTYPE and LABEL of a device that was formatted?

Question

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?

Solution 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.

Solution 2

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

partprobe /dev/sdc

Comments

[bit]

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?

[bit]

I ran the command partprobe /dev/sdc, it didn't work

[wurtel]

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.

[bit]

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?

[wurtel]

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.

[bit]

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

[eichin]

Given that lsblk --fs works even if you're not root, it's not reading anything directly. Turns out (based on strace) that lsblk talks to udev to get the label, at least on 16.04; this matters when you're debugging this problem from a minimal install where changes like this don't show up without an explicit udevadm trigger. That's probably not what the original questioner was dealing with, though.

[sayap]

When using zfsonlinux, partprobe does help to get lsblk -f to output zfs_member as the filesystem type.

[Sridhar Sarnobat]

This didn't work for me either, even though I did a full dd (though over ssh and gzipped).