Bug#80325: Installer misreports partition numbers
Chris Paul wrote:
>
> Hi Adam,
> it took me quite a few days to `find ..` your "flavours" in a path requiring 70 chars ... ;-)
>
> There was no vanilla, but the test results of the rest looks really interesting.
>
> > ... I need to know what "flavor" you were booting from...
> So sit down, ...;-)
>
> <Long Story>
> Lets begin with my current layout:
> susa:~ # fdisk -l /dev/hda
>
> Disk /dev/hda: 240 heads, 63 sectors, 3970 cylinders
> Units = cylinders of 15120 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hda1 * 1 258 1950448+ 6 FAT16
> /dev/hda2 259 775 3908520 a5 BSD/386
> /dev/hda3 776 820 340200 4f QNX4.x 3rd part
> /dev/hda4 821 3970 23814000 5 Extended
> /dev/hda5 821 1078 1950448+ 83 Linux
> /dev/hda6 * 1079 1336 1950448+ eb BeOS fs
> /dev/hda7 1337 1594 1950448+ 83 Linux
> /dev/hda8 1595 2111 3908488+ 83 Linux
> /dev/hda9 2112 3117 7605328+ 83 Linux
> /dev/hda10 3118 3892 5858968+ 83 Linux
> /dev/hda11 3893 3970 589648+ 82 Linux
> swap
>
> summary:
> - 3 primary partitions a the beginning, with a BSD Unix containing slices at pos. 2,
> - swap at disk/extended partition end (11)
>
> So now my current OS:
> susa:~ # uname -a
> Linux susa 2.2.16 #1 Wed Aug 2 20:03:33 GMT 2000 i686
> unknown
> susa:~ # dmesg | grep hda:.hda1
> hda: hda1 hda2! hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > <
> hda12 hda13 hda14 hda15 >
> - quite broken! It is a SuSE 7.0 "apm" kernel with default modules, unchanged, AFAIRemember...
> (It __should__ show: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >)
> My custom kernels dont show these "extra partitions" (2.4.0-test5 and 2.2.12)
> - And [c]fdisk, too.
>
By extra partitions do you mean <hda12 hda13 hda14 hda15> ?
Partitions listed within < > are logical partitions, so dmesg from your
suse kernel is reporting that you have *TWO* extended (or container)
partitions.
hda4 is one of your extended partitions, and i think (although i dont
know bsd much at all) that hda2 is another extended partition, where
hda12 to hda15 are the bsd slices within hda2.
Note that if the kernel you boot with doesnt have support for BSD slices
then you wont see hda12 to hda15, only the partition that holds them
(hda3).
If you boot with a kernel that doesnt understand BSD slices the kernel
wont display hda12 - hda15, but they are there. Userland fdisk type
programs that understand BSD slices should still list hda12 - hda15.
> Flavors:
> -----------
> 1) idepci:
> - "Show Part. Table (?)" from "Setup (?)" shows something like
> /dev/hda1 not mounted (type ok)
> 2 not avail. (type ok)
> 5 not avail. (type ok)
> 6 not avail. (type ok)
> 7 not avail. (type ok)
> 8 not avail. (type ok)
> 3 not avail. unknown
> 4 not avail. extended
> 9 not mounted linux nat.
> 10 not avail. unknown <---(???)
> 11 not mounted linux nat.
>
> - dmesg: looks like it should (like hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >)
The part of the installer that produces this list is libfdisk, it can be
compiled to identify BSD partitions (hda12-hda15), but libfdisk appears
to get its list of partitions from /proc/partitions so unless the kernel
you booted from has support for BSD style disklabels it may not show
(hda12 - hda15), im not too sure.
> - BUT /var/log/messages: (something like...)
> user.warn: dbootstrap: no dev. name f. disk /dev/hda part. 12 (skipped)
> (and same entry for part. 13, 14, 15)
Im less sure about this, could it be that the device entries
(/dev/hda12 to /dev/hda15) dont exist ?
Or Could it be that libfdisk has found your BSD slices but but your
kernel doesnt know about them.
Doing a "cat /proc/partitions" would help here.
> - fdisk: OK
>
Im not sure if fdisk/cfdisk will show BSD slices....
> 2) compact:
> Same like idepci; BUT: /var/log/messages only warnings for part. 12 and 13...
> - fdisk: OK
>
> 3) udma66:
> - Very much and very fast scrolling-by errors "can't ...(open device???)" before inittial screen...
> - "Show Part. Table (?)"
> - same like "idepci" (see above) PLUS
> 12 not mounted
> 13 not mounted
> 14 not mounted
> 15 not in use <- whatever it means...
> - dmesg: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 >
> - log/messages: nothing but syslog started...
> - fdisk: OK
>
> Remarkable:
> 1) the order of the partitions 1-2-5-6-7-8-3-4-...
> 1 is fat, 2 BSD with slices, 3 unknown to linux (but was the same with ext2), 4 extended.
> Some process inserts the slices with numbers greater than the extended one at the places where they are found on disk, ads the real partition (3) and the following ...
> This ordering keeps constant whether the kernel sees more partitions or not...
Maybe the issue here is that 5-6-7-8 in the debian menu refer to
hda12-hda13-hda14-hda15 acording to dmesg listing.
If two extended partitions (or partitions that contian partitions like
BSD slices i asusme) are found in primary partitions i dont know that
there is any correct way to list them, but for consistency it should
agree with the kernels method.
> 2) Part. 10: Why "not available"?
Probably means cant be mounted.
> 3) Part. 15: What could be meant with "not in use"?
> 4) All that doesnt affect fdisk, mkfs, mount,swapon,... (but unfortunatly you might "not quite get what you want"...)
If you follow the partition numbering as shown in /proc/partitions for
mounting then you should be right, but for complete userland programs
like fdisk, you have to follow the order that they think is right (even
if it is different).
> 5) My partitoning is ok: the "newer" lilo (e.g. found on debian) boots what it can boot - up to the high cylinders and the great GRUB boots them all...
> 6) All that disappeard when I temporarily changed my type-id of the BSD-Partition (Did you ever hear of "56 Golden Bow" ?)
>
Once you changed the partition type, it must have made libfdisk only see
one extended type partition, so there was no conflict with the ordering
of the two extended partitions.
> Last but not least: Q.: Why dont you use some fdisk -l | sed | grep && awk for display AND mkfs?
> </Long Story>
>
libfdisk is probably works on more platforms, and when it was created i
dont think the kernel recognised as many partition tables as libfdisk.
and libfdisk is smaller....
Hope this helps, i would be particularly interested to see your
/proc/partitions with with BSD support compiled into the kernels.
Glenn
Reply to: