Date: Wed, 26 Apr 2006 10:49:43 GMT From: Leo Shum <shum@u.washington.edu> To: freebsd-gnats-submit@FreeBSD.org Subject: i386/96357: FreeBSD cannot recognize all the logical partitions Message-ID: <200604261049.k3QAnh6m069832@www.freebsd.org> Resent-Message-ID: <200604261050.k3QAoBMq041766@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 96357 >Category: i386 >Synopsis: FreeBSD cannot recognize all the logical partitions >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 26 10:50:11 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Leo Shum >Release: FreeBSD 6.0 >Organization: >Environment: FreeBSD 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC i386 >Description: The interpretation of dp_start in an extended partition is incorrect. According to wikipedia http://en.wikipedia.org/wiki/Extended_Master_Boot_Record, the 2nd entry of the EMBR, if not empty, points to the next EMBR in the chain. The starting sector is relative address of the next EMBR within the extended partition. However, in boot/i386/libi386/biosdisk.c, in function bd_checkextended, dp_start of the next chained partition is added to the start address of the current logical partition, but not the address of the extended partition. (line 677 and 687) The end result is that when iterating through the logical paritions (slices), the function fails to recognize other slices past the 7th or 8th, and bombs with "no magic in extended table" because by that time the start address of the slice is all messed up. >How-To-Repeat: On a disk, create a few logical paritions (>10). Invoke /boot/loader and check for available slices. With enough debugging turned on, /boot/loader will complain "no magic in extended table" when looking at slicenum 7. >Fix: I have a brute force hack to make dp_start calculate the correct address, then /boot/loader can find all available slices. But at the boot prompt, the slice start and end addresses as shown by lsdev -v are incorrect. Looks like there are other parts of the code that calculate the values incorrectly as well, not just bd_checkextended >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604261049.k3QAnh6m069832>