Description of problem: Version-Release number of selected component (if applicable): How reproducible: Try to install F11 on a system with opensolaris ZFS partition. Installation fails with "File System error detected, cannot continue" It seems to barf on /dev/sda2 which is an opensolaris ZFS partition /dev/sda2 * 7753 10302 20482875 bf Solaris It might be related that I have opensolaris' grub installed (as it's the only one that can read/boot zfs). Anyway, relevant logs below Steps to Reproduce: 1. Install F11 on a system with opensolaris ZFS partition 2. Install fails 3. Actual results: Expected results: Additional info:
Created attachment 338138 [details] Anaconda's storage.log
Created attachment 338139 [details] Anaconda.log
Grub is opensolaris' Grub .. and blkid seems to think the FS is ext3 [root@localhost F11beta]# blkid /dev/sda2 /dev/sda2: LABEL="/" UUID="0ff0d0da-f193-4a5d-ae39-27d6f0bab1c4" SEC_TYPE="ext2" TYPE="ext3" [root@localhost F11beta]# fdisk -l Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x2c5f3b7b Device Boot Start End Blocks Id System /dev/sda1 1 7752 62267392 7 HPFS/NTFS /dev/sda2 * 7753 10302 20482875 bf Solaris /dev/sda3 37329 38913 12731512+ 7 HPFS/NTFS /dev/sda4 10303 37328 217086345 5 Extended /dev/sda5 10303 10353 409626 83 Linux /dev/sda6 10354 15452 40957686 8e Linux LVM /dev/sda7 15453 18002 20482843+ 83 Linux /dev/sda8 18003 37328 155236063+ 7 HPFS/NTFS Partition table entries are not in disk order
Ahmed, thanks for the report. Any idea if the kernel messages during the install confirm that it tried to mount as ext3 & failed? Could you dd off the first chunk (at least 270k) of sda2 and attach it, or otherwise send it my way? It looks like zfs sometimes has it's signature at 264k in, and apparently doesn't zero old signatures before that... sigh. Maybe we can move the zfs check ahead, since it is a fairly specific signature. This gets tricky, though, when so few mkfs utilities zero out these gaps. :( Anyway, blkid might need to be fixed up for this (but maybe also anaconda can not choke if it finds an unmountable filesystem...?) thanks, -Eric
We no longer use blkid for filesystem identification in anaconda -- we use udev, which uses /lib/udev/vol_id to identify filesystems. You should file a bug against udev so that it can properly identify ZFS filesystems. Additionally, anaconda should indeed be able to carry on in spite of this failure.
Thanks Dave, wasn't sure. Well, I probably need to fix blkid anyway. :)
volid also thinks it's ext3: # /lib/udev/vol_id sda2-first-1M ID_FS_USAGE=filesystem ID_FS_TYPE=ext3 ... -Eric
Reassigning to udev on the basis of comment #7.
(In reply to comment #7) > volid also thinks it's ext3: > > # /lib/udev/vol_id sda2-first-1M > ID_FS_USAGE=filesystem > ID_FS_TYPE=ext3 Notes: * vol_id does not support ZFS * vol_id: always check for ALL filesystem types and skip conflicting results (since udev-133, Nov 18 2008) -- the same behaviour is implemented in blkid in util-linxu-ng (planned for F12).
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 494111 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
util-linux-ng-2.16.2-6.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/util-linux-ng-2.16.2-6.fc12
util-linux-ng-2.16.2-6.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.