Description of problem: On installation, I selected custom partition, and named my partitions with the Label option: OS1 Mageia Root OS2 Windows Temp Directory Home /home etc. During the installation, the boot then subsequently fails, with: dracut: inable to process initqueue warning "dev/disk/OS1" does not exist When I booted my old OS, with the disk on the USB, I went into the Mandriva disk partitioning tool, and something had re-labelled the disk OS1_Mandriva, but I don't know what had done it - it is possible it was the Mandriva 2011 tool. Version-Release number of selected component (if applicable): Mageia 2b3 dracut-017-5.mga2 How reproducible: Only gone through this once, as it takes some time Steps to Reproduce: 1. Install new image 2. When partitioning disks, use advanced option, and include a space in the label 3. Boot
Sorry, disk was re-labelled OS1_Mageia_Root, not OS1_Mandriva
CC: (none) => mageiaBlocks: (none) => 4298
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 => RESOLVEDResolution: (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.