GNOME Bugzilla – Bug 684403
GParted appends 'nA' to label when changing label
Last modified: 2012-11-03 19:58:09 UTC
Whenever I use GParted to change a label on a partition it adds 'nA' to the label. This is reproducible 100% of the time.
To troubleshoot this problem we will need more information. What type of file system is in the partition? What is the text of the label are you trying to set? What is the output of the following command before and after changing the label? sudo blkid /path-to-partition Where /path-to-partition is something like /dev/sda2
In this case, I had send an information to alain@mtools.linux.lu a bug in the mlabel program Hello Alain, a bug in the mlabel program of mtools version 4.0.12, dated November 3rd, 2009 and gparted 0.11.0-2 gnome-disk-utility 3.0.2-2ubuntu7 #Laufwerksverwaltung sudo mlabel -i /dev/sdb1 -s :: #Volume label is sudo mlabel -i /dev/sdb1 ::my_external #-> MY_EXTERNAL (11 charakters must be) sudo mlabel -i /dev/sdb1 ::my_ext #-> MY_EXT_Oo_d (MY_EXT?????) after a restart at the next day #-> MY_EXT¶OoÀd Labeling Programs FAT16 and FAT32 sudo mlabel -i /dev/sdb1 -s :: #note: 8+3=11 characters maximum. NTFS sudo ntfslabel /dev/sdb1 #Note: 128 characters maximum. ext2, ext3, and ext4 sudo e2label /dev/sdb1 #Note: 16 characters maximum. etc. look at https://help.ubuntu.com/community/RenameUSBDrive Have you any idea to solve this problem ? regards Siegfried I hope this can help you for this problem.
Can you test with the latest GParted Live 0.13.1-2? When I tested with GParted Live 0.13.1-2, I had no difficulty setting the label to MY_EXTERNAL. GParted Live 0.13.1-2 uses the following related packages: gparted-0.13.1 mtools-4.0.17-1 Perhaps the newer mtools-4.0.17-1 fixes the problem?
I have tested with the latest GParted Live 0.13.1-2 . Now the setting label to my_external etc. is o.k. (only in upper case) but not if I delete a label. #Details 1. enter box: label delete -> o.k. 2. in 1 Operation pending *no* Undo exist, only Apply 3. clear partition label on /dev/sdc1 -> in English is correct 4. clear partition (no label !) on /dev/sdc1 -> confuse in German 5. really the label was deleted -> checked with ubuntu 6. but not in the gparted graphic display and not in the enter box In the moment I have no possibility to test mtools newest version. I hope in a week.
(In reply to comment #4) > I have tested with the latest GParted Live 0.13.1-2 . > > Now > the setting label to my_external etc. is o.k. (only in upper case) GParted shows the label in the same case as the tool used to retrieve the label. See also the following forum post: Partition Label: only capital letters? http://gparted-forum.surf4.info/viewtopic.php?id=14115 > but not > if I delete a label. > > #Details > 1. enter box: label delete -> o.k. > 2. in 1 Operation pending *no* Undo exist, only Apply > 3. clear partition label on /dev/sdc1 -> in English is correct > 4. clear partition (no label !) on /dev/sdc1 -> confuse in German > 5. really the label was deleted -> checked with ubuntu > 6. but not in the gparted graphic display > and not in the enter box I can confirm that the label is deleted, but still shows up in the GParted graphic display and the label enter box. When the label is deleted, it appears that it is still cached by commands such as blkid. For example if the label was deleted from /dev/sdc1, check the output of the following two commands: sudo blkid /dev/sdc1 sudo dosfslabel /dev/sdc1 Since deletion of the label is considered a different problem, would you be able to create a new bug report for deleting a volume label? The problem with setting a label on the FAT file system appears to be fixed in newer versions of mtools. As such we should close this bug report as RESOLVED.
The problem with label deletion, but still being cached and shown by GParted is being tracked in the following bug report: Bug #685656 - GParted doesn't notice when file system label is changed to blank The problem raised in this report has been identified as a problem with an older version of mtools that has since been fixed. As such I am marking this bug as resolved.