Bug 1251262 - blkid does not detect msdos disklabel with bsd partition
blkid does not detect msdos disklabel with bsd partition
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Karel Zak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-06 16:33 EDT by Adam Pribyl
Modified: 2015-11-11 08:51 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-11 07:18:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log (9.75 KB, text/plain)
2015-08-07 02:55 EDT, Adam Pribyl
no flags Details
storage.log (16.97 KB, text/plain)
2015-08-07 02:55 EDT, Adam Pribyl
no flags Details
program.log (6.60 KB, text/plain)
2015-08-07 03:15 EDT, Adam Pribyl
no flags Details
anaconda tb 1 (269.13 KB, text/plain)
2015-08-07 08:48 EDT, Adam Pribyl
no flags Details
anaconda tb 2 (268.30 KB, text/plain)
2015-08-07 08:49 EDT, Adam Pribyl
no flags Details
anaconda tb 3 (268.17 KB, text/plain)
2015-08-07 08:49 EDT, Adam Pribyl
no flags Details

  None (edit)
Description Adam Pribyl 2015-08-06 16:33:12 EDT
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
Comment 1 David Shea 2015-08-06 16:35:36 EDT
Please attach the logs from /tmp to this bug as individual, text/plain attachments.
Comment 2 Adam Pribyl 2015-08-07 02:55:16 EDT
Created attachment 1060243 [details]
anaconda.log
Comment 3 Adam Pribyl 2015-08-07 02:55:43 EDT
Created attachment 1060244 [details]
storage.log
Comment 4 Adam Pribyl 2015-08-07 03:15:54 EDT
Created attachment 1060251 [details]
program.log
Comment 5 David Shea 2015-08-07 06:41:09 EDT
Was there a traceback file in /tmp, named anaconda-tb-*? That would be helpful.
Comment 6 Adam Pribyl 2015-08-07 08:48:56 EDT
Created attachment 1060354 [details]
anaconda tb 1
Comment 7 Adam Pribyl 2015-08-07 08:49:20 EDT
Created attachment 1060355 [details]
anaconda tb 2
Comment 8 Adam Pribyl 2015-08-07 08:49:44 EDT
Created attachment 1060356 [details]
anaconda tb 3
Comment 9 Adam Pribyl 2015-08-07 08:51:05 EDT
Quiet a bug ones - just remember those are not for the exactly same session as previous logs.
Comment 10 David Shea 2015-10-26 17:02:01 EDT
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.
Comment 11 Adam Pribyl 2015-11-09 08:01:39 EST
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.
Comment 12 David Lehman 2015-11-09 10:50:27 EST
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.
Comment 13 Adam Pribyl 2015-11-11 04:14:54 EST
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.
Comment 14 Karel Zak 2015-11-11 07:18:49 EST
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:-)
Comment 15 Adam Pribyl 2015-11-11 08:11:14 EST
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
Comment 16 Karel Zak 2015-11-11 08:51:41 EST
... 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 :-)

Note You need to log in before you can comment on or make changes to this bug.