Bug 5541

Sorry, disk was re-labelled OS1_Mageia_Root, not OS1_Mandriva

OK, I tried to reproduce this, but couldn't.

I installed a test system and labelled my root drive "My Mageia Root". After completing the install, both /etc/fstab and /boot/grub/menu.lst referenced the UUID of the drives, not the their label.

Also, the label itself it's not actually relabelled as such... it's just mis-reported. It seems to be reading the udev properly ID_FS_LABEL rather than ID_FS_LABEL_ENC (the former being a sanitised version of the latter which converts spaces to underscores among other things).

So I'd say this is a bug in diskdrak.

As for the install, I'm not sure how you managed to get it to use labels rather than UUIDs. Did you adjust the bootloader stage during install?

CC: (none) => pterjan

I went around the houses several times, as I was having problems with the graphics driver, and kept having to re-install.  So I apologise that the description is muddled.

During the first install, I used the GUIs that were presented - I didn't run anything else.  I didn't select the advanced option, and didn't label any disks, and didn't have any problems (apart from me screwing up the video configuration).

I did several installs, and I also moved the disk between Mandriva (on the USB) and Mageia as I have data to transfer from my old disk to the new one.

I did run the disk partitioning tool in Mandriva on the disk when mounted on the USB - I set the partition sizes in that tool (but it wouldn't let me label them or assign them to / and /home, for example, as those directories were already mounted)

The install before the problem, I used the disk partitioning tool that is called up in the boot process - the partitions I had already created were there, but their mount points, types and Labels were not set - so I set them (with spaces).

I believe that it was this boot that failed.

I put the disk back on Mandriva via the USB, and saw that the labels now had underscores in them, where I had previously put spaces.



What are the rules with regards to allowable characters in the partition labels?



With regards to the labels vs uuids:

I supplied kernel option xdriver=vga to get the os to boot, but didn't do anything else out of the ordinary when it came to the install.

On one install, I noticed that the drives were mounted by the OS in the /media/Label directory.  Now they get mounted by the OS in the /media/d2320f42-36b6-4248-b448-3ba6cda92e77 directory.


Steve

May not be relevant to this (but relevant elsewhere), but I've just run a few applications to view the disk, and I've noticed that somehow, the patitions have not started on sector boundaries - could this be relevant to the labels issue - probably not.

#fdisk -l

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63   262132604   131066271   83  Linux
Partition 1 does not start on physical sector boundary.
/dev/sda2       262133760   524265209   131065725    b  W95 FAT32
/dev/sda3       524265472   786397814   131066171+  83  Linux
/dev/sda4       786401217  3907024064  1560311424    5  Extended
Partition 4 does not start on physical sector boundary.
/dev/sda5       786401280   851926949    32762835   82  Linux swap / Solaris
/dev/sda6       851929088   978904709    63487811   83  Linux
/dev/sda7       978907136  2443213394   732153129+  83  Linux
/dev/sda8      2443216896  3907024064   731903584+  83  Linux

# more /etc/fstab
# Entry for /dev/sda1 :
LABEL=Mageia_root / ext4 defaults 1 1
# Entry for /dev/sda8 :
LABEL=backup /backup ext4 defaults 1 2
# Entry for /dev/sda7 :
LABEL=home /home ext4 defaults 1 2
none /proc proc defaults 0 0
# Entry for /dev/sda6 :
LABEL=tmp /tmp ext4 defaults 1 2
# Entry for /dev/sda5 :
UUID=105d0681-8b1e-4ac0-8bb5-be3105f50125 swap swap defaults 0 0

[root@hodgins libDrakX]# blkid /dev/sdc1
/dev/sdc1: LABEL="label with space" UUID="c834eb85-6f93-48dc-99cd-cd35704a306b" TYPE="ext2"
[root@hodgins libDrakX]# blkid -o udev /dev/sdc1
ID_FS_LABEL=label_with_space
ID_FS_LABEL_ENC=label\x20with\x20space

Very inconsistent.  Looking at the filesystem with hexedit,
it does have x'20' in the label.

Regarding the partitioning,
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

This is one of the so called "Advanced format", or green
drives that uses an internal sector size of 4k, but
a logical sector size of 512 bytes.  Most file system writes
are 4k blocks.  If the filesystem tries to write a 4k block
that doesn't align with the internal sectors, it will result
in two 4k reads, a merge with the data being written, followed
by two 4k writes.  A massive write performance hit.

diskdrake and gparted now default to 1 mb alignment, but
that won't alter existing partitions.

Probably a good idea to shrink the partitions slightly, and move
them so they are aligned with 1 MB boundaries.  As always, when
working with partitioning, make sure you have backups of anything
important, just in case.  I find gparted the easiest to use for
this type of work.

CC: (none) => davidwhodgins

Yeah because diskdrake uses the ID_FS_LABEL attribute for the labels, if you load it up and then save the label that has been loaded, it will write it back with the spaces converted to underscores.

So while this is a bug in diskdrake, it's not a problem as per reported in this bug.

As my test installation worked perfectly, I don't think this is a valid bug report in itself.

I would very much encourage you to open a new bug against diskdrake (or maybe Pascal will see this and decide to fix it anyway). That bug should explain that diskdrake should use ID_FS_LABEL_ENC and decode it when filling in it's label information.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME

it seems there used to be ID_FS_LABEL_SAFE and ID_FS_LABEL, but now ID_FS_LABEL is "safe" (as of few years ago :) ). ID_FS_LABEL_ENC would need to be decoded (space is \x20).

Anyway udev output format is deprecated, we'd better switch to -o export.