This bug does appear to be a problem with the dosfslabel command
not setting the volume label in two locations.
It is interesting to note that the mkdosfs command from the
dosfstools-3.0.5 package _does_ set the label in two locations.
Following is some more information regarding this bug that
On Mon, Nov 24, 2008 at 19:31:30 +, Sam Morris wrote:
I've tried running dosfslabel to change the label of a vfat filesystem. This
seemed to work:
# /sbin/dosfslabel /dev/sda1
sam
However, the change was not picked up by HAL. On investigation, it seems that
this is because
On Tue, 2008-11-25 at 13:52 +, Sam Morris wrote:
For the record, findfs from e2fsprogs also sees the label as being
'UDISK 2.0' and it does not link against libvolume-id--so this may not
only be a libvolume-id-specific bug.
I'm now beginning to suspect dosfstools again. I plugged my device
reassign 506786 libvolume-id0
tags 506786 +moreinfo
thanks
Sam Morris wrote:
I've tried running dosfslabel to change the label of a vfat filesystem. This
seemed to work:
# /sbin/dosfslabel /dev/sda1
sam
correct.
However, the change was not picked up by HAL. On investigation, it seems
The string 'sam16' does appear at the top of the device:
eb 58 90 4d 53 57 49 4e 34 2e 31 00 02 80 d0 10
|.X.MSWIN4.1.|
0010 02 00 00 00 00 f8 00 00 3f 00 80 00 80 1f 00 00
|?...|
0020 80 90 e4 01 98 07 00 00 00 00 00 00 02 00 00 00
Package: dosfstools,libvolume-id0
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've tried running dosfslabel to change the label of a vfat filesystem. This
seemed to work:
# /sbin/dosfslabel /dev/sda1
sam
However, the change was not picked up by HAL. On investigation, it
6 matches
Mail list logo
