Description of problem: Disk /dev/sda: 601.3 MiB, 630480896 bytes, 1231408 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x90909090 Device Boot Start End Sectors Size Id Type /dev/sda4 * 0 49999 50000 24.4M a5 FreeBSD Version-Release number of selected component (if applicable): Fedora 22 anaconda How reproducible: Always, right at the start screen with language Steps to Reproduce: 1. Download FreeBSD-10.0-RELEASE-i386-memstick.img 2.Start qemu-kvm -cdrom Fedora-Live-Workstation-x86_64-22-3.iso -boot d -m 2GB -hda FreeBSD-10.0-RELEASE-i386-memstick.img Actual results: Crash
Please attach the logs from /tmp to this bug as individual, text/plain attachments.
Created attachment 1060243 [details] anaconda.log
Created attachment 1060244 [details] storage.log
Created attachment 1060251 [details] program.log
Was there a traceback file in /tmp, named anaconda-tb-*? That would be helpful.
Created attachment 1060354 [details] anaconda tb 1
Created attachment 1060355 [details] anaconda tb 2
Created attachment 1060356 [details] anaconda tb 3
Quiet a bug ones - just remember those are not for the exactly same session as previous logs.
Can you retry with F23 Beta? A lot of improvements have been made as far as reporting on different storage configurations that anaconda cannot use and how they can be fixed.
Well, the anaconda of F23 does not crash, but refuses to continue with message "failed to scan disk sda", blabla.. report a bug, "we were unable to locate a disklable on a disk that the kernel is reporting paritions on". Fdisk reports stil the same as in #1.
udev/blkid do not indicate any partition table on sda. What is indicated is a UFS filesystem. There is also this in syslog: Aug 07 08:44:47 localhost kernel: sda: sda4 sda4: <bsd:bad subpartition - ignored > So, there are several problems with your disk: 1. For some reason blkid does not think it contains a partition table 2. blkid thinks it contains a UFS filesystem 3. There is something wrong with the BSD partition on sda (?) These issues need to be resolved before an OS can be safely installed on the disk. I know people tend to think that the installer should be able to use any imaginable existing device, but this is not at all a reasonable position. It is not reasonable to leave various stale metadata all over the place and expect software to be able to tell which to pay attention to and which to ignore. I am reassigning this to util-linux so you can figure out why the partition table on sda is not detected by blkid. It is not necessarily a bug in blkid.
Ok, I understand broken partition layout can no be used. I was not expecting a FreeBSD to distribute the image with incorrect partition layout. Parted complains about: Error: Invalid partition table - recursive partition on It seems the problem is the parition in slot 4 of MBR is defined to begin at sector 0, which overlaps the MBR and leaves no free sectors for it at disk beginning.
It seems like typical messy bootable image :-) 1/ bootloader stuff (begin of the first sector) -- see hexdump for more details 2/ MBR (end of the first sector): # fdisk -l /dev/loop0 ... Disklabel type: dos ... Device Boot Start End Sectors Size Id Type /dev/loop0p4 * 0 49999 50000 24.4M a5 FreeBSD where partition starts from begin of the device. We usually use this for bootable CD images to make happy tools/systems where MBR is required. 3/ BSD partition table # fdisk --type bsd /dev/loop0 ... Disklabel type: bsd ... Slice Start End Sectors Size Type Fsize Bsize Cpg a 0 1282959 1282960 626.5M 4.2BSD 0 0 0 c 0 1282959 1282960 626.5M unused 0 0 0 The BSD specific and common feature are nested partition tables. It means that you have normal MBR and one partition (BSD type, for example a5) contains another BSD specific partition table. This is reason why kernel tries to parse "sda4: <bsd> ...". The important detail (for Linux) is that the nested BSD partitions have to be *within* parental MBR partition, but 4th MBR partition (sda4 in your #1 comment) is only 24MiB and the BSD nested partitions have 626MiB. This is reason why the BSD label is ignored by Linux kernel as well as by blkid. 4/ UFS (sector 16) blkid is correct, it's really mountable UFS filesystem: # losetup -f FreeBSD-10.1-RELEASE-i386-memstick.img # mount /dev/loop0 /mnt/test -r -t ufs -oufstype=44bsd works as expected. Note that -oufstype is necessary to specify and you have to do it manually, because nowhere is info about the type of UFS. Sooo, I think blkid is correct: # blkid -p -o udev /dev/loop0 ID_FS_VERSION=1 ID_FS_UUID=54629e466b8b4567 ID_FS_UUID_ENC=54629e466b8b4567 ID_FS_TYPE=ufs ID_FS_USAGE=filesystem ID_PART_TABLE_UUID=90909090 ID_PART_TABLE_TYPE=dos it's disk with MBR (ID_PART_TABLE_TYPE=dos) and there is also UFS. The problem is that such information is useless for anaconda and the disk is impossible to use for anything serious (all (MBR, BSD PT and UFS) is mapped to the same area). I don't think we have to be compatible with all crazy boot images especially when designed for another operation systems and I'm not sure what is expected from installer in this case. IMHO the best possible solution is to ignore such disk and offer console for manual intervention (for example to mount the FS). Closing. Sorry. (but thanks, I have another PT item in my on-disk-zoo collection:-)
No problem, thanks for attention. BTW: It seems to me, that 10.2 image is somewhat improved (well GPT, not DOS anymore): # fdisk -l FreeBSD-10.2-RELEASE-i386-memstick.img GPT PMBR size mismatch (1346453 != 1346452) will be corrected by w(rite). Disk FreeBSD-10.2-RELEASE-i386-memstick.img: 657.5 MiB, 689383936 bytes, 1346453 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 18B420EA-412C-11E5-BA8F-002590EC5BF2 Device Start End Sectors Size Type FreeBSD-10.2-RELEASE-i386-memstick.img1 3 34 32 16K FreeBSD boot FreeBSD-10.2-RELEASE-i386-memstick.img2 35 1344402 1344368 656.4M FreeBSD UFS FreeBSD-10.2-RELEASE-i386-memstick.img3 1344403 1346450 2048 1M FreeBSD swap
... because GPT is really explicit and strict about layout and overlap is unsupported and unexpected. MBR is whatever you want if you keep 55aa at the end of the first sector :-)